A lot of software answers "who is in charge of this group?" with a single field: the owner. Whoever pressed create holds it. They can delete the group, hand it over, or lose their password and strand everyone else. Admins, if there are any, hold power the owner lent them.

This week the direction for NAOMS went the other way. Shared spaces are not going to have owners.

What a group is made of

In NAOMS a group (a hive) and each channel inside it keep their history on a chain: an append-only record where every entry is signed by whoever wrote it, so anyone holding a copy can check who did what. The question this work is about is simple to state. When a new entry arrives, what makes its author allowed to write it?

Until now, for many kinds of chain, part of the answer was "they created it". Each chain carried an owner identity, and a lot of code quietly asked "is this the owner?" before asking anything else.

The owner's instruction, given on 31 August, was blunt: "there is not supposed to be a chain owner", "there are only members", and a member "has a steward VRC or not" (VRC, short for verifiable relationship credential, is the project's name for a credential that records a role someone holds). The next day came the boundary. The idea of an owner stays only where a single person is the whole story: the owner of the machine, and your own personal record (along with the other one-person record types that sit beside it). For every other chain, "membership is to be done by VRC. the first one is just the first one to hold the steward VRC."

That last sentence carries most of the design. Creating a group does not make you its owner. It makes you the first steward, and after that you are an ordinary steward like anyone else who holds the same credential.

Two credentials, not one

On 2 September the owner corrected a working assumption and gave the model its final shape: "members have a membership VRC. only stewards can govern."

So there are two credentials, and they mean different things:

• Membership says you belong. It is what the group's rules look for when you take part as a member.
• Stewardship says you take part in governing. Holding it enrols you in the group's decisions, under whatever method that group uses: a single steward, a majority, everyone agreeing. The credential does not set the method. The group does.

A credential is a record that names who it is about and which role it confers. It is issued under the group's own rules (the founder's first pair is derived from the group's signed creation entry), and it can be revoked. That is the important difference from an owner field. A field is a fact about the past: this person pressed create. A credential is a present-tense claim the group keeps standing, or withdraws.

flowchart LR
  P[A person] -->|holds| M[Membership credential]
  P -->|may also hold| S[Steward credential]
  M --> A[Takes part in the group]
  S --> G[Takes part in governing it
under the group's own method]
  S -. revoked .-> D[Still a member:
stepped down]
  M -. revoked .-> R[Leaves the group]

Stepping down is not being shown the door

The owner's second ruling that day is the one that makes two credentials worth having: "somebody can go from steward to non-steward while still staying a member, or they can be move to not being a member, these are all possible changes."

These are two separate acts:

• Demotion. Revoke someone's steward credential and keep their membership. They stop governing and stay in the group.
• Removal. Revoke their membership. They leave.

If you merge them, one of two bad things happens. Either stepping someone down from a governing role throws them out, or throwing someone out first requires stripping their role as a separate ceremony. Real groups need both moves, and they need them to be different.

This had a concrete consequence for the person who founds a group. Until 2 September, creating a group gave the founder a steward credential and nothing else. The team's own ruling notes put the result plainly: revoke that one credential and the founder holds nothing at all, so "a founder can only be expelled, never demoted." The same day, creating a group started issuing both credentials to the founder, each with a fixed, predictable identifier, so replaying the group's history lands on the same records instead of minting a second pair.

A third ruling, "and must all be allowed in the GUI and CLI", turned this from plumbing into a promise. Stepping someone down and removing them both need a real button in the app and a real command in the terminal. That was added to the plan as its own milestone.

Channels too

A channel that runs its own affairs is, underneath, the same kind of thing as a group: a chain with members. Also on 2 September, the credential step at creation was moved into one shared place used for every chain type, with nothing in it that asks whether the chain is a group or a channel. A channel created on its own, outside any group, now gets the same two credentials for its creator that a group does. (How a channel then uses them to decide its own votes is its own story, told on 7 September.)

Two kinds of chain are deliberately left out:

• Your personal record, and the other single-person chain types. One person's key controls these, and a membership credential there would be ceremony with no meaning.
• Channels that inherit their parent group's membership, like a group's general channel. Issuing credentials there would create a second, competing answer to "who belongs?". On 2 September the code treated every channel created inside a group this way; which channels inside a group should inherit, and which should keep their own members, was settled the next day (see below).

The failure mode was chosen on purpose. If issuing the credentials fails, the error is loud, but the chain is still created, because the credentials can be issued again later at the same identifiers. The one outcome ruled out is silence. A chain without its founding credentials would look ownerless when it is actually broken.

Measure first, enforce later

There are many places in the code that currently ask the old question, and switching them all to the new answer at once would lock people out of groups they rightly belong to. So on the morning of 2 September the first step was not to enforce anything. It was a shadow probe: at the point where a write to a group is checked, the system also worked out what the credential-based answer would have been, and logged every case where the two disagreed, in both directions, because each direction is a different risk:

• An owner the old rule lets through, who holds no steward credential, is a write that would break the day enforcement is switched on.
• A credentialed steward the old rule does not recognise is someone the new rule would rightly let in, and the old one is shutting out.

The probe also refuses to round off uncertainty. If the credential lookup fails, it records "could not check", never "not credentialed". Treating an error as a no would make enforcement look safer than it is, and that is the one direction a measurement must not lean.

The code already held one warning about why this care matters. In one earlier measurement, 81 of 81 membership records on a machine carried no credential reference at all. A rule that simply required a credential on day one would have denied every membership on that machine.

Later the same day the check itself was rewritten in code. The old line said, in effect, "if the writer is the group's owner of record, allow". The new one says "if the writer holds an active steward credential, allow"; an owner of record without the credential is logged and judged like any other member, and a lookup that fails is never read as an allow but falls through to the older, narrower role checks. The probe's second direction was retired with it, since the rewritten check makes that case impossible. Making the credential lookup actually answer on the path that judges real writes took much longer: it was finished in stages and reached the main line on 26 September. So during this week the new check was not yet deciding anyone's writes.

Where this stands

Say it plainly: this is a direction and work in progress, not a finished feature. By the end of 2 September the direction had been approved, the rulings were written down, founders were being issued both credentials, channels created outside a group were getting them too, and a group's write check had been rewritten in code to ask for a steward credential instead of an owner. Terminal commands for the two acts, one to demote a steward and one to remove a member, were written that evening but had not yet been proven against a running system. None of this was on the project's main line until 3 September, when the work was merged. Moving every other authority check onto credentials, and a proven button for each act in the app, were still ahead.

One piece was settled the very next day. On 3 September the owner made inheriting the group's membership the default for every channel inside a group, not only the general one: "you must default to passthrough for every channel." A channel inside a group can still opt out and keep its own members; since then, only a channel that keeps its own membership, inside a group or outside one, is issued its own credentials at creation.

As of 25 September the work is still in its implementation phase.

What we find worth keeping from the week is the shape of the rule rather than any single change: authority is something a group grants and can withdraw, held by people as credentials, and the person who happened to press create is simply the first to hold it.

Related: Adding someone is not a row in a table · A group that knows you're real without learning your name · Taking a role away has to take it away

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

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