R1 Mesh — Protocol69 / FOIL-over-RF Integration Design

Research line stub: how protocol69 (FOIL-over-RF cache-key teleport) can reinforce and extend the resilient R1 inference mesh. This document is honest about what is proven today versus what must be built.

Status key:

• PROVEN — working code, verified OTA or in unit tests
• BUILT — implemented in the repo, not yet OTA-verified on the mesh
• NEEDED — design decision made, code does not exist yet
• OPEN — not yet fully designed, needs a future subagent

Background

The R1 inference mesh uses two planes today:

• Data plane — WiFi TCP, /chain peer relay carrying f32 residuals between fat-station instances (verified R1-to-R1, 766 ms warm, zero USB in the path).
• Control / discovery plane — UDP gossip on FlowFrame stream 2010 carrying {node_id, model_id, stage, ip:port, health, load, epoch} heartbeats; eviction on missed beats drives the failover pool inside /chain.

Protocol69 (src/protocol69.rs, src/teleport.rs, /.aeon/teleport-admit) is a separate, orthogonal mechanism proven OTA in a different context: broadcast symbol 66 transmitted as a 66 kHz tone over NESDR SMArt v5 / Pluto SDR, recovered at 66 dB SNR, 66 XOR 7 = 69 validates, FOIL cache-key replayed with geodesicLength:0. The mesh integration proposed here bridges these two proven systems.

1. RF Discovery — protocol69 beacon as an out-of-band membership channel

The problem it solves

The WiFi gossip ring (stream 2010) is the heartbeat bus. If WiFi partitions (or an R1 falls off the AP and cannot re-associate), a node disappears from the gossip view and is evicted from the routing pool — even if it is physically present and computationally healthy. In a room full of flaky $200 devices this happens. BTLE was noted as a potential fallback discovery channel in R1_MESH_SCALING_PLAN.md, but BTLE is not implemented. RF (SDR) is proven working OTA.

The idea

Each R1-adjacent SDR node (or a designated RF anchor — a single Pluto or NESDR collocated with the room) transmits a periodic protocol69 beacon: a 66 kHz FSK or OOK tone encoding the protocol69 projection envelope (broadcast_symbol=66, local_foil_operand=7, expected_projection=69, plus a node manifest payload). Any R1 in RF range that can listen (via an attached NESDR or via a relay bridge) can decode the beacon and learn which nodes are physically alive, independent of whether their WiFi association is healthy.

The beacon content mirrors the gossip heartbeat struct:

Protocol69RfBeacon {
    protocol69_envelope: Protocol69ProjectionEnvelope,   // PROVEN: validates 66^7=69
    node_id:             [u8; 16],                       // same as gossip node_id
    model_id:            String,
    stage_lo:            u16,
    stage_hi:            u16,
    data_endpoint:       String,   // "http://10.0.0.199:8090"
    epoch:               u64,
    beacon_seq:          u64,
}

Because validate_protocol69_projection_envelope is fail-closed (a drifted projection is rejected, not passed through), the beacon acts as a self-authenticating liveness signal: any node that cannot produce 66 XOR 7 = 69 is treated as absent.

Mapping onto stream 2010

The existing gossip registry (src/mesh_gossip.rs) drives next_stage_pool(), which is what /chain reads for its failover pool. The RF beacon path would inject entries into the same registry via a new admission path:

rf_beacon_admitted(beacon: &Protocol69RfBeacon) -> GossipEntry {
    // validate the projection envelope first (fail-closed, PROVEN)
    validate_protocol69_projection_envelope(&beacon.protocol69_envelope)?;
    GossipEntry {
        node_id:       beacon.node_id,
        data_endpoint: beacon.data_endpoint.clone(),
        stage:         (beacon.stage_lo, beacon.stage_hi),
        ...
        source:        HeartbeatSource::RfBeacon,  // NEEDED: new variant
    }
}

A HeartbeatSource::RfBeacon entry would be treated identically to a WiFi-sourced heartbeat for routing purposes, but could be given a longer eviction window (RF beacons are coarser-grained than UDP, and that is acceptable for the out-of-band role).

What is proven vs. what must be built

The bridge daemon (a small process on a WiFi-connected host with an attached SDR) is the least invasive first step: it listens on RF, validates beacons, and injects gossip FlowFrames onto stream 2010 on behalf of the RF-visible nodes. Fat-station itself does not need to change for the first iteration. BUILT + VERIFIED (everything but the SDR receive): rf-gossip-bridge decodes beacons (selftest/file sources today; rtlsdr gated until the on-device USB-OTG probe), validates fail-closed, and injects stream 2010 heartbeats over UDP. Live test: a phantom beacon appeared in a running station's /mesh/peers; a forged envelope (expectedProjection:68) was dropped at the gate.

2. Cache-Key Teleport Handoff — skip recompute across /chain hops

The idea

