Hive front ends should consider adding a default payout cap, just like d.buzz has.
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