RE: What if paid voting services provided truly passive ROI for their clients? Would this be an improvement for the ecosystem?
To me, the ideal thing would be for the top-tier stakeholders to take action and protect the ecosystem against the voting service abuse that is diluting everyone's stake and destroying the value of STEEM, but it seems that this is not going to happen.
My unlikely but not completely crazy hope is that Justin Sun will give some LLM-based agents a substantial stake of Steem and they could be convinced that the vote-bots are bad for the economy and be willing to take action.
The voting service automatically replies to their own daily post with a separate comment for each client where the comment beneficiary is set to that client's account.
They probably don't need individualized comments, they could just set the beneficiaries appropriately on a single mega-voted post.
Thoughts?
There are pros and cons to trying to make the abuse less visible. In the long run I think transparency is one of the core values of blockchain tech, so rather than paper over the problem we're probably better off leaning in to that and letting the ugliness be visible until someone tries to fix it.
That would be entertaining. It sounds like Tron's first pass at LLMs was less than optimal, though.
Yeah, I was thinking that too. Not sure how many beneficiaries you can put on a single post, but they could definitely reduce the number of posts.
I guess that's what happens when you use steemit.com as your training data 🤣
I'm surprised that he made his previous post about "groundbreaking" AI with Tron and Steemit if he hadn't seen the LLM product yet... Unless the previous post was referencing something totally different (which I sort of doubt).
Yes, good point. Creating a LLM isn't groundbreaking in the slightest... so the either it's not groundbreaking, or the way he's planning to apply it is. I'm guessing the former.
Looks like the max number of beneficiaries per post is 128.
Does that work for you? My broadcast operation rejects anything more than 8 so maybe that's an API restriction.
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).