Four frontends. Four uploads of the same file. Four times my resource credits, four times my time. And now it sits on the blockchain four times over.
If you just want to chill and use social media without it turning into a job, that can be pretty exhausting. But it gets better, because the end result is that I look like the problem:
- Posting the same thing everywhere? Annoying.
- Cluttering everyone's feed? Annoying.
- Tripping the spam police? Annoying.
So the user pays. In time, in credits, in reputation. For what?
Why this actually happens
Not because users are spammy. Because frontends can't or refuse to read each other's posts. "I want it first."
Hive standardises how bytes get into blocks. Nothing standardises what those bytes mean. So every frontend invented its own metadata conventions, and each one renders the others badly. An InLeo thread shows up as an orphan comment elsewhere. A LikeTu gallery degrades to bare markdown. A poll is invisible outside the app that made it.
If your app can't tell what my post is, it can't show it properly. And if it can't show it properly, I have to post it again, in your app, by hand. Four uploads is the symptom. Not knowing what a post is, is the disease.
About those containers
Someone had to solve microblogging on a chain built for "posts." Sure, the daily container post was a genuinely clever answer at the time. Threads, Snaps, Waves, etc. — but yeah, also three (and counting) container systems, each one invisible inside the other two.
It worked. For frontends. For users, not so much. For developers, IYKYK. Never: let the user decide. And that's the part that should bother all of us.
Third-party clients like Snapie and HiveGrove are already posting into PeakD's Snaps container right now. They reverse-engineered an undocumented convention because there was real demand for a standard and none existed. Why can't @snapie have its own snapie.micropost or whatever? Don't get me wrong, it's not a dig at anyone. Absolutely not. But hey, we're matured, the metadata was always there, it's time to use it.
Who's going to revive Hive?
Because, honestly, if people are leaving, who are the ones who pick up the trash and start cleaning up? Right: developers. So let's start looking at what a new developer walks into.
I ran an indexer over live chain data and classified what I found: 35 distinct frontends, 982 objects, 19,574 events, and 120 cross-frontend interactions across 48 app pairs. One single account was publishing through 18 different applications (I believe this was @ecency -> Waves). Duplicate posts everywhere. Random container accounts. Some things declared, most not.
That's the onboarding experience for anyone who wants to build here. Noice.
Hey, actually a time to use and spell it like that.
We're all facing outward. I think it's time to face inward, and like I said before: you don't actually have to talk to each other, just do your part.
What OpenAttribute is
I didn't build the next super app, or the next thing Hive supposedly needs. Nothing here is new. To be blunt: it's always been right under our noses the whole entire time — metadata, plus a bit of accountability. That last part is basically just the human effort that is lacking.
An attribute is just a key in your json_metadata that says something true about your post. Duration on a video. BPM on a song. Surface on a stream. Nothing exotic, and nothing that breaks: apps that don't recognise a key ignore it, exactly like they do today.
OpenAttribute.app is a place to explain what your objects mean and what keys are attached to them (not posting/active keys), and to see what everyone else is already writing. That second half is the real point. Right now you find out another app writes duration by reading raw chain data or by knowing the right person. That works with five apps. It does not work with fifty.
And you can do all of this without me. Anyone can declare metadata. Anyone can read it. Anyone can build the same interface. There's no signup, no approval, no list of who counts. If OpenAttribute vanished tomorrow, every app that adopted an attribute would keep working exactly as before. What it gives you is visibility: who writes what, and how widely. Not a badge I hand out. Just what's already happening, in one place.
The ask
Register your attributes through OpenAttribute.app. That's it. Users experience nothing, nothing breaks, and legacy frontends go on ignoring what they don't recognise, same as always.
And then we can finally build the thing that fixes my afternoon: "Share this on Threads, Snaps, Waves, etc. too?" One upload. One post. One set of resource credits.
Think about it, and if you need help, you can find me on Discord or down below in the comment section.
Cheers :)
Ha, this one hits home 😅
Our Outpost front-end already reads five container systems — Snaps, Threads,
Waves, Hangs and D.Buzz — all reverse-engineered straight off the chain, exactly
like you describe. And then last week we cheerfully added two more undeclared
ones of our own (BBH Chats and Alive Pings). So yeah, we're both halves of your
problem 🤣
The reason I'm interested: it's one codebase serving two tribes (BBH and Alive),
config-only per tribe. So whatever we declare lands on both at once, and on every
tribe that comes after. Just made "read another tribe's feed" a one-line setting
this week — no code, no new container, nothing posted into anyone else's account.
Will register our attributes.
container: trueis already in there; theshort-form posts themselves are the gap, they carry nothing that says what they
are.
And am seeing the same error on your site as mentioned before here in the comments...
!ALIVE !BBH !MMB !INDEED
haha, I'm somewhat glad to hear this hits home.
And awesome, super excited to see this getting some traction.
If you register through OpenAttribute.app, the identifier is one thing, your account plus a name,
youraccount.leaf(account name is a prefix for verification/credibility, name afterwards is just the name for your attribute that serves as a identifier)This way, you can contribute as a developer, or as a frontend. In some cases it might be worth deciding which hat to wear. Front-end specifics (uniques) or developer specifics (efficiency/overlap/re-usable by yourself -and- others)
For example; borniet.micropost + property 'platform'
would be something like; render borniet.micropost from platform x(yz).
The register also provides a version and a short description of what it means, that's the whole form, and it's what gets shared with other developers as your own declaration. Basically anyone can use whatever you put on chain, some decide to hide it or make it as mysterious as possible.
One thing I'm curious about: when you say
container: trueis already in there, is that in your own config, or something that you already write on-chain? If it's internal, this is exactly the kind of thing a manifest can carry instead, and because you're config-per-tribe, one declaration covers every tribe on your codebase, current and future.More information - Support - Reports - Discord
Support engagement with a delegation to topcomment:
50HP - 100HP - 250HP - 500HP - 750HP - 1000HP - 1500HP
Hi 👋 @rubencress! Sounds like you’ve done some noodling on the in & outs of microblogging.
I still miss @dbuzz and really miss Chris & Nathan.
I went to kick the tires on your https://openattributes.app and tripped on an error. I’ll look later when the link 🔗 gets repaired.
Good luck with your project. 😎
Whoops! 1 S too many ;) Thank you for checking it out Alessandra. I'll update the post. Appreciate the pointer.
https://openattribute.app/
@alessandrawhite Someone got the dbuzz frontend up and running on a new domain. I don't know who it is but it's at: https://d-buzz.com
It's not very active though.
This is the kind of thing I find much more interesting than another attempt to make people “engage” more.
The part that really stands out to me is “you don't actually have to talk to each other, just do your part.” That's pretty much how I think decentralized systems should work. You shouldn't need every frontend, developer, or user to coordinate with everyone else. Give people a common standard, let them build independently, and make the information they produce legible to everyone else.
I've always thought Hive and Blurt are more interesting as semi-permanent records of people's work than as places to farm votes and rewards. The blockchain already has a huge amount of information sitting there. Making that information actually useful and interoperable seems a lot more valuable to me than creating more layers of behavior around the reward mechanism.
If this can actually get us closer to “post once, have it understood everywhere” without requiring everyone to agree on a single frontend, that's a damn good direction to be pushing.