EDIT: While I bring valid points below. The comments made me realize that this article was written on multiple wrong assumptions. Please read the comments before adding to the conversation.
D.Buzz is one of my favorite interfaces on #HIVE blockchain. While I switch between PeakD & Ecency all the time for my normal posts. The microblogging nature of D.Buzz makes it perfect to write short posts, read the posts of others & interact with them.
However, microblogs create unique problems on their own. They're easy to write and publish and most microbloggers write a bunch of them everyday. These posts tend to clutter the user's Posts section of their page in the other HIVE interfaces. The more varied/random your microblogs are, the less attractive your page will look!
Automatic Messages!
Another problem, as complained by 
- For more about this, read: Meet the "EMBED BUZZ BUTTON"
In this game, users could automatically make a post on DBuzz from the game itself that shows their progress in the game. That's a cool idea. There are two problems here:
- These automatic messages clutter the user's HIVE account with multiple blogs with questionable value, even on other HIVE interfaces!
- These automatic messages clutter D.Buzz's latest posts section as well. This is only a short term problem! Since #DBuzz is still small, many of us use it to see what others post and interact with them. I use these section to look for posts for my compilation!
I won't talk about the rewards these automatic messages get. Those being a good or bad thing is subjective and it's not one of the problems I see in this.
When
complained about Rising Star's automatic D.Buzz messages, I felt happy that I didn't have to do it myself. (I was waiting to see how things played out.)
Solutions?
One of the members of D.Buzz team, 
1. Burning Automatics Posts Rewards:
, that is, if they don't think the Buzz would result in quality original content.. this will solve #1 and the release date is targeted for January 2021."
I do think this is a step in the right direction, it's always good to let Dapps/games have the option to force reward burning so spammers don't use it as way to earn money. I do recommend Declining the rewards instead of burning them, so they go back to the reward pool.
But for me, the rewards are not a problem, at least not the immediate one that should be fixed.
2. Working with other Front-ends/Interfaces
The default for
(owned by
),
&
is that their users view both, by force, and they cannot opt-out of viewing short-form content.
We asked them to write the code, but this is crypto/blockchain, and everyone is busy.. it will get done now, and ASAP (first thing we will do in 2021, starting now).
While I think this will solve the problem we have now. This is a terrible solution in my opinion! Why?
- It requires too much communication for it to work.
- It assumes that all other interfaces will work along with you.
- It's a very slow process because other interfaces already have a roadmap for the next half year! Adding something like this will mess up their schedule.
- It assumes that you could actually communicate with all interfaces. That's not how decentralization works!
A solution for your interface problems shouldn't assume the interference of other interfaces for it to work. I know that many interfaces do solutions that require this, and they work. But I want you to think
I believe 
- If you made a decision after a public conversation, it'll will help if you linked to that conversation. When it's relevant to your comments about that decision.
- If you made it after a private conversation, please specify where that took place (Discord? Twitter? Encrypted Hive Memos?) Also the time-frame of that conversation so we could know the context behind it.
- Quote as much as possible from these private conversations! They may be private but there will be parts that the public should know, the decision affects them after all.
That I would say to any Hive developer who wants to be as transparent as possible, they don't have to do that, but it will add to their transparency and will let us trust them more.
3. Additional Thoughts
- I was thinking "if people had spare accounts for microblogs, the problem will slow down." My conclusion? Asking the players to create new accounts is out of question!
When I first started using D.Buzz, I realized that my account will be cluttered with small blogs, and my followers want to read my longer (+500 words) posts, so I'm only using my sub account:
for D.Buzz. You can't expect anyone to do this!
- Another thing I thought about is having a special tag. This might sound stupid but how about making all these add an additional tag (example: #autobuzz) so these automatic microblogs don't show up in the latest section of #DBuzz website. This won't solve the main problem, but at least will stop cluttering D.Buzz itself.
In short I don't have another solution to the problem, I only wanted to put what others have said and why I think we need to look for other solution. I also wanted to inspire a conversation out of this.
4. What About the Back-end?
I don't recommend enforcing a solution for the microblogs problem using the back-end. It's better to not rely on HIVE blockchain hardforks.
But I wanted to add, if the distinction between long form and short form posts was on the blockchain level, we wouldn't have to communicate with other interfaces. They will know which ones to show and which ones not to.
That's what I have today!
This response to the automatic microblogs was written with
If you have a problem with D.Buzz you can go to the platform's Discord server. You can also comment on any of my posts about it. I'm not a part of the team but I can message your problem to them.
Also, you can write posts like this one and send it to them or me. I'll make sure they read it!
If you have anything to add please comment! Even a stupid idea might be make the way for us to find the perfect one.