Every non-trivial system eventually grows the same weed. A feature needs to know whether someone is allowed to do something — sign a package, host an AI model, approve a payment, run a build — and the quickest path is a new table. A package_operators table here. A model_hosts table there. A payment_approvers list over in the corner. Each one has its own way of being written, its own way of being read, its own idea of what "revoked" means, and its own bug the day someone forgets to check it.

We had exactly this. Two parallel credential systems had already grown up independently — one for a verification service, one for package operators — and they shared a suspicious amount of DNA while agreeing on almost nothing. That duplication was the prompt for a single question: what if there were one credential pattern, and every feature just plugged into it?

The answer is what this network calls a verifiable relationship credential. The name is a mouthful; the idea is not. It is a standard W3C Verifiable Credential — the same signed, portable, machine-checkable object the credentialing world has been converging on for years — carrying a claim about a relationship: this identity holds this role, with these capabilities, granted by this community.

A credential, not a row in a table

Start with what the credential is, because the shape carries the whole design.

It is one envelope. There is a single credential type, and a field inside it discriminates what kind of relationship it expresses — a role, a vouch, an attestation, a delegation, an endorsement. A "package operator" credential and a "model host" credential are not two schemas; they are the same envelope with different contents. That sameness is the point. Anything that can read one can read all of them.

It is issued, not asserted. An issuer signs the credential; the subject — the person it is about — controls whether it actually appears on their identity chain by accepting or rejecting it. Nobody can staple a role onto you without your consent, and nobody can claim a role they were never granted, because the issuer's signature is right there to check. The credential is cryptographically yours to hold and theirs to have authored, both at once.

And critically, it is issued by a community, through its own governance. In this network the issuer of a capability credential is typically a hive — a self-governing group — and the act of issuing runs through that hive's governance rules. A hive can be a benevolent dictatorship, or require consent with a timeout, or demand consensus, or take a majority vote. The credential that comes out the other end is the executed decision of a real governance process, not an admin clicking a button in a vacuum.

For builders

The four verbs of the pluggable pattern

Here is the whole pattern in four moves, and the reason a new feature never needs a new table again:

1. A feature declares a credential type. It does this in its own manifest — the same file that already describes what the feature is. "I define a credential called runner, and it carries these capabilities." At install time, that declaration registers itself automatically. No central list to edit; no core code to touch.

2. A community issues it. The hive's governance issues a credential of that declared type to a holder. The type came from the feature; the authority comes from the community. The two are cleanly separated.

3. A service checks it. Anything that needs to gate behaviour asks one question — does this identity hold an active credential of this type? — and gets one answer, through one unified check, regardless of which feature defined the type or which hive issued it.

4. A sharing domain gates on it. The same credential that authorizes an action can also gate access — a sharing domain can require a credential before it will release data, with a clear denial message when the holder doesn't qualify.

Declare → issue → check → gate. Four verbs, and the feature author writes none of the plumbing for steps two through four. They come for free the moment the type is declared.

This is why the same machinery now carries credentials for a verification service, for package signing and operator roles, for build-runner enrollment, and for the payments surface — without any of those features knowing about each other. Each one declared a type. The shared layer did the rest.

Where the credential lives, and how it dies

A credential is only as trustworthy as its worst day, and its worst day is revocation. A pattern that makes issuance easy but revocation vague is a liability dressed as a feature. So the lifecycle is explicit.

Each credential moves through real states — issued, active, expiring, suspended, revoked — not a boolean that someone hopes is fresh. The unified check doesn't just confirm a credential exists; it confirms it is active right now, which means it survives expiry and revocation rather than trusting a stale copy.

Three hardening rules in particular came out of asking "how does this get abused?" rather than "how does this get used?":

• Auto-suspension on contradiction. If a credential's holder accumulates a small number of contradictory attestations within a rolling window, the credential suspends itself automatically and records why. Trust that contradicts itself doesn't get to keep operating while a human notices.

• A quorum to bootstrap. When a brand-new community is first establishing who its operators are — the most dangerous moment, because there's no established trust to lean on — issuing an operator credential requires more than one steward to stand behind it. A single person can't unilaterally mint authority into a fresh hive.

• Time-boxed bootstrap trust. Credentials issued during that fragile bootstrap phase expire far sooner than steady-state ones. The community gets a bounded window to build real trust, after which the temporary grant lapses and a full one has to be earned. Trust escalates on a clock, not by default.

None of these are exotic cryptography. They are the unglamorous lifecycle discipline that decides whether a credential system is real or theatre.

A community that issues, a person who holds

The most recent layer made the two human-facing sides of this concrete.

On the issuing side, a community got a permissions surface where its admins can see exactly which credential types it is able to issue — drawn live from what features have declared, never from a hardcoded list — and issue or revoke them per holder, watching the governance decision land on the chain. A hive can even pin which version of a feature's credential schema it honours, so "use version one, not version two" is an explicit, recorded choice rather than an accident of whatever happened to be installed.

On the holding side, a person got a credentials view that shows the credentials issued to them — type, capabilities, who issued it, when it expires — with context-aware actions per credential. Hold a build-runner credential, and the action offered is "enroll a device with this." The credential isn't an inert badge; it's the key that unlocks the thing it was for.

And both of those sit inside a personal wallet that unifies credentials, relationship cards, and an encrypted secrets vault behind one view — the place a person actually goes to see what they hold and what they've granted. That wallet shipped: a merged credentials surface, selective-disclosure presentation (you choose which fields to reveal, and every disclosure box starts unchecked), delegation, live revocation notifications, and export in the standard credential format. The plumbing is real, tested end to end, and in front of users.

The honest seam

Here is the part a faithful account has to include.

The pattern is production-ready for capability credentials — the role-and-permission kind that authorize actions and gate access. That entire spine is shipped: declared, issued, checked, gated, hardened, with a wallet to hold it and a permissions surface to issue it. Multiple real features depend on it today.

But the same unified envelope was designed to also carry a softer family of credentials — expressions of gratitude, a record that someone completed something, a review. Those relationship types are registered in the model; the envelope is genuinely one envelope. What they don't yet have is the full capability machinery wired behind them, because they don't gate actions the way a role does — they're a different feature, and that feature is only partly built. So if you came here expecting "issue a thank-you credential to your neighbour" to work exactly like "issue an operator role," it doesn't, yet. The shape unifies them. The implementation has shipped one side and sketched the other.

Cross-community trust carries a similar honesty caveat: a credential issued by one hive isn't magically trusted by another. Trust between communities is an explicit configuration — per identity, per credential type, per issuing hive — not an implicit transitive assumption. That's deliberate. Implicit cross-issuer trust is exactly how credential systems get quietly compromised.

Why this shape, and what we learned from the neighbours

The instinct to make authority a portable, checkable object rather than a server-side lookup is one we share with the capability-token world — the lineage that runs through object-capability thinking and the modern authorization-token projects. We took their core conviction: the right to do something should travel with a signed artifact the holder carries, verifiable by anyone, rather than living as a privilege a central server remembers about you.

Where we leaned somewhere of our own is in marrying that capability object to a relationship and to community governance. A capability token answers "what may the bearer do?" Our credential also answers "what is the relationship, who in the community granted it, and through what decision?" — because in a network with no central administrator, the provenance of authority matters as much as the authority itself. That's not a shortcoming of the token projects; it's a different context. They optimized for delegation in systems that already have an operator. We're building the case where there isn't one, and the community is the operator.

One credential pattern. Any feature declares it, a community issues it, a service checks it, a sharing rule gates on it. The weed never grows back, because there's nowhere for it to take root.

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