AP0110 Lab
Coordination Server
The infrastructure that introduces devices to each other — then gets out of the way.
The problem with connectivity infrastructure
Most "serverless" peer-to-peer systems are anything but. They route traffic through central servers that log it, inspect it, and hold it. The server becomes the single point of trust — and the single point of failure. When it's compromised, breached, or compelled, everything it ever touched is exposed.
The coordination server is built on a different premise: a server that has never seen your data cannot leak it.
What it does
When two devices need to find each other across the internet, they need something in the middle — briefly. The coordination server is that something.
It handles the introduction. It relays the handshake. Then it steps aside, and the two devices talk directly.
That's the whole job. Anything beyond it is out of scope by design.
Why that constraint is the product
Most infrastructure providers expand their surface area — more state, more logging, more services layered on top of the connection. We contracted ours.
The coordination server holds no application data. It does not inspect what your devices are exchanging. It has no concept of files, messages, channels, or content. It does not log the payload of the connections it sets up. If we were compelled to produce records of what your devices communicated, we could not — because we never had it.
This is not a privacy policy. It is an architecture.
"The cheapest way to defeat a 'harvest now, decrypt later' adversary is to make sure the server has nothing worth harvesting."
A platform, not a feature
The coordination server is intentionally application-agnostic. It does not know whether the devices it connects are sharing files, running a video call, synchronizing a document, or doing something no one has built yet.
This means you can build any of those things on top of it. Adding a new application to your product requires no server changes, no new endpoints, no coordination with us. You write client-side code; the infrastructure already supports it.
File sharing, encrypted messaging, real-time collaboration, custom peer protocols — the platform was designed so the list never needs to end.
// Independent Internet
The connection layer of Web 4.0
Web 4.0 — the Independent Internet — is about owning the connectivity itself, not just your data. That requires a way for devices to find each other without handing the connection to a provider who can log it, inspect it, or cut it.
The coordination server is that introduction layer: open, self-hostable, and built so no central operator — us included — sits in the path of what you send. It's how peers meet on a network with no single point to fail or be seized.
Built in to AP0110 products
If you're already building on AP0110, the coordination server is already there. Every AP0110 product uses it by default. You get the same infrastructure — the same architectural guarantees — without standing anything up.
Available to everyone else
Hosted
Registered accessUse the AP0110-operated coordination server directly in your own products. Register for access and build against the SDK. No infrastructure to run.
Self-hosted
FreeRun your own instance for private use. The server is open and self-hostable. Your devices, your infrastructure, no dependency on us.
Self-hosted
EnterpriseProduction-grade self-hosted deployments for organizations with compliance, data-residency, or scale requirements. Supported, auditable, yours.
The SDK
The coordination server comes with an SDK for building products and services on top of it. Device identity, contact management, connection lifecycle, and the signaling layer are handled for you. You write the application; the SDK handles the handshake.
The wire interface is stable and documented. Everything the server and client agree on is a contract — not an implementation detail.
What you get
Devices find each other.
Across NATs, across networks, across the open internet. The connection setup that is genuinely hard is handled.
Direct connections.
Once introduced, devices communicate directly. Traffic does not route through our servers. We are not in the path.
Cryptographic identity.
Each device generates its own keypair locally. Identity is verified by the devices themselves, not by the server. No central authority issues or revokes credentials without your knowledge.
Opaque signaling.
The server sees envelopes. It does not see contents. Your application protocol is your business.
Rate limiting at the boundary.
Abuse is caught before it reaches your application — per device, per IP, before any signal is forwarded.
What it doesn't do
The coordination server does not store your data, log your connections, or know which devices trust each other.
- × It does not store your data.
- × It does not log your connections.
- × It does not know which devices trust each other.
- × It has no user accounts, no access control lists, no content policies — because it has no content to enforce them against.
If you need a server that mediates ongoing application state, this is not it. If you need a server that can be subpoenaed for conversation history, this is not it.
If you need devices to connect directly, privately, and verifiably — this is exactly it.
The Coordination Server is coming soon.
Join the waitlist to be notified at launch and get early SDK access.