docs: fleet discussion conclusions in to-discuss
e2f86922845e9804e885968d8e65edc8cdbb40a0
Oliver Jan Krylow <oliver@bugabinga.net> · 2026-09-25 17:37 UTC
unsigned 1 parent
repositories / smith
smith
There are many coding harnesses - but this one is fast
owned by admin
Changed files (1)
TO_DISCUSS.md
ready@@ -17,7 +17,7 @@
## Frontends
- smith-web: SSE skeleton first (std-only possible), websocket when live input and multi-viewer arrive — websocket forces the async runtime decision. Sequence: formalize smith-rpc as first smith-ui consumer, then smith-web.
-- Fleet / remote effects: p2p multiplexing of machines, tools, plugin instances across smith peers. Layer: beside the effect layer, not smith-ui. Trust tier for fleet peers is the spec-worthy core. Candidate transport: iroh. Trigger: multi-machine usage hurts.
+- Fleet / remote effects: p2p multiplexing of machines, tools, plugin instances across smith peers. Layer: beside the effect layer, not smith-ui. Sync scope: sessions + plugins; filesystem and environment stay plugin territory. Blockers when design starts: multi-writer session merge, effect host attribution, peer trust tier, credentialed-host routing rule — first two need zero preparation, additive fields ride the compatibility laws. Frontends attach to one peer; remote attach arrives with the web/daemon frontend. Candidate transport: iroh (node keys, encrypted tunnels, self-hostable relays). Trigger: multi-machine usage hurts.
- smith-mcp: MCP is a UI for agents and humans; smith-as-MCP-server consumes smith-ui so plugin features translate naturally into MCP (progress notifications, resources, tools). Frontend, not adapter mode. Trigger: external-harness integration wanted.
- ACP (Agent Client Protocol): editor-facing agent protocol; technical shape and smith layer unclear to us both — likely a frontend sibling of smith-rpc and smith-mcp, but unverified. Deferred. Trigger: editor integration wanted.