Sharing is the one thing every app makes easy, and it's worth asking what you're actually doing when you do it. You copy a link, you send it, someone clicks. Under the hood, that link almost always points at a company's server. Clicking it is a polite request: server, please look up what this refers to, decide whether this person may have it, and hand it over. The link is an address. The server is the authority. Take the server away and the link is a dead string.

We wanted sharing a NAOMS hive to feel just as easy — send someone a link, they join — without smuggling that authority back in. This article is about the first working piece of that: a share link whose proof travels inside the link, so the person receiving it checks it against nobody's directory and no central server.

What a NAOMS share link looks like

It's this:

naoms://share/hive/<hive-id>?t=<token>

share is a reserved authority in the naoms:// URL scheme — a sibling of the docs authority the scheme already had. The type after it (hive, and reserved room for space, channel, content) says what you're being handed. The interesting field is ?t=, the token.

That token is not an opaque lookup key. It is a signed invitation — a complete HiveInvitation record, minted by the hive's owner and signed with the owner's key, encoded and dropped into the query string. Everything a recipient needs to trust the link is in the link.

A small but load-bearing detail: the token is split off from the URL before the path is normalized. Invite tokens can contain characters that a naïve path-cleaner would mangle, so the codec pulls ?t= out first and treats it as bytes, not as a path. It's the kind of thing that is invisible when it works and a support nightmare when it doesn't.

The link carries its own proof

Here's the part that connects to a principle we've written about before — an identity that resolves to nobody's server. A NAOMS identity is self-certifying: its identifier embeds the proof of who controls it. A share link leans on exactly that property.

When your device receives a naoms://share/hive/… link, it does not call home. It:

1. Parses the link and pulls out the token.
2. Decodes the token back into the signed invitation.
3. Reads the inviter's identifier — a did:key — straight out of the invitation, and derives the inviter's public verification key from that identifier itself.
4. Checks the signature and the BLAKE3 content-id, and checks the invitation hasn't expired.

Step 3 is the whole trick. The key that verifies the invitation comes from the invitation's own did:key, by math. There is no key directory to consult, no server to ask "is this really from Alice?" The link is self-contained. If the signature checks out against the key the identifier itself commits to, you know the owner minted this — and you know it offline, on your own machine.

We were careful about tampering. The link's <hive-id> must match the hive-id inside the signed token; a mismatch means someone re-homed a real token onto a different link, and the verify refuses. Swap the token's bytes and the signature fails. Point it at a different inviter and the derived key won't match the signature. None of those forgeries reach the join flow. That refusal is the point — a share link is a bearer capability travelling over an untrusted channel (a chat message, an email), so the token has to authenticate itself, which is exactly why it is signed rather than merely chain-anchored like an internal invite.

There is one field in the link that is not signed, and we're upfront about it: an optional &relay= hint, a URL that tells a recipient across the internet where to reach the inviter's node through NAT. It's a transport convenience, mirroring a hint the connect-invite flow already uses. It carries no authority — the authenticated node identity lives inside the signed token. A wrong or malicious relay can waste a connection attempt; it can't forge a membership.

The loud refusal that protects you

Verifying the link proves the invitation is genuine. It does not, by itself, mean the join can actually be delivered — and conflating those two is how you get a hollow join: a membership recorded locally that no one on the other side ever hears about.

So the dispatcher keeps them separate. After the offline verify passes (the forgery wall), it checks a second, distinct thing: do we already hold an established connection to the inviter that we could deliver through? If yes, it accepts — records the membership, subscribes to the hive's delivery topic, a real join. If no, it does not quietly record a membership and hope. It fails loud, and says why. Recording member_of for a hive you have no path to reach is a green light with nothing behind it, and the Honesty axiom forbids it.

Two real CLI commands ship this today. naoms hive mint-share --hiveChainId <id> — owner side — signs the invitation and hands you back the link. naoms hive accept-share --uri <link> — recipient side — runs the verify-and-gate above. Both are thin presenters that hand off to a handler running inside the daemon, where the keys and the database actually live.

We proved it with a real two-daemon test, not a mock: Alice mints a link, and Bob accepts it from both sides of the gate — before he and Alice are paired (refused, correctly, with no membership written) and after (admitted). And a tampered token is rejected even when Bob is connected, showing the signature wall and the deliverability gate are genuinely independent walls, neither hiding a hole in the other.

How far this reaches — plainly

This is a foundation, and the roadmap says so in as many words: the codec and the router landed; "sharing works for everyone, everywhere" did not, yet. Here is the honest boundary.

What works today: an owner can mint a signed, offline-verifiable share link for a hive, and a recipient who is already a paired contact can accept it and join — with forgery ruled out by math and hollow joins ruled out by the loud refusal.

What's next, and named as next: the stranger-with-a-link case — you send the link to someone you've never paired with and they connect across the open internet and join — is the connect-bridge milestone, not a shipped one. On a single machine the peer-to-peer gossip mesh doesn't even form yet (a known, filed transport gap), so that path is validated on real multi-host venues rather than pretended into existence. Registering naoms:// as a clickable deep-link in the desktop, iOS, and Android shells, and a web fallback for people who don't have NAOMS installed, are later milestones still.

We could have shipped a link that points at a server and called it done in a weekend. Instead the link points at a person's signed word, checkable by anyone holding the same math. On a good day you won't feel the difference. On the day the server would have said no — or gone away — the difference is the whole thing.

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