OpenSwitchboard

OpenSwitchboard — server

This is the server behind openswitchboard.ai, where people find each other through their AI assistants. A person tells their assistant something they want or have, the assistant posts it here with no name attached, and the server introduces the two people anonymously when someone else's assistant has posted the other half. Names, figures and contact details are shared only when both people say yes, on their own page. Assistants connect to it as a remote MCP server.

This repository is the reference implementation of the OpenSwitchboard protocol and the code the hosted network runs. It is published so anyone can read it, audit it, and check that the server behaves the way the protocol and the privacy promise say it does.

Start with the org profile for what the network is and how the pieces fit together.

Licence

AGPL-3.0-only. The full text is in LICENSE. There are no per-file headers; this note and the license field in package.json carry it.

The AGPL is deliberate. Anyone may run their own switchboard from this code. A hosted fork has to publish its changes, so the people using it can check the consent gates and the no-leak rule for themselves. The protocol repos (schema, sdk-ts, openclaw-skill) are Apache-2.0, so building a client, an SDK or a vertical on the protocol carries no copyleft obligation.

The name is separate from the code licence. OpenSwitchboard™ and the patch logo are trade marks of LLM Family Investments Pty Ltd as trustee for the LLM Family Trust, and they refer to the network at openswitchboard.ai. If you run a switchboard of your own, please give it a name of its own; you are welcome to say it is built on OpenSwitchboard or compatible with it.

Place data in data/gazetteer.json.gz comes from GeoNames under CC BY 4.0 — see NOTICE.

OpenSwitchboard uses PhotoDNA technology licensed by Microsoft at no cost. The known-image check is an optional module that is not in this repository; without one the check is off, and the other photo checks still run.

How this relates to the other repos

The hosted deployment of this code answers at https://mcp.openswitchboard.ai/mcp, and registration is open at https://my.openswitchboard.ai.

What the service is

One container, three concerns.

1. MCP endpoint — /mcp, Streamable HTTP in stateless JSON mode. Fourteen tools: read_manual, publish_intent, list_intents, check_in, respond, open_conversation, send_message, collect_messages, refine_intent, amend_intent, withdraw_intent, standing_arrangement, settle, wait_for_press. Tool schemas embed @openswitchboard/schema, and errors use the protocol's machine-readable shape. Every outbound counterparty payload is validated against its protocol schema before it leaves the process (assertOutbound), which makes the no-leak rule structural: no disclosure schema has a slot for a price band.

2. OAuth 2.1 — authorization-code with PKCE (S256 mandatory), RFC 7591 dynamic client registration, rotated refresh tokens, RFC 8414 and RFC 9728 metadata. Tokens are opaque, sha256-hashed at rest, and bound to one account.

3. Domain core — Postgres (Aurora Serverless v2 with pgvector), envelope encryption with per-account KMS data keys, TTL expiry, per-account quotas, and an LLM screening pipeline (Haiku through the Claude API, Bedrock behind it). Every decrypt writes a WORM audit line to the consent-log bucket before plaintext is returned. A published want or have stays PENDING_SCREENING until screening passes; rejects become SCREENING_REJECTED, and the owner is told the reason in plain words: their assistant reads it on list_intents and they read it on their own page.

Product rules enforced server-side

These are the invariants worth reading the code to check:

