Such a reward cap would need to be implemented on peakd first. Not sure if it is that easy.
And if voluntary, do you think that especially the shitposters would adhere to it? It is like with gun laws, the law abiding people are compliant, and the ones for which the laws are made, the criminals, they don´t care about them.
You are viewing a single comment's thread from:
Think about it this way.
X = number of users just posting like normal on other social sites.
Y = number of users making low effort posts to farm rewards.
Z = number of users who need to be downvoted when their low effort posts get big upvotes. Without default cap, Z = X + Y.
If X don't bother to change their defaults or have only modest increases on default (the norm on d.buzz), then Z = Y, and Z < X + Y. That means it takes less effort to police Y, because there is no need to downvote X as well.
Y also lose plausible deniability, they can't claim they're being bullied off the platform for no reason.
We can ask @dbuzz, @chrisrice if implementing a default cap is easy. I expect it's actually just a few lines of code at most. Though it would need to be implemented by peakd.com, hive.blog and ecency at the least (three largest front ends).
I think PeakD.com already has a max-accepted-payout option.
The #1 issue related to max-accepted-payout is that curators get harmed on posts that earn more than the max.
That is why we switched the 0 setting to burn instead of max-accepted-payout. Needs blockchain level change.
Posted via D.Buzz
As far as I can see @peakd does not have this feature.
Interesting, I remember seeing it on some of the other front-ends.
That was over a year ago and it may have been Hive.Blog.
Posted via D.Buzz
Indeed Hive.blog does have it.
Cool! cool. Maybe I only saw it there and assumed all top social media platforms on #Hive had it.
Posted via D.Buzz
If a front-end adds this default-payout-cap option, they should perhaps also adjust their trending algorithms (e.g. to exclude posts that don't adhere to the cap) and/or add a filter so that users can set their own thresholds and filter out (from their feed) any posts that exceed a certain payout cap.
Ultimately, I think the key is having front-ends provide end-users greater info about posts / authors (e.g. circle-voting metrics) and let end-users easily filter out content that they don't want to see.
Also, I am curious as to what happens when curators vote above the author-chosen payout cap. Do they still get their curation rewards, and the excess author rewards get burned? Or does a curator who over-votes a capped post simply lose all or part of their curation rewards?
Maybe @chrisrice or @nathansenn know the answer to that question ...
The default ranking algorithm on hive.blog and peakd.com actually already account for this, as you can see if you look at d.buzz community on hive.blog or peakd.com.
Edit: misunderstood the first part of your comment. Filters are good in general, but I don't think they need to default filter based on the cap, because many users will have legitimate reasons to raise their cap (high effort posts, for example).
I think but can't say for certain that the curators end up splitting a smaller curation reward if the post exceeds the cap. I think basically all curators get cut in the same way. Curators will thus need to be more careful about how they vote, but IMO that is a positive thing. Lazy voting and auto voting should be discouraged. There will still be just as much curation rewards up for grabs as before, it will just take greater care to get your max rewards.
My understanding is that the excess remains in the pool.
But if what you’re saying is true, that all curators get cut equally, then voting on such a post risks that some lazy voter after me will over vote and cost me an unknown (and perhaps large) portion of my curation rewards.
It looks like it does work that way. Aside from the one late voter, and some smaller votes that might be affected by rounding errors, everyone got the same rewards per rshare.
It's not ideal, because it does mean there's a risk of getting a lower reward per rshare when you vote on a post with a cap as opposed to an uncapped or very highly capped post.
There are ways to fix this but it goes straight back into hard fork territory 😕
Edit: A not too complex fix is to use current curation reward logic but apply rewards on a first-vote-first-paid basis. Thus only late voters are penalized when there is a cap. It's still a hard fork.
I will try and double check if my understanding is correct. I have an example here of one of my buzz's that would have gone over the cap, later in the day I'll look into it to see how it worked out for curators.
https://hiveblocks.com/hive-193084/@demotruk/1f7uq9p6yx7anq7ln61xgp
@trostparadox pointed out an issue we noticed in 2020/2021
We were interested in a change at the blockchain level that switched the algorithm for max-accepted-payout settings to burn author rewards above the max instead harming curators
@dbuzz may submit a PR for this. #HiveCore
Posted via D.Buzz