New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
litrbooh opened this Issue Apr 10, 2018 · 19 comments

Comments

Projects
None yet
8 participants
@litrbooh
Copy link

litrbooh commented Apr 10, 2018

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

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

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

@t3ran13

This comment has been minimized.

Copy link

t3ran13 commented Apr 10, 2018

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

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

@litrbooh litrbooh changed the title Уменьшить STEEMIT_MIN_REPLY_INTERVAL для комментов Уменьшить STEEMIT_MIN_REPLY_INTERVAL для комментариев Apr 10, 2018

@litrbooh

This comment has been minimized.

Copy link

litrbooh commented Apr 10, 2018

ыыыы, бесит!
default

@bitfag

This comment has been minimized.

Copy link

bitfag commented Apr 10, 2018

I support lowering of this limit as a quick solution.

@gropox

This comment has been minimized.

Copy link

gropox commented Apr 10, 2018

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

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

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

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

@litrbooh

This comment has been minimized.

Copy link

litrbooh commented Apr 10, 2018

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

@gropox

This comment has been minimized.

Copy link

gropox commented Apr 10, 2018

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

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

@gropox

This comment has been minimized.

Copy link

gropox commented Apr 10, 2018

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

@litrbooh

This comment has been minimized.

Copy link

litrbooh commented Apr 10, 2018

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

@litrbooh

This comment has been minimized.

Copy link

litrbooh commented Apr 10, 2018

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

@VIM-Arcange

This comment has been minimized.

Copy link

VIM-Arcange commented Apr 10, 2018

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

@gropox

This comment has been minimized.

Copy link

gropox commented Jun 25, 2018

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

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

@VIM-Arcange

This comment has been minimized.

Copy link

VIM-Arcange commented Jun 25, 2018

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

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

@gropox

This comment has been minimized.

Copy link

gropox commented Jun 25, 2018

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

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

@marijadia marijadia added medium and removed question labels Aug 16, 2018

@marijadia marijadia added this to the 0.19.0 milestone Aug 16, 2018

@afalaleev afalaleev removed the R&D label Aug 17, 2018

@afalaleev

This comment has been minimized.

Copy link
Member

afalaleev commented Aug 20, 2018

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

This comment has been minimized.

Copy link

VIM-Arcange commented Aug 20, 2018

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

This comment has been minimized.

Copy link
Member

afalaleev commented Aug 21, 2018

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

This comment has been minimized.

Copy link

VIM-Arcange commented Aug 21, 2018

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

@gropox

This comment has been minimized.

Copy link

gropox commented Aug 21, 2018

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

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

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

@afalaleev

This comment has been minimized.

Copy link
Member

afalaleev commented Aug 21, 2018

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

100 10
100 50
200 2
200 20
400 5

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

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

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

@maslenitsa93 maslenitsa93 self-assigned this Aug 30, 2018

maslenitsa93 added a commit that referenced this issue Sep 10, 2018

maslenitsa93 added a commit that referenced this issue Sep 10, 2018

maslenitsa93 added a commit that referenced this issue Sep 11, 2018

maslenitsa93 added a commit that referenced this issue Sep 11, 2018

maslenitsa93 added a commit that referenced this issue Sep 13, 2018

maslenitsa93 added a commit that referenced this issue Sep 13, 2018

maslenitsa93 added a commit that referenced this issue Sep 13, 2018

maslenitsa93 added a commit that referenced this issue Sep 13, 2018

maslenitsa93 added a commit that referenced this issue Sep 14, 2018

maslenitsa93 added a commit that referenced this issue Sep 17, 2018

maslenitsa93 added a commit that referenced this issue Sep 17, 2018

maslenitsa93 added a commit that referenced this issue Sep 18, 2018

maslenitsa93 added a commit that referenced this issue Sep 18, 2018

maslenitsa93 added a commit that referenced this issue Sep 18, 2018

maslenitsa93 added a commit that referenced this issue Sep 18, 2018

maslenitsa93 added a commit that referenced this issue Sep 18, 2018

afalaleev added a commit that referenced this issue Sep 18, 2018

Merge pull request #951 from GolosChain/533-battery-algorithm-for-com…
…ments-votes

New limits algorithm for comments and votes #533 #825

@afalaleev afalaleev closed this Nov 20, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment