Most trust systems answer one question — "how trustworthy is this person?" — with one number. NAOMS won't answer that question, because the project decided the question is malformed. Trust here is not a property of a person. It is a property of a relationship, and a relationship has a direction, two consenting endpoints, a kind, and a weight. That decision — trust lives on the edge, not the node — is the foundation of the trust-graph model, and everything in the data model falls out of it.

Think of it like vouching for someone at the door. You can walk a friend in and say "they're with me" — and you can stop saying it tomorrow. It's a thing you do and can take back, pointed at one specific person, never a permanent grade stamped on their forehead for everyone else to read. Nobody can claim you vouched for them unless you actually did, and you can drop the vouch whenever you like. That doorway — one person extending trust to one other, revocably — is the single shape this whole model is built from.

This is the engineering walk: the actual shape of an edge, why both endpoints have to sign, why there's a hard cap on how many edges you can draw, and how cross-instance trust lets two separate NAOMS instances reach across a network and agree to share an edge at all. The status, up front and honest: the relational model shipped and was signed off this week; the cross-instance handshake landed only its Phase 1 on 2026-03-25 and, as of this writing, that work is still in progress — started, not finished. We'll be precise about which is which.

The edge is the unit

A trust edge is a directed link from one DID — decentralized identifier, a self-owned cryptographic name — to another. Its fields are small and deliberate:

• a source DID and a target DID — who trusts whom, in that order
• a trust type: vouch, attest, delegate, or endorse
• a weight in [0, 1]
• a propagation flag: transitive or terminal
• a consent proof from both endpoints

The first thing the schema enforces is direction. The uniqueness constraint is on the combination of source, target, and trust type, and the design states the consequence plainly: A→B is independent of B→A. Alice can vouch hard for Bob while Bob has drawn no edge toward Alice at all. There is no row that represents "the trust between Alice and Bob" as a symmetric quantity, because no such quantity exists. There are only edges, each owned by the being who drew it.

This is what makes the per-person score incoherent rather than merely unfashionable. A single number can't hold "Alice trusts Bob 0.9" and "Bob barely knows Alice" simultaneously without averaging them into a lie. Two directed edges hold both truths without contradiction.

Types carry meaning; weights carry force

The weight says how much. The type says what kind. NAOMS ships four trust types, each with a default weight encoding its structural force:

On top of the structural type sits a softer, open-ended signal kind — why the edge exists: relationship, completion, appreciation, feedback, attestation, and so on. "We shipped the sync engine together" is a vouch of kind completion; "thank you for the mentorship" is a vouch of kind appreciation. The structural type drives the math. The semantic kind preserves the human story so the edge can be explained, not just scored.

Consent is bilateral; revocation is unilateral

Here is the constraint that separates NAOMS trust from a follower graph: you cannot unilaterally declare that someone trusts you. Creating an edge requires Ed25519 signatures from both the source and the target over a canonical payload, and the engine verifies both signatures before the edge is ever recorded.

The asymmetry between creating and tearing down is intentional and, we think, morally correct: granting requires two, walking away requires one. Either endpoint can later revoke its side of the edge alone — you can always stop vouching. You need the other being's consent to form a trust relationship; you need no one's permission to leave one. A trust graph that let you exit only with counterparty approval would be a trap, not a graph.

Dunbar's number, enforced in the schema

Trust is finite, so the data model refuses to pretend otherwise. There is a Dunbar cap on outbound edges, configurable per being-type: 150 for humans, 50 for agents, 1500 for collectives. You cannot meaningfully vouch for ten thousand beings, so the system will not let you record that you did.

This is a small constraint with a large philosophical payload. A reputation score has no natural ceiling — you can accumulate unbounded endorsements, which is exactly why scores get farmed. A vouching budget is scarce by construction. Each person you walk through the door is one you can't vouch for elsewhere without first dropping someone. Scarcity is what makes the signal mean something.

