You are viewing a single comment's thread from:
RE: Steem Curation Extension: New version available with more info for curators
Testing, testing, one two, one two...
Sorry if I'm a bit late, but I had to search for the installation instructions one more time... 😇
I am very, very pleased!
However, the ‘resteem problem’ that Michelangelo3 pointed out still exists for me (Brave).
Is the ‘pay-bot’ displayed on my tab SBI? In that case the info is imo a bit irritating. Like a kind of stigma... 😂
Hi, thank you for installing it and for the feedback!
I didn't add SBI to the bot list. Here's what I have (upvu.witness typo is fixed in my dev branch).
And I'm definitely open to suggestions for improving it. I think the ones that are showing in your count are "suntr" and "xiguang". I have the same sort of votes showing up on my posts, too. That falls under this caveat:
The other option is to remove those and leave a blind spot, but I thought it was better to show them and let the curator decide what (if anything) to do with the information. Eventually, maybe I can find some way to distinguish between paid and unpaid votes from those accounts, but I don't have a way right now. In my current dev branch, I relabeled "paid pct" as "% bot" in order to soften the tone. The intention is definitely not to create a stigma.
In your extension manager, does it show up with the date of Nov. 11? Maybe you were downloading while I was uploading?
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_json
operation, but to save the list inposting_json_metadata
of the profile.Retrieving the current list is then done with one request. With a
custom_json
operation, 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_metadata
is 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. :-)
It occurred to me today, if it's a dedicated account, all I'd have to do is follow the paid-voters and then check the account's followers list. No special transactions needed. I think that's the approach I'll take if/when I get to that point.
I updated my dev branch with your merged list. Thank you for that!
Update: And I added this one - steem.botto
Yes, that will have been the problem. Now everything works perfectly - thank you!
I still have mixed feelings about ‘bot filtering’. But I don't really have a suitable solution in mind either.
Perhaps the idea of displaying delegations, as you mentioned to Gorilla, is a good one. There are really ‘smart’ users who post spam once a day and then receive their big Upvu vote. Then they publish a ‘normal’ post and act as if nothing had happened. Displaying every delegation could also be too much. Perhaps it is possible to filter here too? If only delegations to proven bots are shown on the blacklist? But where do you draw the line? Many communities or community accounts automatically vote for delegations (e.g. ssg-community, steem-seven...). I would say that these are ‘bought’ votes, or at least promised votes. Do the operators who have automated their accounts see it the same way? Is it a reason to ‘discriminate’ against the users concerned? Of course, this is a decision that every curator has to make for themselves - now and in the future. In this respect, your extension is ‘simply’ a very welcome help, a decision-making aid.
I'll keep looking for ways to improve it. Maybe I'll play around with examining delegations and beneficiary rewards. Of course the voting services could always take additional steps to disguise the relationship, but maybe this is a decent start. We'll see.
Yeah, this is the goal. I want to arm the curator with information, but I'm definitely not trying to replace the human decision maker.