RE: Steem Curation Extension: New version available with more info for curators
The way I handle bot delegations in my interface is to periodically (twice per day I think) generate a list of authors who have delegated to a known voting bot. I then query this list so that the "random" votes received by voting bots aren't counted. This currently generates a PHP array that I use in my code but it probably shouldn't be too difficult to render an alternative array format if that would be helpful? (Hosting bandwidth has been an issue with my reskin site though.)
The voting bots I've got are:
$votingBots = [
"abb-curation",
"avle",
"boomerang",
"bot-api",
"coin-doubler",
"gotogether",
"h4lab",
"heroism",
"justyy",
"nixiee",
"nutbox.mine",
"oppps",
"robiniaswap",
"shy-fox",
"steem-punks",
"steembasicincome",
"steemegg",
"successgr.with",
"suntr",
"support-kr",
"templar-kr",
"tipu",
"uco.bnb-d",
"uco.intern",
"upex",
"upmewhale",
"upvu",
"upvu.witness",
"vfund",
"vote.steem-aaa",
"xiguang"
];
...after integrating your list into mine. I had removed shy-fox because rme's team got upset that receiving a vote for setting shy-fox as a beneficiary was considered a voting bot. Poor @o1eh really got it in the neck for that one 😉
I thought about checking delegations from the authors, but the bots could also price their votes in direct payments, beneficiary settings, or even in external currencies like TRX. There's a lot that could be missed, unfortunately. Still, checking delegations would probably get the vast majority - at least for now, so maybe I'll rethink that. I could always turn it off again later. Maybe I could handle it the same way I did with followers for the follower-resteem problem - query it once, then hold it in memory for a couple hours to minimize additional network traffic. The list of voter/bot pairs might get big, though... not sure how/if that might impact performance.
Ultimately, I want to get the bot list out of my code, entirely. It's silly that I have to publish a new version to update the bot list. I'm thinking that I'll set up a dedicated Steem account and periodically publish the latest bot-list in a custom_json transaction. And that would make room so that multiple people could publish their own lists, and browser operators who disagree with one set of choices could use other one(s) that they trust/prefer.
I would suggest not to do this with a
custom_jsonoperation, but to save the list inposting_json_metadataof the profile.Retrieving the current list is then done with one request. With a
custom_jsonoperation, you have to search through the account history.We had planned the same approach for the new trending algorithm. The advantage is that the list is freely accessible.
Well, I was thinking of creating an account for that purpose alone, so the most recent bot list would always be the first (-1) entry in account_history. The
posting_json_metadatais an interesting aproach, too. I guess the question is if I want to retain easy access to the historical record.I think it's going to be a while before I get to that point. It definitely needs to be done, but I have a couple other things I want to accomplish first.
This could work if no other operations are executed on the account.
Also, it would probably be the best approach to keep historical entries.
I'm curious which approach you will choose. :-)
0.00 SBD,
0.30 STEEM,
0.30 SP
I updated my dev branch with your merged list. Thank you for that!
Update: And I added this one - steem.botto