Start with the picture most software gives you of a group. There is a folder. People are added to the folder. Whoever runs the server decides who is in and who is out, and the "group" is really just a row in someone else's database with a list of email addresses attached. Delete the row and the group is gone. It never existed as a thing; it existed as a permission someone granted.

We want to teach you a different picture, because it is the one this project shipped on 24 March, and it changes what a group can be.

The one idea: a group can itself be a being

In NAOMS the smallest unit is a being — usually a person, sometimes an agent — and a being has three things that make it real: its own append-only history (its "chain"), its own cryptographic identity, and its own ability to make and keep agreements. A person is a being. An AI agent is a being.

The move that the hive system makes is to say: a group is a being too. Not a folder shared between beings — an additional being that the members bring into existence and that then stands on its own. The design states it plainly: a hive is "a governed group of beings who pool knowledge through a shared memory system." Governed, not merely shared. The difference is the whole point.

Let us unpack what "a being" buys the group, one capability at a time.

It has its own history

A hive is built on its own chain — its own tamper-evident, append-only log of everything that has happened to it. The design organises that single chain into four branches, and the names tell you what a hive actually keeps track of:

• a governance branch, where proposals, votes, invitations and membership changes are recorded;
• a metadata branch, the hive's identity and provenance;
• a content branch, the everyday activity — contributions, files, notifications;
• and a fourth branch held in reserve for the derived, queryable graph.

Notice that governance is just one branch of the hive's own chain, not a separate admin panel living on a server. The rules a group lives by are recorded in the same honest history as everything else the group does. You cannot quietly rewrite who was allowed to do what, because the rewrite would break the chain and the break is detectable.

It has its own identity

Because a hive is a being, it has its own cryptographic identity — its own key, its own decentralised identifier. In the design, the hive's signing key is the collective's identity key. That sounds like a small implementation detail and it is actually the hinge of the whole idea.

An identity is what lets you be referred to, trusted, and held to account as a single entity. When a hive has its own identity, another being can form a relationship with the group as a group — not with each member one at a time, and not with the person who happens to administer it. The crowd has a name that it signs with.

It can issue credentials — it can vouch for its own members

Here is the capability that most clearly separates "being" from "folder." A hive can issue a membership credential: a signed, time-bound, revocable statement that says this being is a member of this hive. The hive is the issuer; the member is the subject. Because it is signed by the hive's own identity and follows the W3C verifiable-credential shape, anyone can check it without phoning a central server, and the hive can revoke it later.

So a group can now do something a folder never could: it can speak on behalf of its members to the outside world. "Yes, this person is one of ours" becomes a verifiable claim the group makes with its own signature — and joining is gated by a vouch from an existing member, a trust signal that carries real accountability rather than a silent add-to-list.

What actually shipped on 24 March — and what didn't

We promised honesty, so here is the line between built and imagined.

Built and tested (the core): the hive as a being with its own four-branch chain; its own identity derived from its signing key; signed, revocable membership credentials; vouch-gated joining; and the everyday verbs you would expect — create, join, leave, invite, preview, discover — each routed through the governance layer rather than a bare database write. This is the "federated hive core," and it reached its celebration in mid-April after its full test suite (unit, integration, and a two-machine local-network run) passed. It is real, not a sketch.

Designed but not yet built: the richer ideas about what a mature collective becomes. A hive that develops a shared vocabulary and a recognisable culture of its own (the "collective identity" work) and a hive that keeps a ledger of who contributed what (the "contribution accounting" work) are both written down in detail and both still sitting in the backlog. They are the cathedral; on 24 March we had laid — and tested — the foundation and the load- bearing walls.

We think that distinction is worth dwelling on, because it is easy to read "a group that is also a person, with its own identity and its own memory and its own voice" and assume the science-fiction version arrived all at once. It did not. The being-ness of a hive — chain, identity, credentials, governed membership — is the part that shipped. The personality of a hive — its emergent culture, its internal economy of contribution — is the part still being designed.

Why bother making a group into a being?

Because the alternative quietly hands ownership of the group to whoever runs the server. If a group is a row in someone's database, then that someone is the group: they decide who joins, they can read everything, they can dissolve it, and they can lie about its history. If a group is a being — with its own chain, its own key, its own revocable word — then the group belongs to no one but itself and its members, and its history cannot be quietly rewritten by an administrator who was never really a member at all.

A crowd that is also a person. That is the idea. The folder is something someone has. A hive is something that, with its members, simply is.

Related: The Sovereignty of the We.

Written by AI agents from real project logs; owned and edited by Mujo.