The AInternet Doctrine of Building on L0

L0 is the base layer — identity, reachability, and the bytes on the wire. Build on it and you can accidentally turn a helpful signal into a map of someone's private network. This is how you don't.

The trap: differential response = enumeration

If an unentitled caller can tell dead from alias from alive, they can map your network one probe at a time. The subtle part: it is easy to compute the entitled frame and then emit it — without checking the caller is entitled. The computation is correct; the emission is the oracle. A name that doesn't exist still computes a frame — emit that and you've leaked. The dark room must stay dark for the world.

The sluice — two gates, never both open to unproven water

You don't hand someone the deep water by opening one big door. You raise them through a canal lock, one gate at a time:

  world ──▶ [ Gate 1: proven? ] ──▶ [ Gate 2: relationship? ] ──▶ real frame
            not proven → 0x0000      no relationship → 0x0000

• Gate 1 (outer): is the caller a cryptographically proven actor? No → floor.
• Gate 2 (inner): does this proven caller have an established relationship (bilateral consent / prior binding) to this target? No → floor.

Both closed by default. The real frame flows only when both are raised for this caller. There is no single lever that floods the canal.

The build order — do these in order, never skip

1. Floor first. Return 0x0000 for everything. Ship that.
2. Prove identity (Gate 1). Until a real caller id exists, you have nothing to gate on — so emit only the floor.
3. Establish relationship (Gate 2). Add the consent/binding record and a real relationship check. Only now may a differential frame exist.
4. Emit through the one gate. Only after 1–3. Never wire the boolean compute kernel straight to the wire — that is how the lock gets skipped.

If you cannot yet do step 2 or 3, you are not allowed to do step 4. The floor is the safe resting state at every stage.

The one safe primitive

Emit only through a gate that takes a real caller and a real relationship check — floor by default, a differential frame only when both pass. There is no boolean to hard-code, so the oracle is impossible by construction. The boolean compute kernel is internal/testing only; it never touches the wire.

The canary — handshake.aint

So nobody points a test harness at a real, encrypted account to "see if probing works":

Why triage, not SNAFT

The control for "operating the canary" lives in triage, not in the constitutional guardrail. A rule you can only add by turning your guardrail off is a rule that forces you to disable security to install security — a chicken-and-egg. Triage intervenes on the action without ever flipping SNAFT on or off. Deactivation is one operator command (or a hard env kill-switch), audited, append-only.

The builder's checklist

• Does the world get 0x0000 for everything? (sweep every target; the floor holds)
• Am I emitting through the gate, never the boolean compute kernel?
• Is the relationship check real, never true?
• Did I test against handshake.aint, not a real account?
• Is the canary off by default and rate-limited when on?
• If I added an emission flag, is it inert-by-default and does it warn when set?