Protocol · The three layers

Three layers. All of them yours.

Potluck is infrastructure you run, own, and govern: the opposite of a hosted vendor service, and nothing like a chatbot subscription.

The architecture, plainly

01
Your device runs the models.
The Potluck desktop app installs strong open-source models locally. Inference happens on your CPU or GPU: no network request, no vendor server, no prompt log. Local models today are good enough for the majority of daily AI work.
02
A local MCP server holds your memory.
A Model Context Protocol server runs on your machine and stores facts, decisions, active tasks, and references. It keeps them persistently, across sessions and across agent vendors. Claude Code, Cursor, Cline, Continue, Zed. Whatever coding agent you use next week can read what you saved this week. Your context, not the vendor’s.
03
A WireGuard mesh connects your machines.
The mesh sidecar handles NAT traversal automatically: IPv6 direct path first, UDP hole-punch second, network-operated DERP relay as a last resort. No root access. No kernel module. Traffic between your machines is encrypted end-to-end.
04
When you need more, the network has capacity.
Network mode is opt-in. When you choose it, the coordinator dispatches your request to a contributor peer. Before forwarding, the coordinator strips your member identity from the job message: the contributor serving your request never knows whose it is. This is enforced by schema, not by convention, and tested in CI on every commit.

Persistent memory for your AI agents

Every time you work with an AI coding agent, you re-explain yourself. What stack you are using. What decisions you have already made. What you tried that did not work. That context lives in your head, and disappears the moment the session ends.

Potluck ships a local MCP server that stores this persistently. Facts, decisions, active tasks, and references: written and read by any MCP-aware coding agent. Save something in one agent; it is there when you switch to another next week.

The memory server runs on your machine. The data never leaves unless you choose to sync it. Your context is yours. This is the piece that ships today, and the on-ramp into everything else Potluck does.

Fig. 1 · What gets storedMCP

Categories of data stored in the Potluck memory server
Category	Examples
Project facts	Stack decisions, architecture notes, tech choices
Preferences	Code style, library opinions, tooling setup
Active tasks	Multi-step work spanning sessions and agents
References	Links, specs, doc sections relevant to your work

Protocol: Model Context Protocol (MCP), an open standard supported by most major coding agents.

A mesh that connects your machines: no third-party VPN

Most people have more than one machine. Their laptop at home, their desktop in the office, maybe a server sitting in a closet. Getting those machines to talk to each other means either paying for a VPN service or configuring port forwarding and hoping your ISP cooperates.

Potluck ships a WireGuard mesh sidecar that handles this automatically. Install the app, click “Add another machine,” scan the QR code on the second machine. The two machines find each other across NATs, through firewalls, across ISPs: no Tailscale account, no separate daemon, no terminal commands.

The mesh runs userspace WireGuard. No root access required. No kernel module. Traffic between your machines is encrypted end-to-end: the relay server sees encrypted bytes, not content.

Fig. 2 · Connection pathordered by speed

WireGuard mesh connection path options, in priority order
#	Method	Notes
1	IPv6 direct	No NAT, no relay. ~45% of US consumer connections.
2	UDP hole-punch	STUN discovers external endpoints; both connect simultaneously.
3	DERP relay	Symmetric NAT fallback. Network-operated, not a third party.

Shared compute, shared upside

A strong local model on a good machine is fast. But not everyone has a good machine, and even good machines have limits. When a member needs more compute than their device can provide, the network has capacity to offer, contributed by other members who have hardware to spare. Think folding@home, except the compute doesn’t get donated to a lab; it stays in your circle and runs your own models. Working today across machines you own; opening it to a friend-circle and the broader network is the next phase.

When you opt into “network mode” for a session, your request is dispatched to a contributor peer that advertises the required model. The dispatch is blinded at the protocol layer: the coordinator strips your identity before forwarding the job. The contributor serving your request never knows the request was yours. This is enforced by schema: the message type has no field where member identity could live. It is also tested in CI on every commit.

Day-to-day, contribution is a ledger, not a token: contribute compute, earn credits, credits offset your subscription. An account balance, no wallets, no speculation, same shape as cloud credits. The credit you earn for work cannot be traded. Longer term, the people who power the network also come to share in its governance token, a voice over how the network runs. It is opt-in, it is being structured with counsel, and it is never required to use Potluck.

Understand how the company and the network are structured, and who governs what.

Governance structure