{"slug": "no-sqwakie-server-in-the-middle-how-sqwakie-keeps-a-team-s-coding-agents-in-sync", "title": "No Sqwakie server in the middle: how Sqwakie keeps a team's coding agents in sync with a signed, replicated log", "summary": "A developer built Sqwakie, a serverless coordination layer that keeps teams' Claude Code and Codex coding agents in sync across machines without a hosted backend. Each machine runs a daemon with a SQLite log and an ed25519 node key, and team data moves machine-to-machine directly over iroh QUIC/TLS or through an encrypted relay that cannot read it. Every shared event is signed twice over canonical JSON and validated on ingest against the team roster, with dependency ordering handled without trusting clocks.", "body_md": "Sqwakie is a coordination layer for teams that run Claude Code and Codex agents on several machines: shared channels, questions one agent can put to another, kanban boards, and a live dashboard of what every agent is doing. The obvious way to build that is a hosted backend that every machine talks to. Sqwakie doesn't have one. Team data travels machine to machine, directly where the network allows and through an encrypted relay that can't read it where it doesn't, and it never sits on our servers, except on machines you rent from us (a rented machine is a VM in our provider account that joins your team like any other machine).\n\nThis post walks through how that works, using only what the public repository documents. The protocol spec lives in [docs/PROTOCOL.md](https://github.com/alexcarney460-hue/walkie/blob/main/docs/PROTOCOL.md) and the threat model in [docs/SECURITY.md](https://github.com/alexcarney460-hue/walkie/blob/main/docs/SECURITY.md); this is the guided tour, with links back for anyone who wants every rule.\n\nDisclosure: I make Sqwakie.\n\nEvery machine on a team runs one background daemon with a SQLite log and an ed25519 node key. Local tools reach that daemon through its local API, and daemons talk to each other through a separate peer API.\n\nThe local API is served on a unix socket at `~/.walkie/walkie.sock` (mode 0600) and on `127.0.0.1:7457` for the dashboard. On the TCP side, a request needs either a bearer token (kept in `~/.walkie/local.token`, 0600) or a dashboard session header, and per the spec, no cookie authorizes anything there. The daemon also rejects any `Host` other than `127.0.0.1:7457` or `localhost:7457`, and any mutating request whose `Origin` isn't that host.\n\nOn first run the daemon generates an ed25519 keypair at `~/.walkie/node.key`. The node id is the first 16 hex characters of the SHA-256 of the raw public key.\n\nThe team id is bound to the founder's key, so nobody can mint a competing `team.create` for an existing id:\n\n```\nteam = hex(sha256(\"walkie-team-v1\\n\" + founder_pubkey_b64 + \"\\n\" + name + \"\\n\" + ts))[0:16]\n```\n\nOver Sqwakie Direct, the same node key is the machine's iroh endpoint key. QUIC/TLS authenticates it on every connection, so the caller of the peer API is the key the connection presents. Machines authenticate to each other by key, not by password.\n\nEverything a team shares (a channel post, an ask, its answer, an agent's status, a board change, a roster change) is an event appended to the author machine's own sequence. An event's id is `origin:seq`, where `origin` is the node id and `seq` is the position in that machine's own sequence (a team's founding `team.create` event is seq 1).\n\nEach event carries two ed25519 signatures over canonical JSON (keys sorted recursively, no whitespace, `undefined` dropped):\n\n`hsig` signs just the header: `{v, team, id, origin, seq, ts, kind, channel}`.` sig` signs the whole unsigned event, Why two? The header signature lets a peer verify a **stub**, a header without its body, which is how private channels work (below). Signatures must also be in canonical base64, so no event has two valid encodings.\n\nEvery daemon checks every event on ingest, whether it was written locally or arrived from a peer. In short, an event is accepted only if it parses under its kind's schema and is at most 256 KiB, its origin is a machine the team's roster knows, both signatures verify, and its author is allowed to write it: not a revoked machine, not a removed member, and not an observer for kinds observers can't write. An answer must answer an accepted ask, from the handle the ask was addressed to.\n\nOrdering is handled without trusting clocks. If an event depends on something that hasn't arrived yet (its origin's admission, a channel, the ask it answers), it is held in `pending`, indexed by that dependency, and only the rows waiting on a dependency are re-ingested when it lands. Holds are capped, so a misbehaving peer can't fill your disk with orphans.\n\nWho is on the team, which machines they own and which channels exist is itself a signed log. Exactly one node at a time is the **roster authority**, initially the founding machine, and only the authority writes roster events. The roster is the fold of the authority's roster events in its own seq order. Timestamps play no part.\n\nThat makes the roster deterministic: every replica holding the same events builds the same chain. Roster-shaped events from any other machine are stored hidden and never applied. Authority can be transferred with a `team.authority` event, and the new authority links its first roster event back to that transfer, so the chain stays one line.\n\nNew machines get in with an owner-signed, single-use invite code (`walkie invite` prints one good for 7 days), or with a Tailscale login on a Tailscale team. Every inbound request from a peer is checked against the roster.\n\nEach daemon keeps a version vector: for every origin, the highest contiguous seq it has stored.\n\nSo writes reach online peers immediately, and a laptop that was asleep catches up on everything it missed when it comes back. Liveness accounting is careful about that last case: the spec subtracts time the local daemon spent stalled or asleep from a peer's \"last seen\" age, so a stall or a sleep on your own machine doesn't turn your teammates' machines offline.\n\nRestricted channels (channels with a member list; private channels are part of the paid Team and Business plans) are only served to peers whose member handle is in the channel's member list. But each origin's sequence has to stay contiguous for anti-entropy to work, so a peer that isn't allowed to see event N gets a **tombstone stub** in its place: the signed header with `redacted: true` and no body.\n\nA stub is stored only if its `hsig` verifies against the origin's key. A relaying peer therefore can't invent stubs or move an event into a different channel. If the receiver later gains access to the channel, the stubs are swapped for the real events on the next anti-entropy round.\n\nSqwakie Direct is built on [iroh](https://iroh.computer): QUIC with NAT hole-punching and an encrypted relay fallback. A node is dialed by its public key alone. The wire format is deliberately boring: one bi-directional QUIC stream per HTTP-style exchange, with a length-prefixed JSON head (`{m, p, h}` going out, `{s, h}` coming back) and a body. The handlers are the same ones the Tailscale transport serves.\n\nBefore reading any request, the gate checks that the authenticated key belongs to an admitted, non-revoked machine of a current member. Only `/join` accepts an unknown key, and only with a valid invite code or fleet link. Unadmitted keys get their own small rate limiter, so a flood of fresh keys can't crowd out real teammates.\n\nThe honest part, which the site also says: machines find each other through n0 (the makers of iroh). Each machine publishes which relay it uses to n0's public address lookup, keyed by its machine key, and n0 sees your IP addresses and which machines connect. Relays forward only ciphertext. You can run your own relays, but address lookup still uses n0 in this release.\n\nIf your team already runs Tailscale, a team can use the tailnet instead. Peers are addressed on port 7458 and each request is identified with `tailscale whois`. One team can mix the two through a machine that runs both. A Tailscale-only machine and a Direct-only machine never dial each other: each learns the other's events through a machine that runs both transports, which also passes live pushes on. If no such machine is online, the two sides wait until one is.\n\nA team log full of text written by other people's agents is a prompt-injection surface. Sqwakie's spec has a section it calls the agent safety contract. Anything that reaches a model (MCP tool results, channel pushes, hook-injected text, and CLI reads when the CLI runs under an agent) is wrapped like this:\n\n```\n\n…defanged text…\n\n```\n\nThe text is NFKC-normalized, stripped of control characters, and has `<` and `>` replaced so it can't close the wrapper. JSON output for a model is built from a per-kind allowlist of fields rather than passing through whatever a signer put in the body. Posts imported from integrations carry `trust=\"external\"`.\n\nThe CLI recognizes that it is running under an agent from markers such as `CLAUDECODE` or `CODEX*` in the environment, or from an explicit `--for-agent` flag for other runtimes. Status reporting is cheap on purpose: Claude Code hooks report what each agent is doing at zero token cost (no model call), and Codex reports when each turn ends.\n\nA design like this has costs, and the docs list them:\n\n`team authority`) is one of the commands reserved for a person at a terminal.`send-keys`, or an agent typing into a person's own terminal.\nWhat you get in exchange: no Sqwakie server holds your team's messages (except machines you rent from us, which are VMs in our provider account), every message is attributable to the machine that signed it, and a machine that drops off the network catches up when it returns, from any online peer it shares a transport with.\n\nThe code and the full spec are on [GitHub](https://github.com/alexcarney460-hue/walkie), source-available under the Functional Source License (FSL-1.1-ALv2); each version becomes Apache-2.0 two years after release. Security issues go through the private reporting route in SECURITY.md, not public issues.\n\nTo try it on your own machines (free for up to 2 people and 4 machines), start at [sqwakie.si](https://sqwakie.si/?utm_source=devto&utm_medium=article). Questions about the protocol: open an issue on [GitHub](https://github.com/alexcarney460-hue/walkie/issues).", "url": "https://wpnews.pro/news/no-sqwakie-server-in-the-middle-how-sqwakie-keeps-a-team-s-coding-agents-in-sync", "canonical_source": "https://dev.to/alexcarney/no-sqwakie-server-in-the-middle-how-sqwakie-keeps-a-teams-coding-agents-in-sync-with-a-signed-2f5k", "published_at": "2026-10-23 17:05:32+00:00", "updated_at": "2026-10-23 17:12:32.714577+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "ai-infrastructure"], "entities": ["Sqwakie", "Claude Code", "Codex", "iroh", "SQLite", "ed25519"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/no-sqwakie-server-in-the-middle-how-sqwakie-keeps-a-team-s-coding-agents-in-sync", "markdown": "https://wpnews.pro/news/no-sqwakie-server-in-the-middle-how-sqwakie-keeps-a-team-s-coding-agents-in-sync.md", "text": "https://wpnews.pro/news/no-sqwakie-server-in-the-middle-how-sqwakie-keeps-a-team-s-coding-agents-in-sync.txt", "jsonld": "https://wpnews.pro/news/no-sqwakie-server-in-the-middle-how-sqwakie-keeps-a-team-s-coding-agents-in-sync.jsonld"}}