The /chain relay today is purely compute-forward: every hop runs forward_range_chunk(residual_in, layer_lo, layer_hi, ...) regardless of whether a downstream node already holds a frozen amplituhedron volume keyed to the same prefix.

The teleport primitives offer a different path: if node B (the next-stage replica) already holds a frozen volume for the same (prefix_hash, prefix_len, layer_lo, layer_hi), it can serve a geodesicLength:0 replay without running the forward pass. Node A, before POSTing the residual to /chain on node B, would first probe B's /.aeon/teleport-admit with a protocol69 envelope carrying the FOIL-keyed cache key. A hit means B can answer without compute; a miss falls through to the normal forward.

This is the "teleport instead of recompute" idea: for repeated or similar prefixes (a multi-turn conversation, a batch of requests sharing a system prompt, or a decode loop re-prefilling the same prompt on failover), the second request to the same node costs zero forward FLOPS on the cached stages.

Concrete flow

Caller -> entry-node /chain:
  1. entry runs embed + layers [0, L).
  2. Derive FOIL cache key from (prefix_hash, prefix_len) for this residual.
     key = foil_cache_key(residual_fingerprint, seq_len)
  3. For each next-stage candidate in pool:
       a. POST Protocol69ProjectionEnvelope to candidate:8090/.aeon/teleport-admit
          (the canonical envelope: broadcast_symbol=66, local_foil_operand=7).
          -- PROVEN endpoint; teleport_admit_canonical validates 66^7=69 --
       b. If 200 + X-Geodesic-Length:0 -> TELEPORT HIT on that candidate.
          Use the replay payload (tail_residual, kv_slab) as the chain result.
          Skip the residual POST entirely.
       c. If 404 (miss) or 403 (drift) -> fall through to normal /chain POST.
  4. Proceed with normal post_to_next_pool on miss.

The teleport probe is cheap (a small JSON POST, no residual bytes transferred). The savings materialize when the hit rate is high enough to offset the extra RTT of the probe. The probe can be issued in parallel with the normal POST and the first response wins (a speculative parallel fork: if teleport hits, cancel the compute POST; if compute returns first, ignore the teleport probe result).

Keying the cache entry

Today teleport_admit_canonical maps broadcast_symbol to prefix_hash and local_foil_operand to prefix_len with fixed values (66, 7). For mesh use, the FOIL cache key must encode the actual residual identity. Two options:

a. Prompt-hash keying (NEEDED): derive prefix_hash from a hash of the token sequence (or a FOIL entropy fingerprint of the residual), not the fixed value 66. The canonical 66/7 path becomes a special case (the "well-known" key used in the OTA proof). A new teleport_admit_mesh variant accepts arbitrary (prefix_hash, prefix_len) while still requiring the projection envelope to validate.

b. Fixed-key prefill caching (simpler, partial): keep the canonical 66/7 key and use it only for the one known-common prefix (e.g. the system prompt of Thoth). Any request that shares that exact prefix teleports; others fall through. Zero new code required on the admission side — just /.aeon/amplituhedron-capture on the target node after the first forward.

Option (b) is implementable today with only a capture step. Option (a) generalizes to arbitrary prompt sharing and is the right long-term design.

Relation to the residual handoff in /chain

In the current /chain implementation (handle_chain in fat-station.rs), the only path that produces a result without running forward_range_chunk is the tail's lm-head. A teleport hit would add a second early-exit: if teleport_admit returns TeleportVerdict::Admitted, the residual from the frozen volume replaces the output of forward_range_chunk and is forwarded to the next hop (or used as the lm-head input at the tail). The change is a three-line guard before the fwd block:

// NEEDED — not yet in fat-station.rs
if let Some(frozen) = try_teleport_from_cache(&station, &residual_in, ...) {
    // geodesicLength:0 path: skip forward_range_chunk entirely
    return forward_or_tail(station, frozen, pool, ...);
}

What is proven vs. what must be built

3. Gap Analysis — honest accounting

What is proven end-to-end today

1. Protocol69 projection arithmetic: 66 XOR 7 = 69, validate_protocol69_projection_envelope, build_protocol69_projection_envelope. Three unit tests pass. The arithmetic is a compile-time const in protocol69.rs.

2. OTA RF teleport: Pluto TX symbol 66 as a 66 kHz tone; NESDR SMArt v5 (SN 94092559) RX at 66 dB SNR, +49 dB on-off; 66 XOR 7 = 69 validated on the live FOIL node; geodesicLength:0 replay confirmed. (Memory entry 2026-05-24.)

3. teleport_admit_canonical + verdict primitives: three unit tests (hit / miss / deny-on-drift) pass. The /.aeon/teleport-admit endpoint in fat-station exercises the same primitive via HTTP.

4. The R1 mesh data + control planes: /chain with failover pool, stream 2010 gossip, qspec admission, wakelock equip. Verified R1-to-R1 over real WiFi (argmax 12095, 766 ms warm). These are the substrate the RF/teleport work would ride on.

