Skip to content

Bring Your Own Rendezvous: Be the Middle

Reaching a Sovereign Box shows that a phone reaches its own box by identity over a dumb, swappable relay. This page shows how to run that middle yourself — so no company, not even ours, sits in your path. It is the operator companion: the three small services, the config knobs, and the two admission gates you now own. It follows the Sovereign Deployment Doctrine — Local First · No mandatory hyperscaler · HTTP is enough — and builds on Route Posture, Not a Trust Score.

The overlay's whole promise is that the middle is interchangeable. That promise is only real if being the middle is practical. It is: the rendezvous is three small, content-blind services on any machine you control — a VPS, a spare box, a Pi at home. None of them is an authority. The keys are the authority; the middle only moves ciphertext and reflects addresses.

What "the middle" actually is

Three services, each independently swappable, none holding trust:

service what it does is NOT
Edge relay (/api/edge/*, /api/mux/*) holds the box's outbound lane; routes sealed TBZ blobs to a box's .aint; records bilateral consent never unseals, never an identity authority
Resolver (/api/overlay/register, /resolve/{did}) STUN-like: reflects a node's observed bearer address by identity, over plain HTTPS never decides trust; a wrong hint only sends you to a dead endpoint
Rendezvous hub (tibet-ping, UDP :7150) address discovery + coordinated NAT punch for direct P2P (the no-relay upgrade) optional; the relay route works without it

The edge relay + resolver are the brain_api overlay/edge/mux surface; the hub is listen_hub.py. Run the first two and the sealed relay route works end to end. Add the hub when you want direct P2P.

Federation, not a hub. Each relay is its own sovereign, with its own admission registry. "No central authority" is exact for the data (sealed — keys decide) and each relay owns its topology. There is no one everybody must trust; only the one you choose, running code you can read.

Point your box at your middle

The box carries the relay address sovereignly, in the pairing card — so every relationship picks its own middle. Configure it before you pair:

export AINTERNET_EDGE_RELAY="https://relay.example.aint"   # YOUR edge relay — goes into the QR the phone pins
export AINTERNET_NODE_AINT="mybox.aint"                    # the box's node .aint (relay routing target)
export AINTERNET_UDP_RENDEZVOUS="203.0.113.7:7150"         # YOUR hub (only for the direct-punch upgrade)
sudo -E ./box overlay up                                    # holds the outbound lane + arms the responders

./box overlay up brings up three deliberate, separate paths: the outbound lane-holder (the relay route — it dials out to the relay you named and opens no public inbound port at all), the direct-LAN status listener (:8455, reachable only from your own network), and — when a rendezvous is set — the UDP carrier (:7150, whose hole is punched from the inside; it is not a published inbound service). Each path is opt-in and separately observable; none of them exposes the box to the open internet.

Point your phone at your middle

You do not configure the phone separately — it inherits your middles from the pairing card. When you run ./box presence enroll, the QR carries relay + node_aint + the box's seal key (sealed relay route) and rendezvous + resolver (direct-punch route), straight from the environment above. The app pins them and routes every sealed request over your middle. Nothing points at us.

Both routes are card-driven. The sealed relay route rides relay + node_aint + the box's seal key; the direct-punch route (the no-relay P2P upgrade) rides rendezvous + resolver. A card that names none of them is the only case that falls back to the app's built-in defaults. Those defaults are a convenience for someone who has not chosen a middle yet — a starting point, never the doctrine. The doctrine is the card: whoever runs the middle is named there. The app shows which middles it is actually on (rendezvous / resolver under node), so falling back to a default is visible, not assumed.

The two admission gates you now operate

Reaching a box is gated twice — both by identity, never by IP (see Route Posture, Not a Trust Score). As the operator you own both:

  1. Consent (who may route to whom). A relationship is bilateral. At pairing the box seeds it for you — paired ⇒ consented — so a fresh owner-device pairing is reachable immediately, no manual approve. You can also grant/revoke by hand (the owner .aint approves a knocker). An un-consented sender is deferred, not leaked.
  2. Admission (may this request reach the wire at all). The relay absorbs abusive traffic by IP heuristic — but a request that proves its AInternet identity is redeemed to the clean lane regardless of its carrier IP. A self-signed key + posture (X-Actor-Pubkey + X-Posture + a fresh Ed25519 challenge) admits a derived device actor that no name-service ever knew, on any carrier. Identity beats IP, so a phone roaming 4G→5G→Wi-Fi is never whack-a-mole blocked for changing address. A bad signature still falls through to the block — the lane is not a free bypass.

Both gates live in the relay you run; neither consults a central party.

Verify it — bring your own verifier

Do not trust our code. The conformance vectors pin every frame in both directions (ping, sendpath, mux_lane, overlay_route, sealed_cmail, gateway_egress, null_route, overlay_bearer_handover, overlay_coordinated_punch, mux_carrier_selection): input → expected output, rebuild the verifier yourself. A Python box and a Kotlin app agree byte-for-byte. Stand up your three services, pair two identities you control, and confirm a sealed request returns REACHED with authorship == pinned node-key: TRUE over a relay that could read none of it.

What never becomes an authority

  • The relay reads nothing — it forwards TBZ ciphertext and refuses anything that is not a sealed carrier.
  • The resolver decides nothing — it reflects an observed address; a spoofed register can only DoS a route, never forge a reply.
  • AINS is an optional phone book, never load-bearing — you can resolve by any hint and still verify by the pinned key.

The line exists only because of the binding. Run the middle yourself, and it still isn't ours.