You are viewing a single comment's thread from:
RE: Help Yourself! (steemit for dummies)
I answered a bit too quickly.
For your remark about it becoming less effective with widespread it's simple :
All bots will be voting sooner and sooner, each time a bot votes before another one, until they attain the limit (in my case 23 minutes) and all bots would "leave this author alone". Last bot to be just before the limit will stay (supposing all bots have the same limit).
And when all bots are gone, the author will go back to "normal upvotes" attracting bots once again. If there's no limit, it will ultimately push the bots to be the first to upvote (so right after the author publish his post at 0 minute), hence defeating the purpose of the bot itself.
Yes, but this behavior works if the times the other bots are upvoting are already known in advance (and they usually are right now, as far as I know). I was thinking of a more "interactive" approach, in which the future bots won't know when each other will be upvoting, by analyzing past data.
That's what my bot does, but if every body went from simple upvote after x minutes to this kind of interactive voting, that's what it would lead to (as after each vote, the current delay between post and vote of a bot will then be known by the other bots).
Do you take in consideration different upvoting scenarios, based on how upvoting for the analyzed post goes? You already mentioned you might consider tags as a distinction.
No, it's not yet real-time, when the post is published, I just put a delay on it depending of my previous calculations, but I'm not modifying it real time (or canceling it) depending on what happens.
It will be implemented as for tags, but I'm still in test phase for the "core" system.