During our Pre-Launch announcement of D.Buzz it came to our attention that there are members of the HIVE community who are concerned with short-form content being used to abuse the reward pool.
People like @jonsnow1983, @trincowski, @ash, @jocieprosza, @belemo and @joanstewart all expressed concerns about this and @chrisrice (Coordinator of @dbuzz) believes their concerns are justified.
He reached out to @hiddenblade, @guiltyparties and @hivewatchers who all made various suggestions and recommendations. The final consensus of a "Hive Keepers" group chat on Discord was that we must redo much of the @dbuzz Dapp in favor of Buzz’s (our version of Posts) being published in the Comment section of people’s Profiles instead of the Posts section.
Besides delaying our project launch by a couple weeks at minimum, @nathansenn (Lead Investor / Blockchain Developer) had this to say about that idea.
By making all posts in D.Buzz comments on a post inside our community, we lose the neatness of having many posts from different users inside our community on other platforms such as Hive.Blog.
We also lose the Trending features that are built into the communities.
I am also concerned that opportunists would take advantage of the lack of posts in our community. To try to post garbage or other spammy, scammy types of posts in hopes that it would be seen by someone viewing our community on other platforms due to the lack of posts in the main feed.
We want people to use our Dapp on D.Buzz but also want people to be able to interact with it on other platforms such as @peakd and Hive.Blog.
The mechanics of doing it through the comment route feels a bit like jerry-rigging our Dapp to adhere to some unwritten protocols instead of using the current protocols that are currently the standards for communities.
I think if the Hive community wants social media Dapps but is concerned about the reward pool abuse, a protocol change needs to be made at the Hive blockchain level where posts made to the chain would be given a type such as Blog, Video, Image, Short-form, etc. The rewards for short-form posts and other types of social media posts of the likes could have adjusted rewards.
My last concern is that if we decide to use comments for posts, people will build bots to upvote comments as the Dapp becomes more popular, defeating the entire purpose.
Our team is open to changing to use comments for the post made on our Dapp but do not feel that this is the best way to do this.
The community wants a social media platform such as D.Buzz.. the question is, how do we work at making social media Dapps on HIVE and prevent reward pool abuse?
In light of this, we are proposing that @blocktrades make a change to the HIVE blockchain that separates each post into categories such as but not limited to:
- Blog
- Image
- Video
- Short-form
If you are in favor of this proposal please vote for it here.. the funds will be sent to @blocktrades if approved.
ABOUT OUR LAUNCH:
We will be launching D.Buzz this week w/Rewards set to Decline for all of our users. This temporary status (one week) of declined rewards is intended to promote public discourse so that we can eventually activate rewards without risking public backlash and heavy downvotes from curation groups and abuse fighters such as @hivewatchers. Please let us know in the comments if you think:
We should extend the Decline Rewards for @dbuzz users for another week after the 1st one expires.
We should activate rewards after the 1st week of Declining Rewards is over.
Give us feedback w/different ideas.
Again, be sure to vote on our proposal if you think policies should be written at the blockchain level and that @nathansenn’s suggestion would help onboard the masses via additional social media Dapps like D.Buzz joining the HIVE blockchain.
P.S. Contact chrisrice#2989 on our Discord if you want to discuss this with @nathansenn via audio or video. He is open to interviews and can discuss this in a public forum.
I think there is no need to modify the Hive at the blockchain level as there is
max_accepted_payout. This parameter can be set between 0 and 1000000 HBD.For short-form content, this parameter could be set to 1-5 HBD and the post payout will not exceed this. Everything above this threshold will be returned to the reward pool.
You can see here how it looks when the parameter set to 1 HBD:
https://peakd.com/hive-174578/@abitcoinskeptic/experimenting-with-max-accepted-payout
When auto voters are checking this parameter, it can be used to mark a post as short-form content.
@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.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.
Exactly.
There is a major flaw in trying to use the max_payout to solve this problem.
This sounds excellent.
As it turns out, the max_accepted_payout route would not work, here's why:
Please help us bring attention to this proposal.. I think it's the only fix and a much needed one at that. Otherwise Dapps like us would also be forced to get involved in politics and in vain when the solution really lies in solving this at the blockchain level @brianoflondon.
This is what I was about to type in when I read the proposal.
It seems like the max_payout would work, but it wouldn't and here's why:
Please consider the above scenario and comment / share accordingly.
Thank you for also sharing, and for being in favor of using the max_payout feature to prevent abuse.
max_payout feature would only be affective if they used in our front-end anyone using other platforms we would not be required to set max_payout.
HECK yeah. I think this is a much better approach than trying to hack it. I want DHive to win and it shouldn't be penalized by the format that you use.
Thanks @crytpoctopus, I hope other people will see that too!
Thanks for the mention.
Yes, I fear that such a platform can lead to a lot of unnecessary spam... but posting on the comments? I don't think it's the way to proceed as well. That would be unfair. Freedom should be the main thing in this platform...
Maybe we should simply allow the community to deal with those posts as they see fit. We already have tools like downvotes, limits to maximum rewards per post, declining payouts...
... and I'm sure it would be simple enough to change Hive Vote to ignore such posts... (@mahdiyari, @steemauto, is this possible?)
Thanks for taking in consideration my concerns.
I just realized that @nathansenn is right.. the max_payout route won't work, at least as it is now:
We are being told to fall in line with a political system when a fix at the blockchain level would fix this once and for all.. with the max_payout code as it is now, the solution mentioned by @holger08 would NOT work.
Hopefully the Community and stakeholders will come together to solve this once and for all, so that other DAPPs like ours can start building on $HIVE.
Yeah, and in the end, @nathansenn thinks it wouldn't even solve the problem since bots would be created to also upvote comments if our DAPP became successful enough.
Yeah, mamximum rewards per post would probably help a lot.. I am glad you are in favor of using that.
I contacted @mahdiyari via Discord and he was against it. Maybe he will change his mind though.
You're welcome.. we are here to create value, not damage the value that is already here.
I like the max_accepted_payout feature as mentioned by @holger80. I guess the next big discussion would be where to set it 1-5 HBD.
As it turns out, the max_accepted_payout route would not work.
Here's why:
Please help us gather attention on this, we were scheduled to launch today but this issue delayed us.. if it delayed us, it will delay other DAPPs too.
Thanks for the reply, Always a way around with code.
I wonder if your DAPP could cryptographicaly sign posts so third party posts could be detected and dealt with by groups like @hivewatchers. When you attach token benefits to users using the DAPP the signed posts would be detectable and therefore properly dealt with.
Just my 2 cents worth
I personally feel that you should be able to do as you please. That being said after reading some comments I would say using max_payout is the most logical solution to mitigate abuse at the moment, just so as you mention it when people post just they know what to expect.
The problem is what is an acceptable payout for shortform content? It's entirely subjective. Personally I feel up to $10-15 seems fine.
@nathansenn just pointed out something and he's right . . the max_accepted_payout route would not work as @holger08 intends.
Here's what would happen:
Please help us gather attention on this . . we are being asked to play politics when the solution is a change at the blockchain level, not limiting ourselves in ways that are not coded into the blockchain.
Ahh yeah that's definitely a problem. Looks like the only route at this time is protocal change or people just accept the fact that if they want dapps they have to accept the way they do things or change the blockchain to suit.
I'll vote for the proposal in this case as this'll help more than just this dapp.
The best option that I could think of so far is posting the buzzes as comments and not posts. Just like how @anonramblingscom posts a daily placeholder and all buzzes will be posted as comments. It will pretty much look like a mess while using peakd or hive.blog but the good thing there is that people will use Dbuzz more often.
There's always gonna be spammers. All you could do is mute them after warnings.
I disagree with this one. There are several short posts that I see that I think deserve the rewards. This could be a one-photo post or a video with less text. Or one-liner text that received a lot of engagements. The length of a post doesn't define the quality of it. We can't limit the rewards for short-form posts (in general) on a blockchain level just to adjust to a new dapp as it would seem unfair and would sound like it will defeat the purpose of the blockchain.
I could say limiting payouts that are posted on Dbuzz is okay, but there's no need to do it on a blockchain level as still, quality is subjective.
Abusers are always there and they will always make a bot for that. If they want to abuse, they will always do what they can to abuse. My suggestion would be: have something like a section where you could see trending buzzes based on payouts and the community can decide to give them downvotes or not.
The trending buzzes based on payouts could probably solve this.
Or those adjustments could probably be made specifically in the Dbuzz community? So whether they use hive.blog or peakd it will be applied when it's posted there. I'm not sure if that's possible though.
I think best practice is to use a 2nd account for buzzing any ways. Even comments can clutch up your account, especially when you search for blog comments. So my plan is to use another account, and I think max payout is a good way to progress. No need to interfere with a hardfork imo
As it turns out, the max_payout feature won't work.
This should be solved at the blockchain level or it would require a change to all existing front-ends and future existing front-ends.
Here's why:
Please help us share the message so that more people can start discussing this. If we solve this, it would likely increase the value of the HIVE blockchain, since as it stands now, it's broken.
Using a 2nd account is one option and I think that could work, but a lot of people value the idea of having one account for all front-ends.
And I think if everyone comes together and the best solutions rise to the top, we can find a way to do that.
Trying to get a change at the blockchain level sounds like it would delay this by quite a few months as who knows how long that would take if it was even accepted by the community to do in the first place. As that sounds like it would require a hardfork so could that even be doing by the end of this year?
I personally would prefer just using a second account. Regardless if there was a limit on post rewards or not if you are going that route.
While at first I thought “why not just make them all comments or give an option to make Tweets comments instead.” I would agree it be limiting the growth of this project if they could only comments.
I do sometimes wish if I was commenting on a Tweet that had a Hive link that it would auto post it to the blockchain as a comment on that post for me.
Thanks for the support @enjar.
I wanted to add that @nathansenn just pointed out a fatal flaw of @holger08's idea of using the max_payout features to prevent abuse and limit payouts.
Please help us get some people's attention so that this can be solved once and for all.
Congratulations @dbuzz! You have completed the following achievement on the Hive blockchain and have been rewarded with new badge(s) :
You can view your badges on your board and compare to others on the Ranking
If you no longer want to receive notifications, reply to this comment with the word
STOPDo not miss the last post from @hivebuzz:
Support the HiveBuzz project. Vote for our proposal!
Will you guys have keychain support as well? I hate giving authority when keychain can do the job.
Yes, we will :)