The walk so far is the free preview. Below the line: traversal mechanics, the bounded search horizon, and the full cross-instance handshake that lets two strangers on two separate NAOMS instances draw their first edge — including the ECDH friendship-key exchange from cross-instance trust's first phase.

Edges to a network: bounded traversal

Direct edges are half the story. The transitive question is the interesting one: if Alice trusts Bob and Bob trusts Carol, what — if anything — does Alice's graph say about Carol?

The traversal primitive is a breadth-first hop-distance search that follows outbound transitive edges and stops dead at terminal ones. The transitive/terminal flag on each edge is the control knob: a transitive edge says "trust may flow through me to the beings I trust"; a terminal edge says "trust me, but do not follow my trust onward." That flag is how you vouch for someone without silently importing their entire trust network into your own.

The horizon is capped low on purpose: a query fans out only a few hops before it stops, not across the whole graph. The cap isn't a performance hack — it's a privacy and honesty requirement. Trust computed over a partial, local view of the graph means you never have to download the whole network to reason about your neighbors, and a tight horizon doesn't pretend to a precision that thin social data can't support. (The heavier propagation math — TrustRank, max-flow, EigenTrust-style schemes — was surveyed and deliberately deferred; the shipped v1 stays simple. That's a separate piece.)

Drawing the first edge between strangers

Everything above assumes both DIDs already live in the same graph. But two beings running two separate NAOMS instances start as strangers to each other's systems entirely. There is no shared database to insert a row into. So how does the very first edge between two instances come to exist?

That is cross-instance trust establishment. Its Phase 1 — the trust handshake protocol plus ECDH friendship keys — landed on 2026-03-25.

The shape of Phase 1 is a handshake that establishes a shared, authenticated context between two instances before either one writes a trust edge. The "friendship keys" are derived via ECDH — Elliptic-Curve Diffie–Hellman — so the two instances compute a shared secret from each other's public keys without ever transmitting a private key or trusting an intermediary. Once that authenticated channel exists, the bilateral-consent edge ceremony from the trust-graph model runs across it: both endpoints sign the canonical payload, and each instance records its own view of the now-mutually-consented edge.

A note on status, stated plainly because it matters: as of this writing, cross-instance trust is still in progress, not signed off. Phase 1 (the handshake plus ECDH friendship keys) is the piece that landed on 2026-03-25; the full cross-instance trust establishment — every later phase, the complete revocation-across-instances story, the production hardening — is not finished. Treat it as started this week, foundation in place, not yet complete. We're flagging this rather than describing a finished cross-instance handshake, because the difference between "the protocol's first phase landed" and "cross-instance trust works end-to-end in production" is exactly the kind of gap it would be convenient and dishonest to paper over.

Why it's built this way

Trace every property back to the first decision and the design coheres:

• Asymmetry (A→B ≠ B→A) is only expressible because trust lives on directed edges. A per-person score structurally cannot hold two opposing truths.
• Bilateral consent, unilateral exit is clean because an edge has two named, signing endpoints — two signatures to create, one to revoke.
• The Dunbar cap makes the signal scarce, which is what stops it from being farmed the way an uncapped score is.
• Bounded traversal keeps trust computable on a partial, local view — privacy-preserving by construction, not by policy.
• Cross-instance edges (Phase 1) extend all of the above across a network without a central registry, by bootstrapping a shared secret two strangers can both compute and neither can forge.

Related: Trust Is Directional: The Relational Trust Graph.

The reframing — from "how trustworthy is this person" to "how much does this being trust that being, in what way, and with whose consent" — reads like philosophy. It is load-bearing engineering. It's the difference between a number that can be gamed and a graph of consenting, directional, explainable, finite relationships that mirrors how trust actually works between real beings. The cross-instance work is how that graph stops being a single-machine artifact and becomes something two sovereign instances can extend toward each other — one honest, consented edge at a time.

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