hyper-games #73 NEXT item 9. Reading daemon/session_daemon.h instead of assuming its shape: session-daemon is NOT Blender-specific and holds no logic. It exposes one Protomux channel on one topic to a local socket and moves opaque frames both ways; grab arbitration lives in blender-bridge/session/grab.py. So swarmd already supersedes it at the transport level, and that is measured rather than argued — test_channel_e2e.py carries a frame between two daemons over a named channel on a shared topic on the public DHT, which is session-daemon's whole job, plus buffering, truthful backpressure, client ids and a generated wire. What remains is a CLIENT change: the addon writes raw frames at a socket and would instead say HELLO / SWARM_JOIN / CHANNEL_OPEN / SEND and read on-message. Payloads stay opaque. ⛔ Which is why design step 5 — the C++ client library — comes first, and not as bookkeeping. A Python client means hand-writing swarmd's wire in the addon, and this session watched that exact mistake twice already: the first channel gate hand-rolled compact-encoding and the daemon answered "undecodable message" to every frame. Rebuilding it inside the addon puts it where it is hardest to test. ⚠ And it cannot be verified here: there is no Blender binary on tabertron (searched /storage, /opt, /usr, flatpak and snap; blender-source is a source tree with no build). Every blender-bridge gate runs `blender --background`, so an addon port made on this machine would be an unexercised path by construction. Steps 1-4 are marked done in §9; 5 and 6 are not, and the order between them is now written down with its reason. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>