What the mesh integration needs (does not exist yet)

a. RF-to-gossip bridge. A process that decodes protocol69 RF beacons and injects gossip entries into the stream 2010 registry. No code; the boundary between the SDR receive path and the gossip registry has not been crossed.

b. Prompt-hash FOIL key derivation. A deterministic mapping from a token sequence (or residual fingerprint) to (prefix_hash, prefix_len) that is consistent across mesh nodes so they can agree on what is cached where. The canonical 66/7 key is a single point; generalizing it requires a shared key-derivation convention.

c. Teleport probe in post_to_next_pool. The optional pre-flight check against /.aeon/teleport-admit before committing to a full residual POST. The speculative parallel fork variant (probe + POST in parallel, first response wins) avoids adding latency on the miss path.

d. Cache warm-up / population policy. Deciding when to POST to /.aeon/amplituhedron-capture on a downstream node. The simplest policy: after the first successful /chain hop through node B, capture the output residual to B's cache keyed by the prompt hash. Subsequent identical prefixes teleport.

e. NESDR / Pluto driver on R1. The R1 (MT6765, aarch64) has USB-A OTG. Whether the Android kernel exposes USB bulk or the rtl-sdr kernel module is available is unknown. This is likely the highest-friction item for running the RF path on-device rather than via a bridge host.

4. Next Steps for a Future Subagent

Ordered by value/risk. Each step is bounded and independently verifiable.

1. Implement option (b) fixed-key prefill teleport (no new code, uses existing endpoints). On a running two-R1 mesh: after the first /chain run (which already proves correct at argmax 12095), POST the entry-node's residual to node B's /.aeon/amplituhedron-capture with prefix_hash=66, prefix_len=7, layer_lo, layer_hi. Then replay a second identical request: hit /.aeon/teleport-admit on B first; expect geodesicLength:0. Measure the wall-clock delta. This proves the loop end-to-end with zero new code.

2. Add prefix_hash derivation to handle_chain. Hash the token sequence (FNV-1a or xxh64 of the u32 token slice) into prefix_hash; use seq_len as prefix_len. This is the key contract the mesh needs. Write a unit test asserting the same hash across two identical token sequences before landing it.

3. Add the teleport probe to post_to_next_pool. Before the agent.post(...)/chain call, try agent.post(...) /.aeon/teleport-admit with the derived envelope. On TeleportVerdict::Admitted, decode the replay body and return it directly (skip the residual POST). On Miss or Denied, fall through. Log the hit/miss ratio to stderr alongside the existing /chain latency line.

4. Implement Protocol69RfBeacon + the bridge daemon. DONE (everything but the SDR front-end). src/rf_beacon.rs defines Protocol69RfBeacon (frame + fail-closed to_peer_info/to_gossip_frame); bin/rf-gossip-bridge deserializes beacons, validates the projection envelope (fail-closed), and forwards heartbeats to a configurable fat-station gossip port via UDP FlowFrames on stream 2010 — keeping the SDR dependency out of fat-station. Sources: selftest, file; rtlsdr is a gated stub pending step 5. Verified end-to-end: a phantom beacon injected into a live station's /mesh/peers; a forged envelope dropped at the gate. REMAINING: the actual RTL-SDR demod front-end feeding --source rtlsdr (gated on step 5's hardware probe).

5. Probe NESDR availability on R1 (USB OTG). Plug an NESDR into a running R1 via a USB-C OTG adapter. Check dmesg | grep rtl, lsmod, and whether /dev/bus/usb enumerates the device. If the kernel module is absent, assess whether a loadable .ko can be pushed to /data and insmod'd under the R1's SELinux policy. Document the result — this gates whether the RF path can run on-device or must remain on a bridge host.

6. Cache invalidation policy (OPEN — design before building). The amplituhedron cache has no TTL or eviction today. For a mesh under bursty load with varying prompts, stale entries accumulate. Options: LRU eviction by entry count, TTL per capture, or explicit invalidation via a new /.aeon/amplituhedron-evict endpoint. The right choice depends on observed cache size in production; do not design in the abstract — instrument first (step 1 + 3 give the hit/miss data).

Summary

Protocol69's two contributions to the mesh are distinct and composable:

• RF beacon path: an out-of-band liveness signal that survives WiFi partition, bridging into the stream 2010 gossip registry via validate_protocol69_projection_envelope as the admission gate. The primitives are proven; the bridge is not built.

• Cache-key teleport in /chain: a pre-flight probe against /.aeon/teleport-admit before each residual forward, allowing a node that already holds a frozen amplituhedron volume to serve geodesicLength:0 without compute. The endpoint is proven; the probe integration and key-derivation convention are not built.

Neither integration requires modifying the existing gossip or /chain semantics; both compose on top. The fixed-key proof-of-loop (step 1 above) is achievable on a live mesh today with zero new code.