Уменьшить STEEMIT_MIN_REPLY_INTERVAL для комментариев

[litrbooh]

Постоянно упираюсь в лимит 20сек при оставлении комментариев, это дико раздражает. Обычно это происходит, когда ты заходишь в свой пост, а там 5-10 комментов, на которые надо ответить.

Предлагаю уменьшить хотя бы до 5 секунд.

Или как вариант рассмотреть возможность ввести лимит времени на группу комментариев. Например, чтобы можно было оставить не более 10 комментариев за 200 секунд. Получается, что общий лимит тот же - 20 секунд, но в реальности ты в него не упираешься.

[t3ran13]

за последнее, тоже самое для постов и апвотов.

никто никогда ничего не делает с равными интервалами. ни комменты не ставит, ни посты не пишет, ни лайкает. всегда интервалы разные. мыж не роботы)

[litrbooh]

ыыыы, бесит!

[bitphage]

I support lowering of this limit as a quick solution.

[gropox]

Если делать то группу, и небольшую. 6 комментариев в минуту.

Не хотелось бы превращать в чат.

Потом ещё меня смущает, что пул вознаграждений общий с постами, что может привести к эксплуатации комментариев ботами.

И вообще, лучше подумать прежде чем что то написать.))

[litrbooh]

@gropox
Ботам как раз всё равно, они 20 секунд подождут :)

[gropox]

@litrbooh но так боты могут писать комментарии в 4 раза быстрее.

Вообще по хорошему, может стоит еще подумать, и сделать пул вознаграждений комментариев общим с постом. Тогда хоть сколько комментариев пиши под постом.

[gropox]

Но попробовать снизить паузу, не до 5, а до 10 секунд стоит. Обычно секунды 3-5 проходит, от записи поста в блокчейн, до обновления вебстраницы. Так что в сумме 10 секунд задержки никто не заметит.

[litrbooh]

Не, 10 секунд уже много. Достаточно быстро сейчас на golos.io комменты публикуются, точнее они же уходят в блок и ты сразу пишешь новый, тебе не нужно обновлять страницу.

[litrbooh]

У нас, правда время наверно блоками считается, так что 6 секунд.

[VIM-Arcange]

FYI, there was the same discussion on Steemit. They decided to put the limit to 1 comment per block.

[gropox]

Тоже самое хотелось бы и для постов. Иногда нужно опубликовать сразу пару постов скриптом к примеру, но не получается.

Можно кстати сделать увеличенное потребление bandwith, если пост опубликовался в период менее 5 минут. Пропорционально - два поста сразу если, то второй пост отъест x2 bandwith, если второй пост опубликуется спустя 2.5 минуты, то отъест x1.5 обычной bandwith и так далее. Тоже самое можно сделать с комментариями, только таймфрейм взять в 20 секунд. Тогда акки с большой СГ не почувствуют ограничения совсем

[VIM-Arcange]

Можно кстати сделать увеличенное потребление bandwith, если пост опубликовался в период менее 5 минут.

Это предложение интересным, но и очень сложная. Это уже трудно объяснить пользователям, как это работает. В этом случае, он не поймет ничего. Я думаю, что следует отдавать предпочтение простых решений.

[gropox]

Зато можно было бы в одной транзакции отправить сразу несколько комментариев.

Так можно к примеру создавать опросы. Создать пост с вопросом и несколько комментариев под постом с разными вариантами ответов. Можно отправить все одной транзакцией, как единое целое. А не отправлять варианты ответов один за другим в блокчейн.

[afalaleev]

Comments

• Add constants
• comments window (200 seconds)
• comments per window (10)
• Refactor comment limits in comment_evaluator to use window and comments per window

Votes

• Add constants
• votes window (15 seconds)
• votes per window (5)
• Refactor vote limits in vote_evaluator to use window and votes per window

[VIM-Arcange]

Why not use delegate parameters instead of constants?
This would allow you to change the behavior of the blockchain without the need of a hardfork.

If so, you need to add lower and upper limits to avoid potential colluded delegates to block user's interaction with the blockchain by setting inappropriate values (big window value with low per windows value)

[afalaleev]

The main problem - these parameters are interrelated.
So, the blockchain should select a median in a sorted array of pairs.

The possible decision is to sort pairs by two directions:

• At first we sort pairs by value of window/items
• Then we sort pairs with same value of window/items by window

For example 5 delegates set values:

window  |  items | window/items
-- -- -- -- -- -- -- -- -- -- -
200     |  10     |  20
100     |   5     |  20
10      |   2     |  5
400     |   20    |  20
50      |   5     | 10

The result sorted array will be:

window  |  items | window/items
-- -- -- -- -- -- -- -- -- -- -
10      |   2    |  5 
50      |   5    |  10
100     |   5    |  20             <--- median
200     |   10   |  20
400     |   20   |  20

The result will be: 5 items per 100 seconds

Is it normal decision to select median for pairs?

[VIM-Arcange]

Then, you might solve this dilemma by making window a constant and items a parameter (or the reverse).

[gropox]

А почему не раздельно считать медиану? Понятно, что связанны, но высчитав медиану раздельно, ты придешь к "средней величине" так и так.

Вообще мне непонятно, как это будет реализовываться на практике. Надо для каждого пользователя будет хранить массив таймстэмпов нескольких последних комментариев, что бы динамически смотреть, сколько пользователь уже напостил за последнее время. Так как медиана может каждый блок меняться.

Не проще все же сделать через бэндвиз (#934)? И прочие ограничения снять вообще.

[afalaleev]

Сортировать по каждому значению совсем получится странное

100 10
100 50
200 2
200 20
400 5

После сортировки:

100 2
100 5
200 10       <--- median
200 20 
400 50

Такого варианта вообще никто не предлагал.
Результат может быть еще более неожиданный, чем в примере.