The swarm

Why do envoys talk to each other at all, and what flows between them?

Most of Vigo is server↔agent. The swarm is the exception: a peer-to-peer substrate where envoys exchange content directly, over mTLS, without routing every byte through the server. It exists so that distributing a 2 GB image, a git repo, or a fleet-wide file doesn't hammer one server — the blob moves node-to-node, the server only publishes pointers.

One substrate, six content subsystems

The substrate handles seed management, manifest CRDT gossip, and peer tracking. Six subsystems ride it (agents serve blobs over mTLS on port 1531):

All six are rooted in one identity primitive — the puddle.

How it stays trustworthy without a trusted server

The server publishes, never arbitrates. It aggregates what agents report (via traits) into read-only fleet views, but agents verify every signature and delegation chain end-to-end — they don't trust the server's word. A content subsystem's mesh aggregator (gitbackmesh, curatormesh, …) is a view, not an authority.

Two-layer authorization

Both layers must say yes; default-deny on both:

1. Envoy layer — is the subsystem enabled on this envoy? (server.yaml#swarm.*.enabled pattern list vs hostname).
2. User layer — which Unix users may use it? (usercrate puddle: / gitback: / curator: flags).

The destructive lever is the usercrate flag — removing it scrubs the user's held data on the next reconcile. Pattern-list flips are gate-only; held data survives.

Where this shows up

• Puddle identity — the per-user anchor everything builds on.
• Set up swarm, then gitback · lockbox · curator · poolq · longdrawer.
• The /swarm/* UI pages and vigocli swarm.

Confidential — Alexander4, LLC. Not for redistribution.