Gud Boi
d9a6e2e9b4
§3.2 specced a pure fn `_peel_tunnel_segs(proto_names) ->
(bearer_names, tunnel_specs, overlay_names)` to split a maddr at
its tunnel seg. It should never be written: `py-multiaddr` ships
that whole surface already and the plan simply missed it, even
though gh #443's 2nd bullet links the README sections in
question.
Replaced w/ a ⚠️ CORRECTION carrying the verified API table
(`.decapsulate_code(P_WG)` for the bearer, `.split()`/`.join()`
for a seg tail, `.value_for_protocol()` to read a value,
`.encapsulate()` to recompose) plus *why* it works on an infix
`/wg/` seg: the cut is by proto-code, never by matching an addr
value, and the key seg has no addr of its own.
Also,
- adopt `bearer`/`overlay` as the role names throughout, and say
plainly why not `inner`/`outer` — the call-stack reading of
"inner" is the exact opposite of the encapsulation one.
- warn that `value_for_protocol('ip4')` on a full tunnelled
maddr silently yields the *bearer's* host; only call it on a
peeled sub-maddr.
- note nesting (wg-in-wg) falls out of `.decapsulate_code()`
cutting at the *last* occurrence, so peel repeatedly rather
than recursing through a bespoke splitter.
- `mk_maddr()` for `TunnelledAddress` is `.encapsulate()`
composition, not `str` building.
- README: drop the "degrades to a plain segment split" para,
since that path is gone — no codec now means one actionable
raise.
(this patch was generated in some part by `claude-code` using `claude-opus-5` (`anthropic`))
|
||
|---|---|---|
| .. | ||
| 00_shared_backend_contract.md | ||
| 01_tipc_backend.md | ||
| 02_quic_iroh_backend.md | ||
| 03_wg_tunnel_bindspace.md | ||
| README.md | ||
README.md
next-gen tractor.ipc transport backend plans
Implementation specs for three prospective .ipc transport backends, written so each can be worked independently (by a different model/provider) without design or lib-selection drift.
Read 00_shared_backend_contract.md first — it is the normative description of what a tractor transport backend is as of main@83b34884 (the backend duck-type, the 10-item registration checklist, the test-harness plumbing, the code-style rules). The three plans assume it and document only their own deltas.
| plan | issue | dep | size | lands |
|---|---|---|---|---|
| 01 — TIPC | #378 | none (stdlib) | small | first |
02 — QUIC/iroh |
#353 | iroh (uniffi FFI) |
large | needs a prep PR |
03 — wg bindspace |
#482, #443 | pyroute2 |
medium, 3 layers | layer A now |
Headline conclusions:
- TIPC is the cheap win. Verified:
trio.SocketStreamandtrio.SocketListenerare address-family agnostic (onlySOCK_STREAM+ a trio socket), and CPython shipsAF_TIPC+ 23TIPC_*constants. So the backend is ~one module of contract boilerplate, zero new deps, and it buys kernel-native service discovery:bind()publishes,connect()-by-name resolves — no registrar in the loop. (modprobe tipcis required; hard-gate everything.) - QUIC’s cost is entirely in two adapters, not in QUIC. The
irohpython bindings areuniffi-generated asyncio, but the asyncio dependency is confined to one future-poll callback — a ~40-linetriobridge (TrioToken.run_sync_soon) replaces it. The second cost is that an iroh listener isn’t a socket, which needs a small, independently-reviewable prep PR to_server.py/_types.py. - WireGuard is not a transport. It’s an iface-layer tunnel, so it belongs as a nested bindspace (
TunnelledAddress+open_bindspace()@acms) wrapping whatever L4 tpt is in use — which is also what finally implements the long-spec’dAddress.namespace, and what generalizes toveth/vxlan/gre.
Ordering rationale: plan 01 first as the cheap proof the table-registration story generalizes to a genuinely new proto; plan 03 layer A is already deployable-today doc/example work; plan 02 last (and gated on its prep PR). Plans 01 and 02 both want the same Address.rebind_from_sockname gate — whichever lands first ships it.