@nathansenn just informed me of a major flaw in the max_payout route @holdger08.
Users would be able to post to our Community & DAPP from 3rd party front-ends like Hive.Blog and @peakd with those Posts (Buzz's) being exempted from the max_payout code that we hardcode into our DAPP.
Users would then be incentivised to post to our DAPP from 3rd party front-ends and our real users would be punished by being restricted by in-house rules that are not applied to Buzz's posted from 3rd party front-ends.
Please review the proposal above and the issue more in-depth and comment accordingly @holger08.
3rd party front-ends as @peakd and hive.blog could be easily updated so that they allow setting of may_payout during posting.
E.g. @peakd could add a new option here to allow D.BUZZ content:
Hive.blog could also be updated and a new option for D.BUZZ content could be added here:
@peakd and hive.blog are already using
max_accepted_payout, just an option to set a value higher than 0 HBD needs to be added.edit: For implementation at @peakd and hive.blog, there should be an agreement about the value of
max_accepted_payoutfor D.BUZZ, so that only a new option in the drop-down menu is needed.That would be a temporary fix, and would require politics since new Dapps could arise that would launch without that "fix".
Then there would have to be a call to action by the community each time a new DAPP launches to pressure the newly launched DAPP to also instate that "fix".
Even if we solve this with temporary front-end fixes, don't you think we should also solve it at the blockchain level, once and for all?
Assuming a D.BUZZ post needs to have
max_accepted_payout=1 HBD. This would mean:max_accepted_payoutset to 1 HBD are D.BUZZ posts, no matter on which frond-end the post was writtenMy proposed changes are not temporary frond-end fixes. Agreement if a post is a D.BUZZ post is already defined at blockchain level. There is no way to cheat, either a post has the correct value for
max_accepted_payoutor not.If you or someone else that is more connected in the HIVE community can get Hive.Blog and @peakd to implement this change, of setting the max payout for posts published to the DBuzz Community to $1, please make it happen.
It would still be a temporary and somewhat messy fix since DAPPs could still launch, even tiny ones that are bootstrapped as simple services to game the system.
I believe if you were us or another DAPP wanting to offer a reliable service without interruption from rogue actors, you'd be interested in code that made it impossible to game the max_accepted_payout as opposed to relying on verbal agreements with others, and the belief that everyone else in the future would agree to those agreements too.
There is a way to cheat..
All of the posts published in our D.Buzz Community reflect onto our site so the posts published to that forked front-end would not be constrained to $1.00 payouts and would therefore trend higher than our real users who posted from D.Buzz.
Not sure you are really understanding how the blockchain works though. The frontend doesnt matter. Holger is saying that you should check the max_accepted_payout before considering the post as a valid DBuzz post. You also don't need to use Hive.blog or any other frontend to post to a community.
So if your website shows all posts in your community, that literally just means it is showing all posts with the category
hive-xxxxxwherexxxxxis your community number.Ah.. checking to ensure that the max_accepted_payout was $1.00 would block any rogue actors from posting to our DAPP since we would filter those out by checking.
It sounds like the only issue now is how to get Hive.Blog and @peakd to set the max payouts in our D.Buzz Community to $1.00, right?
People won't need to use Hive.Blog or @peakd to post to our community but we want them to be able to use both to post to our community so that our users will have more options.
I assume you mean there could arise a new service that allows posts without setting
max_accepted_payout? That problem will be solved with SMT (smart media token), there is no need to ask now for a different solution at blockchain level.Until our venture produces a sizable profit for a long length of time, we won't even consider issuing an SMT.
It wouldn't be in the interest of the people who'd buy our token, nor would it be in our interest to issue a token as a small business.
Some DAPPs like ours are / will be interested in building a HIVE based DAPP without the commitment of issuing their own token / SMT.
For ventures like us, SMTs won't help since we want to focus on using the $HIVE token.
I also think you are under estimating how fast a rogue act could and might launch a bootstrapped service to publish posts in our DBuzz Community without the $1.00 max_accepted_payout measure.
Communities allow moderation what's the concern?
Check the post see if it has a max_payout if it doesn't ... mute it.