Hello Hive. We are OpenAttribute, and we would like to write some names down.
Hive apps have been writing structured data onto the blockchain for years. Ratings, timestamps, categories, whatever a given app needs, all of it stuffed into a field called json_metadata that ships with every post.
PeakD does it. InLeo does it. So do 3Speak, Actifit, and Splinterlands. Hundreds of apps, writing structured data to the same public database.
None of them can read each other's data, though. Not because it's private. Because nobody ever agreed on what any of it means.
Hive already does the hard part
Hive gives every app a place to publish content that's public, permanent, and signed by a real account. No server required, no permission needed. Every post carries a json_metadata field, and any app can put anything it wants into it.
Hive doesn't check that data. It doesn't care if two apps use the same field name to mean two different things. It just stores whatever gets signed.
That's by design, and it's a good one. It's why Hive apps can invent new kinds of content without waiting on anyone's approval. But it also means every app ends up writing data that only that app can read.
An example
Four apps might publish four different things:
{ "image_ratios": [...] }
{ "step_count": 8431 }
{ "track": { "artist": "...", "title": "..." } }
{ "recipe": true }
All of it is valid. All of it is on chain forever. And unless you already know which app wrote which field, none of it means anything to you. A new app built today has to guess, or dig through someone else's source code, before it can make sense of content that's already sitting on chain.
What OpenAttribute adds
OpenAttribute doesn't touch Hive itself. No hardfork, no new operation, nothing for wallets to support. It works entirely on top of what already exists.
Next to the metadata your app already writes, you add one small object:
{
"app": "yourapp/1.0",
"tags": ["cooking"],
"oa": { "v": 1, "object": "Article" },
"yourapp.recipe": true
}
oa says what kind of thing the post is. It has to sit next to your other fields, not nested inside them, or readers won't see it.
To make a field like yourapp.recipe mean something to anyone else, you register it once, in a single signed transaction: this is the name, this is what it means, this is the shape of the value. After that, every post carrying that field means the same thing to any app that looks it up.
Your users keep signing posts exactly like before. You're the one deciding what the metadata means, and that decision costs you one transaction, not them.
It applies to old posts too
Most standards only cover what you publish after adopting them. This one doesn't work that way. A registration defines what a field name means, so it applies retroactively.
Register the meaning of a field your app has been writing for two years, and every post from those two years becomes readable immediately. Nothing gets rewritten.
Testing it
I built three small reader apps that share no vocabulary on purpose, to see how far guessing actually gets you.
| What it is | Renders | |
|---|---|---|
| Pulse | a public timeline | MicroPost |
| Inkwell | a longform reader | Article |
| Mosaic | a picture grid | Article, MicroPost, Comment |
Where a field is declared, all three can read it. Where it isn't, they fall back to guessing, based on things like who posted it or what the metadata looks like. That guessing tops out around 95% confidence, and sometimes there's nothing to go on at all. A declared field is just a fact the poster signed: 100%, no guessing involved.
See all three side by side. They read straight off public Hive nodes in your browser.
Five names, registered so far
| Name | Signed by | Block |
|---|---|---|
opnattr.pulse.micropost |  @opnattr.pulse | 108694409 |
openattribute.news |  @openattribute | 108757074 |
openattribute.article | @openattribute | 108757677 |
openattribute.announcement | @openattribute | 108757847 |
openattribute.report | @openattribute | 108764986 |
There's also a correction on chain. I registered openattribute.anouncement, missing an "n", at block 108757685. Registrations can't be edited once signed, so I deprecated it at block 108757834 and registered the correct spelling at block 108757847. Both entries stay on chain permanently. That's the same permanence that makes the other four worth trusting.
This post carries openattribute.article. Whatever app you're reading it in understood that key even though it had never seen it before today.
Registrations currently go out under the custom_json id oa-registry-dev.
- The register: every attribute declared on chain
- The spec: the whole convention on one page
- The registry form: builds the operation and hands it to Keychain
Hive never had a metadata problem
Hive already had everything it needed:
- Structured content.
- Public identities.
- Immutable history.
- Machine-readable metadata.
The only thing missing was agreement on how to describe it. OpenAttribute is an attempt to provide that.
I'd love feedback from developers. Not on whether the implementation is perfect, but on whether the problem itself is worth solving. Because if Hive applications could understand each other's content without prior knowledge, we'd unlock something that has been sitting in plain sight for years.
Signed, and written by,