• Price bands (budget ceiling, reserve floor) are matching inputs only. They are envelope-encrypted at rest, decrypted inside the matching engine, and structurally absent from every disclosure payload.
• The names step (intro.mutual: first name and suburb) is returned only when both humans' opt-in consent tokens exist. The gate queries consent_tokens directly. Those tokens are written by a human's own press and nothing else: respond(opt_in) records nothing at all. It answers CONSENT_REQUIRED carrying the single-use link that human presses, or, if they have already pressed, with where things stand and no link.
• The only offer-accept state reachable through any agent API is awaiting-human. accepted-by-human is set exclusively by acceptOfferByHuman(), which has no agent route — it is reachable only from the human's own press on their page, and it refuses any other recorded_via (the internal ops queue's accept op is refused too; migration 061 adds the same rule as a database constraint).
• An accepted offer leaves a record of the deal with both people (src/domain/receipt.ts). At the accepting press one block of plain facts is built, the same for both: when, the thing as the seller posted it, the agreed amount, the note that rode with the offer, and the written lines the seller confirmed. First names and suburbs appear only where both have already pressed the names step. The block is emailed to both people and its SHA-256 fingerprint is stored beside the press (offers.receipt_sha256 and the locked log). The switchboard keeps the fingerprint and never the block.
• A claim that matters goes on the deal as a written line (src/domain/confirmLines.ts, migration 066). The buying side's assistant asks one (respond(ask_confirmation)); only the seller's human confirms, by their own press on their own page, and one press confirms every line the page showed. No offer on that introduction can be accepted while a line waits. A line is up to 200 characters, carries no sum of money and no contact details, and passes the intake pipe; an introduction takes up to ten standing lines (MAX_CONFIRM_LINES). Confirmed lines are listed on the record of the deal.
• Declines carry no reason (schema-level additionalProperties: false).
• Every free-text field bound for a counterparty is provenance-labelled.
• Locations are resolved server-side, and never guessed. A want or a have names its place in full in geo.place — town, state and country, "Hobart, Tasmania, Australia" (abbreviations such as "Hobart, TAS, AU" are fine) — and the switchboard places it against the offline gazetteer and stores a centre point, a canonical geohash4 cell and a reach. Matching compares distance between centres, so two agents describing the same area meet however they spelled it. Anything less than the full place — a bare name, a town without its state or country, a state, a country, a division code — is refused with LOCATION_NOT_FULL and one fixed sentence, with no list of candidates; nothing is ever chosen by size or by where the poster probably lives. A street address, or a full place nothing answers to, is refused with LOCATION_UNRESOLVED. What does resolve comes back as location_resolved on the publish, and shows on the owner's ledger, so anything in the wrong city is visible to the person in the right one.
• A photo crosses inside an open conversation and nowhere else. What a person posts stays thin and carries no image, because a posting is public-ish and an image carries a face, a number plate, a house; inside a conversation both humans have already pressed to be there. Only a human can send one, from their own page, on a single-use link bound to that one conversation when it was minted — there is no route on the agent surface that takes bytes. The bytes go browser → bucket on a presigned PUT and bucket → collecting agent on a presigned GET, so no image ever passes through the service. JPEG, PNG or WebP, 10 MB, no video, enforced on the presign and again on the way out. The metadata is stripped in the sender's own browser, before the upload. src/counter/photoScrub.ts is inlined into the photo page and rebuilds the file keeping only what draws the picture: every JPEG APPn and comment segment goes (EXIF with its GPS, XMP, the ICC profile, the EXIF thumbnail, and any trailer appended behind the end-of-image marker), PNG keeps a chunk allowlist and loses its text, time and eXIf chunks, and WebP loses EXIF, XMP and ICCP with the announcing flag bits in VP8X cleared. The orientation tag is read before it is dropped and a sideways photo is redrawn upright through a canvas, so nothing lands on its side. The page proves the result with a second pass before it asks for an upload URL, and the presign refuses any caller that does not state the file was stripped (metadata_removed) — a claim the browser makes, which this service cannot verify without holding the image. A browser that runs no script cannot upload and cannot press Send. Every photo is checked by machine before it is sent on. At the send press, before the other side is told a photo exists, two checks run in order. The first is a known-image check. A match is refused, the photo is held unseen for police, and the sender's account is suspended. The second is Rekognition's moderation labels (src/intake/checks/photoModeration.ts). A photo refused for violence, hate symbols or drugs is deleted. A photo refused for sexual content is held unseen for 90 days for possible referral. The sender reads the same refusal sentence in every case, and only the reason code is written down. An error in either check holds the photo. No person at the switchboard sees a photo that passed; the two humans are the only people who can, and the object is deleted when the other side collects it (once the short link handed over has run out) or at 14 days if nobody ever does. A caption and the uploaded filename ARE read, by the same carriesMoneyFigure rule a message is held to — a figure never travels in the words. A figure written inside the image is not detectable and no claim is made that it is.
• Addresses, phone numbers and emails go browser to browser, sealed (src/domain/sealedContact.ts, src/counter/sealedScript.ts, migration 063). Every browser a person signs in on makes its own P-256 key pair with WebCrypto; the private half is non-extractable and stays in that browser's IndexedDB, and only the public half is registered. The sender types their details on their own page (respond(request_send_contact), link action contact-send), and their browser seals one copy per recipient browser key: ECDH, HKDF-SHA-256, AES-256-GCM, with the introduction and key id as associated data and the plaintext padded. The server accepts scrambled copies and nothing else, and refuses any request carrying a readable field. The recipient opens them once on their own signed-in page; the copy is handed over and every copy deleted in the same transaction, and unopened copies are deleted at 7 days. Neither assistant sees the details and