What peerd is, precisely.

The connection to whichever model you picked. Bring your own key; peerd has no inference service of its own and never proxies your traffic through anyone.

Three adapters, one interface

Three model adapters ship today, all behind a tiny registry and a single callModel() entry point:

• Anthropic: native /v1/messages, the default. Streaming, prompt caching, and adaptive extended thinking.
• OpenRouter: the OpenAI-compatible gateway, so one adapter reaches most vendors at once.
• Ollama: keyless and local on localhost:11434. peerd reads your real installed models from /api/tags and recommends one sized to your GPU.

A native OpenAI adapter does not exist yet (OpenRouter covers it meanwhile). Every adapter normalizes to one provider-agnostic stream of events (text, reasoning, tool-use, usage, stop), so the runtime never knows which vendor it is talking to.

Extended thinking is requested in the shape each model expects (modern models take an adaptive budget drawn from a 64k output ceiling; older ones take an explicit token budget). Effort defaults to medium, deliberately below the platform default, because long invisible deliberation reads as a hang in a browser. A per-chat dial raises it where the provider honors it.

The module where security is the whole point. Every secret, every outbound request, and every irreversible action passes through here.

The vault

One AES-GCM data key wraps everything sensitive. That key is itself wrapped by two interchangeable unlock factors: a WebAuthn passkey (full-entropy, no password) and an optional Argon2id passphrase. Argon2id is the only passphrase KDF; there is no weaker legacy path. The unwrapped key lives in service-worker memory and is mirrored only to RAM-backed session storage, so it survives the browser killing the worker but is gone when you close the browser.

Two egress gates

peerd splits the network into two regimes, because credentialed provider traffic and open-web browsing are different problems:

• safeFetch: the credentialed path. A five-origin exact-match allowlist (no wildcards, by design). This is where your API keys go.
• webFetch: the open-web path for the agent's read tools and the VM's curl/wget/git. No allowlist (the web is too big), but a strict gauntlet: scheme check, a private-network SSRF block, the sensitive-site denylist, redirect fail-closed, and an audit entry on every call, successes included.

The denylist

164 seed patterns across 8 categories (banks, brokers, crypto exchanges, wallets, US health portals, government, password managers, identity providers), plus your own additions and removals, edited with search and confirm-to-remove. The matcher only accepts exact hostnames or boundary-safe *. globs, so *.chase.com can never be tricked into matching evilchase.com. It gates both the agent's tool dispatch and webFetch.

The module that creates and manages the agent's execution environments. The primitive underneath every one is the JS isolate the browser already ships.

A V8 isolate (a SpiderMonkey realm on Firefox) starts in milliseconds and isolates strongly, which is why Cloudflare builds its agent platform on them rather than containers or VMs. The browser has shipped that same isolate for decades, hardened against hostile code from every site you load. peerd runs the agent's code there: no server, no container, no process on your machine, and nothing that can reach a host filesystem the browser never exposes.

An execution environment is one isolate plus the tooling around it (a shell, a filesystem, a UI), picked for what a job needs. They range from a sealed JS worker, the lightest, for the agent's own code, to an opaque-origin iframe, the strongest boundary, for code you'll share. Most run in a tab you can watch; one runs headless.

Headless worker: the agent's own quick compute

The lightest environment, and the base the rest build on: a sealed JS worker with no tab (js_run), running in the background. Each call is fresh and ephemeral, its scratch discarded after, leaner and quicker than a tab and never stealing focus, so it is where the agent runs its own throwaway work. This is peerd's code mode: instead of a long chain of separate tool or MCP calls, the agent writes one script that loops, fetches, and returns just the result, over the same audited HTTP bridge (peerd.egress.fetch, the gate call_api uses). The same worker also runs compiled wasm32-wasi binaries via the peerd:wasi builtin — query a SQLite file, decode an archive, run a language runtime — against an in-memory filesystem: the module gets no network at all, only the stdin and files the call hands it. The run is recorded in the audit log like any other tool call.

Notebook: a JS workspace you watch

