You are viewing a single comment's thread from:
RE: What if paid voting services provided truly passive ROI for their clients? Would this be an improvement for the ecosystem?
Nope. Just discovered last night that python is also limited to 8. So far, I don't understand why. That throws a big monkey-wrench in my plans.
Yes, I’m sure everything could be automated across more posts / comments… and I guess 1 post instead of 8 will significantly reduce the spam still. But if the blockchain / hivemind says 128, then maybe a custom hosted API that doesn’t impose an 8 beneficiary limit would be the best approach.
My goal is near-0 spam😉. With or without 128 beneficiaries, I think this has some pretty big implications.... look at the beneficiaries and the dates of the curated posts.
Ah, interesting. It just goes to show how good Steemit authors used to be 😆
How different would that look if you only included users who are still actively posting? (so excluding users who still only vote via a curation trail.)
It would be nice if something like this were able to reignite some of those old authors - my suspicion is that they're all long gone though.
Yeah, I'm noticing that I almost need two sets of filtering criteria depending on how old the posts are. If I set it to catch a reasonable number of posts in 2017 or 2018, it doesn't catch much in modern times. As discussed in the other thread, I think I'm definitely going to start with the past-payout stuff. This is another reason. Maybe content will start to improve if people start to see a longer-term reward opportunity(?).
Even letting the curation trails stay, filtering out inactive users really reduces the number of posts that it finds by a lot (especially if I also filter accounts that have been active on Hive).
I also suspect that a lot of them are gone permanently, but not all - I hope. A lot of people go away for a while and then pop back in a year or two later, so they'd have a surprise waiting for them if/when they do. Though a problem is that Steemit wallet doesn't show beneficiary rewards, so when they get back again, they might not even know where the rewards came from.
I would definitely have a bias of quality over recency - even if it means that nothing recent gets shared - for exactly the reason that you mention (putting more effort in due to the longer-term reward opportunity). That might even prompt somebody like me to prioritise the content that you share with this exact objective in mind.
Good point and probably an important one. I won't want to be voting on something, knowing that the STEEM will just get sold to buy HIVE.
I think that's a feature that you should suggest to symbionts with their Wallet upgrade proposal. I know that the wallet is limited by the number of transactions that it shows but I see little reason why the beneficiary transactions shouldn't be included in the feed (i.e. show the author and post that the beneficiary came from).
Of course that would be easy enough to dodge, just by using different account names, but at least it will filter out the historical posts from people who are/were actively hostile to Steem. I'm excluding hive participants during testing, and I'll play it by ear after that. Maybe it's just as simple as labeling the author's information with their hive inactivity time and let the voters decide how to reward it.
I suppose I could include posts from inactive accounts and hive participants in the output but send beneficiary rewards to null, but that starts to feel kludgy. Also, there are some hive participants who are decent contributors here, too. Handling that situation in the long term will be challenging. "A few bad apples spoil the bunch", as they say...
Good idea. I will do that.
Ah... found this issue from 2018: Increase Reward Beneficiaries Soft Cap #2162:
And further down:
No idea why they implemented a soft cap, but that seems to be the challenge...