Skip to content

Reaching a Sovereign Box: Sealed Over a Dumb Relay

How a phone reaches its own box across the open internet — by identity, not by IP — sealed end-to-end, bilaterally verified, over a relay that can read nothing, while the box sits behind carrier NAT with no inbound port open at all. Where Reaching a Raint explains how a runtime proves who it is, this page explains the transport that carries that proof across a network you do not trust. Builds on Keys Never Leave Your Machine and Route Posture, Not a Trust Score.

Nothing below is a mock — every frame is a verbatim reply from a live node. But it is an explanation, not an invitation to poke something of ours: you reproduce it by running the stack yourself.

The claim

A device can reach its own box by identity, sealed end-to-end, bilaterally verified, over a relay that is a dumb rendezvous and never an authority — with no inbound port on the box. The middle can move, break, or be swapped for another; the keys are the authority, not the network.

If that holds, your box is reachable from anywhere without punching holes, without trusting the middle, and without a company in the loop. That is the whole point of the overlay.

The shape of it

  your device                      dumb relay                     your box (dark, Layer 0)
  you.aint      ── sealed ──►   /api/edge/*    ── held lane ──►   box.aint
  (your identity)               content-blind                    (behind NAT, NO inbound port)
                                sees only TBZ blobs              holds an OUTBOUND lane; answers sealed
  • The box holds an outbound lane to a relay and never listens for a connection. Dark by default.
  • The relay is any host running the edge endpoints — another box, a peer's node, a small VPS, or in principle your own phone. It is a rendezvous you choose; it is not part of the trust.
  • The device seals a request to the box's static X25519 seal key, routes it to the box's .aint, and opens the sealed reply — verifying the box's authorship against the key it pinned at pairing.

What the wire actually says

The box opens a trusted lane — admitted by posture (a proven, capable identity), not by IP or a trust-score number:

{ "frame": "0x4000", "state": "trusted/alive",
  "sealed": true, "note": "lane opened — you are on a trusted lane" }

The relay refuses anything that is not a sealed carrier. A probe of raw bytes:

{ "frame": "0x7000", "state": "rejected", "intent": "foreign/disguised", "note": "bytes do not prove …" }

It is content-blind, but it still insists that what it carries is a real TBZ sealed envelope — it forwards ciphertext, never plaintext.

A real sealed request routes to the box's live lane, and the box answers within one tick:

{ "frame": "0x4000", "state": "routed", "intent": "sealed-tza", "surface_name_ignored": "box-status-req" }
{ "landed": ["…"], "routed": ["boxstatus-…tza"], "deferred": [] }

The relay routes the opaque blob and ignores the surface name — it has no idea what the message is, by design.

The device opens the reply and verifies the box's authorship against the pinned key:

REACHED   ·   authorship == pinned node-key: TRUE

REACHED is the whole ballgame: a signed, decryptable, authorship-verified reply came back over a relay that could read none of it.

The relay is interchangeable — there is no central authority

This is the point worth keeping. To the relay, every payload is opaque; it routes TBZ blobs by their destination .aint and cannot read, forge, or splice them. The authority is the keys: the X25519 seal (only the recipient derives the tunnel key — a wrong recipient gets an AEAD failure, not a rejection) and the Ed25519 authorship signature, checked against the node_pubkey pinned at pairing.

So the relay is swappable. The pairing card carries the relay address sovereignly, so every relationship picks its own middle — and running that middle is a small, content-blind service you can host yourself. There is no single point everyone must trust; only the one you choose, running code you can inspect.

The honest nuance: identity admission to a relay is checked against that relay's own registry, so "no central authority" is exact for the data (sealed; keys decide) and for the topology each relay is its own sovereign. That is federation, not a hub.

Why it is a thin layer, not a heavy stack

The overlay does not reinvent the stack. It is a copy-on-write-thin layer over what is already there: the identity is your existing keypair, the seal reuses the airdrop crypto, the receipts are TIBET. It adds no weight until you need it — and then it is simply there. That is why the same primitive fits a box, a phone, and an IoT device without any of them carrying a container platform to get it.

Reproduce it on your own stack

You need two identities you control, each a keypair registered active; a relay you run; and a box that holds an outbound lane to it with a seal key. Seed a mutual consent at pairing (paired ⇒ consented), then let your device seal a request, route it, and open the verified reply. No private key ever leaves the machine that owns it. Conformance vectors pin the wire in both directions, so a Python box and a Kotlin app agree byte-for-byte on every frame above.

The line exists only because of the binding; for everyone else, it isn't there.