The same sealed worker, now in a tab you watch (js_notebook): a CodeMirror file-tree editor backed by OPFS, so you see every run. Each run is a fresh worker (no warm kernel, no leftover globals, no cells), so a run is a pure function of the code plus the files on disk, reproducible by construction (none of Jupyter's works-only-if-you-run-it-in-order surprises). State that must outlive a run goes to OPFS explicitly; dependencies are explicit imports (the peerd:std stdlib, peerd:wasi for compiled WASI binaries, or a CDN URL), never ambient globals. Return a value and the pane renders it: a flat-object array becomes a table, a chart spec draws an SVG.

App: a client-side SPA

A step up in isolation: multi-file HTML/CSS/JS the agent writes for you, stored in OPFS and run in a sandboxed opaque-origin iframe, the strongest boundary peerd has: its own origin, every chrome.* API stripped. That is what makes it the safe host for code you'll share or receive, and a dwapp is just an App distributed over the dweb (see distributed). The agent can rewrite an App in place and the tab live-reloads.

WebVM: a real Linux box

The heaviest environment: a full Debian, compiled to WebAssembly with CheerpX. The tab is the VM: a persistent bash shell and an xterm terminal, exit codes captured inline. The disk is an IndexedDB overlay over a streamed base image, so the blocks you touch cache locally and the next boot is offline. There are no raw sockets (the browser has none to give), so its only network is curl/wget/git wrappers that relay through the extension's egress stack.

WebAssembly is the general lever here. A whole Linux box in a tab is just the first runtime peerd points it at; the same WASM confinement can host other heavy workloads (a language VM, a database, a native toolchain), so a new one is a matter of compiling it in, not inventing a new kind of sandbox.

The orchestrator the side panel is a view over. The loop, the tools, the memory, and the disposable runner that keeps untrusted page text away from everything valuable.

The loop

A streaming, abortable tool-use loop. Read-class tool calls run as concurrent waves; writes stay strictly serial. Each session has its own stop control, so steering one chat never disturbs a stream in another. Long sessions roll up into a trim summary; a crashed worker recovers from per-delta persistence.

do / get / check: the only browser surface

This is the load-bearing security decision in the whole product. The main agent has no direct DOM tools at all. To act on a page it calls do, get, or check, each of which spawns a disposable browser-runner: a fresh sub-agent with its own context, pinned to one tab, holding no memory, no keys, no network tools, no code-eval, and no ability to spawn. The runner drives the page and returns a plain-text summary. Untrusted page content and your privileged capabilities are never in the same model context.

Tools, gated

56 tools are registered; 44 are visible to the main agent and 12 (the low-level DOM and page tools) are runner-only, filtered from the main agent's tool list and refused at dispatch if it names one anyway. Every call runs a six-gate chain (persona, exposure, origin, confirmation, egress, audit) with the full gate lineage attached to the result, so the UI can show exactly what a call passed through.

Plan / Act, and one toggle

Safety is two controls. Plan lets the agent read and load URLs but never click, type, or submit; Act enables the rest. A single confirm toggle decides whether side effects pause for your sign-off. Plan/Act plus the denylist carry the weight.

And the rest of the brain

• Memory: file-based, AGENTS.md-style, hierarchical scope. New: auto-memory proposes a few notes at wrap-up that you approve or dismiss, never written silently.
• Commands & skills: slash commands, @-references, a fuzzy palette, and user-authored skills loaded on demand via progressive disclosure.
• Tool manifests: per-session tool exposure (/tools), inherited by every sub-agent as a narrowing, never an escalation.
• Hooks: pre/post tool-use, fail-closed; a pre-hook is the last veto before a side effect, even over a human yes.
• Voice: local Moonshine transcription with a Web Speech fallback, a hard mic kill switch, and a no-speech watchdog.
• Sub-agents, clock, cost, review, Ralph loop: depth-bounded sub-agents, temporal grounding, per-turn cost metering with a hard spend cap, a clean-context reviewer, and a persistent loop driver.

The one bet, made concrete: a real peer-to-peer network that lives in the browser. Every bit of routing, messaging, and storage logic runs in the page; the only servers are stateless bootstrap nodes that introduce two peers and then leave the data path. Built and tested today in the preview channel, the store build prunes this module entirely.

A network, and apps on top of it

peerd-distributed is two layers. A base network does the universal work, find other peers, learn who they are and what they can do, keep a healthy set of connections, and it is designed to run always-on in the extension's offscreen document so it outlives any single tab. Apps (dwapps) plug into it: each gets a scoped capability, peerd.distributed.dwapp, to open a sub-protocol, a private overlay on the shared connections where it speaks its own message types, be that chat, a shared document, or game state. A "room" is just a sub-protocol; the platform carries the bytes and never reads them.

What runs today

• Identity: native Ed25519 encoded as a did:key, private half non-extractable, seeded from the vault so it persists across restarts.
• Content addressing: peerd://<did>/<hash> URIs over signed manifests that commit to an ordered list of 256 KiB chunk hashes, so one signature covers every byte. Apps travel as signed bundles and install from a peer, verified chunk by chunk.
• The mesh: an N-peer WebRTC mesh of authenticated links. Each link proves the peer's did with a signed handshake before it joins, and frames are multiplexed by channel (control, DHT, direct, gossip). Rooms assemble three ways, a stateless rendezvous node, a relay through an existing member (so the room keeps working if the rendezvous dies, the "kill the server" beat), or an out-of-band paste-code. Trickle ICE connects on the first working path.
• Messaging: two shapes. Gossip floods a signed message to the whole room, deduped and rate-limited. Direct messages go to exactly one peer over only that peer's link and are never forwarded, private at the routing layer and carried by WebRTC's encrypted channel. Plus presence, who's here right now.
• The DHT: a Kademlia variant running over the same mesh, a distributed addressable directory. Records are signed and mutable with a monotonic no-downgrade sequence, so a stale value can't be replayed, and routing tables are reachable-only (a contact is added only after it answers, the fix for browser NAT churn). It is where a late joiner finds a dwapp or a peer it missed in the gossip wave.
• commons, the demo dwapp: one room code, a public chat for everyone, and genuinely-private one-to-one chats behind a request/accept handshake. It ships pre-loaded in the Library, tagged dweb, and travels peer-to-peer like any signed bundle.

How we know it works

The node logic is a pure actor: it only ever sends and receives opaque messages over its links, never reaching around the network. That makes the whole network simulatable, we run the real logic of many nodes against an in-memory transport, deterministically, and watch gossip flood, DHT lookups converge, and partitions heal. The same node code runs over real WebRTC in the browser and over a relay between separate OS processes, so a five-node network can be stood up and tested for real, not mocked.

Discovery and Sybil, honestly

Discovery is gossip-first, fast and churn-resilient, with the DHT for durability and stateless bootstrap gateways as the cold-start seed (bootstrap.peerd.ai is live). Sybil resistance without a consensus mechanism is an unsolved problem, and peerd doesn't pretend otherwise: signed identities stop forgery, local-only peer scoring and source diversity raise the cost of abuse, and an address book bucketed against any one source resists eclipse, but a determined attacker with many identities can still flood the network. That limit is stated, not hidden.