Open a shared group in NAOMS and, by default, you are looking at a crowd of strangers. Not by accident — by construction. Members appear as name-less markers, and by default no name travels with them. That is the privacy floor we built this year. (A member who deliberately turns on a field in their join card does put a name in front of that group — but that is their choice, made per group, not the default.)

It is also, on its own, slightly useless. A room of anonymous dots is safe and unreadable. You will know some of those people — one of them perhaps for a decade. The interesting question is whether we can put those names back on your screen without putting them on anyone else's, and without asking any server, anywhere, who these people are.

That is what we built, and it is on the main line. Your device fills in the names. Only yours.

The shape of it

flowchart TD
  A["Your address book
people you already know"] --> C
  B["The group's member list
name-less markers, no names anywhere"] --> C
  C["Match, on your device"]
  C --> D["Match found
the marker shows your name for them"]
  C --> E["No match
the marker stays anonymous"]
  N["The network"] -.->|"nothing sent, nothing asked"| C

The dotted line is the whole article.

Why the markers can be matched at all

Each member is represented by a small one-way fingerprint, built from the person's permanent identifier mixed with the identity of the group. We covered how that is constructed, and why it looks completely different in every group, in a group that knows you're real without learning your name.

The part that matters here is the direction it runs. You cannot go backwards from a fingerprint to a person — but you can go forwards. If you already know someone's permanent identifier, because they are in your address book, you can compute what their marker would be in this particular group, and then check whether that marker is present.

So your device does the only thing it is in a position to do: it walks your own contact list, computes each person's would-be marker for this group, and looks for it among the members already loaded in your local view.

Some names appear. The rest don't.

If the marker is there, your device writes your own name for that person onto the node. Not the name they registered under — your name for them, the one in your address book, the one you'd recognise.

If it isn't there, nothing happens. The node stays a name-less marker. There is no partial hint, no "probably someone you know", no greyed-out silhouette that narrows the field. A person you don't already know is, on your screen, exactly as anonymous after this pass as before it.

That asymmetry is the design. The matching only ever moves in one direction: from knowledge you already possess, to a label on your own screen. It cannot manufacture knowledge you don't have. Someone with an empty address book sees a screen of anonymous markers and learns precisely nothing, which is the correct outcome.

Nothing left the machine

It would be easy to build this feature the ordinary way. Send the member list to a service, let the service — which knows everyone — return the names you are allowed to see. It would work. It would be fast. It would also mean that a server somewhere learns, every time you open a group, exactly which of its members you personally know. That is a social graph of your relationships, assembled as a side effect of a convenience feature, and it is precisely the thing we are trying not to build.

So the matching asks nobody. Nothing about who you know is sent anywhere — no lookup, no query to another member, no question put to a server. The matching works only on things already on your device: your contacts, and the markers already loaded into your local view of the group.

We want to be exact about the shape of that guarantee, because the tempting version of this sentence is stronger than what we can defend. The part that does the matching is a self-contained piece of arithmetic with no way to reach outward — it takes your contacts, the group's identity and the member list, and returns labels. Around it, the app does the ordinary things apps do to put a screen together, including loading its own code. What none of it does is ask anyone about your relationships.

We would like that property to be pinned down by an automatic check rather than by our word, and here we have to be honest: the check that exists today is weaker than it looks. It hands the matching function a stand-in network and asserts it was never called — but that function has no way to call it in the first place, so the assertion cannot really fail. The wider check, the one that would watch the whole naming path as it runs in a real browser, is written but not yet switched on. Until it is, the strongest thing we can truthfully say is that the code is shaped so that reaching outward would be conspicuous — not that something automatically stops us.

One more deliberate choice. If your device can't compute the fingerprints — an older client, a missing building block — the whole pass is skipped and everyone stays anonymous. The failure direction is always toward less naming, never toward more. A feature that degrades by revealing more than intended is not a privacy feature; it's a leak with good intentions.

"Known to me" must not become "known to the network"

The sentence the design keeps returning to is this: knowing someone is a fact about you, not a fact about them.

Most systems get this backwards. They treat your recognition of a person as data the platform now owns — a connection, an edge, a signal. Once it is on the platform, it is a fact about the relationship, visible to the operator, sellable, subpoenable, breachable. You did nothing but recognise a face.

Here, recognition stays where it started. The names you see are a rendering of what you already knew before you opened the app. Nothing new is created, nothing is uploaded, and the group itself never learns who among its members you happen to know. Two people can sit in the same group, look at the same markers, and see two completely different sets of names — with no way for either of them, or for the group, to find out what the other one sees.

This builds on ground we've laid before: what you share with the group doesn't carry your name is the floor this stands on, proving something without showing your birthday is how names come back deliberately rather than by default, and it follows the same instinct as a link that resolves to nobody's server — do the work on the device that already has what it needs, and ask nobody's permission. It is the same principle as your files staying on your own machines, applied to something less tangible than a file: the shape of who you know.

What's not done

Being straight about two edges.

Recognising the same person across several different groups — "these three markers, in three groups, are all the same friend" — is built and wired into the same screen, on the same on-your-device basis. What is missing is only the small piece of the interface that would tell you how many of a group's members resolved to someone you know. That count belongs to a separate piece of work that is genuinely still in progress, so we are not claiming the badge — but the recognition itself is not hypothetical.

And the honest limit on all of it: what we describe here is how the code on the main line behaves. We have read it closely; we have not yet watched it paint names in every client we intend to support, and one of those paths depends on a building block that has to be present for the pass to run at all. When it isn't, you get anonymity rather than a wrong name — but "we read the code" and "we watched it work everywhere" are different claims, and this is the first.

What is shipped is the one that matters most: open a group, and the people you already know have names. Everyone else is a stranger, and stays one — on your screen, and on everyone else's.

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.