FastPubSub Network
Live pub/sub. Paths that heal themselves.
Live pub/sub. Paths that heal themselves.
What already works. What we are building. Ideas we have not promised.
Core systems that are operational today
QUIC relay backbone is live. PoPs spread across the globe. Relays discover each other, establish encrypted tunnels, and form a resilient mesh. When standard Internet links fail, the overlay reroutes on its own— recovery starts almost immediately and completes within seconds.
Publish/subscribe is working end-to-end. Writers publish to the nearest PoP, the relay mesh forwards along the best measured path, destination PoP fans out to all subscribed listeners.
Scoped access token authentication is in place. Clients receive tokens with scoped permissions (publish/subscribe per channel). Tokens are validated on every PoP.
Central management service is operational: tenant management, token issuance, configuration push to PoPs.
Relays continuously measure RTT between each other and compute fastest paths using measured-path routing. Traffic is routed through the lowest-latency path in real time.
dashboard.fastpubsub.com — real-time world map of PoPs, overlay vs direct latency comparison, network anomaly detection. Uses our own FastPubSub infrastructure to deliver live updates to the browser.
The first FastPubSub SDK is available for Rust: fastpubsub-sdk on crates.io. It provides a simple client library for application integration.
JavaScript and TypeScript client library for browser and Node.js: @fastpubsub-sdk/client on npm. Connect, publish, and subscribe with auto-reconnect and token refresh.
Public demo server at demo.fastpubsub.com: Paint Board, Online Radio, and Video Meeting. The server issues access tokens only; the master token stays on the backend.
Early-access admin UI at cockpit.fastpubsub.com: overlays, master and access tokens, users, and passkeys. Live per-channel metrics, connection maps, and client logs are still in progress.
Product docs are live at doc.fastpubsub.com: quickstart, tokens, channels, WebSocket and REST API. More integration examples are still being added.
Real WebTransport in the JavaScript (browser) and Rust SDKs, next to WebSocket. Unidirectional subscribe lines are supported. Node.js without a WebTransport global is not supported yet.
Client filters for latest-only, delta, fragment, encryption, and bandwidth. Access tokens can set ingress and egress kilobyte-per-second rights. Tenant-wide abuse protection is still separate work.
Message routing and delivery do not depend on one central node. The control plane is redundant: working routes keep carrying traffic if a control-plane instance is down.
Core infrastructure and tools needed before public launch
Per-PoP and per-channel metrics: message rates, connections, latency histograms, GeoIP, bot detection. Prometheus export + internal dashboards.
Meeting media encryption and waiting room. Keep Paint Board and Online Radio as public reference apps.
Harden the browser WebTransport path and add Node.js support where the runtime exposes WebTransport.
Per-channel rates, connection map, and client logs in Cockpit. Token and overlay management already work.
Per-tenant and per-channel rate limits (msg/s, bytes/s, connections). Backpressure, slow-consumer drop policy, IP-based throttling. Token-level bandwidth caps already exist.
Extra integration guides and reference apps on top of the live docs site.
Publish C# and Java client libraries. Both wrap the Rust SDK today in the repo; they are not yet a public package.
Message counters per tenant, usage aggregation, quota enforcement. Foundation for paid tiers and metered billing.
Concepts we are thinking about. Not committed yet, but high potential.
Who is online in a channel, subscriber count.
A ready-made HTTPS endpoint on the nearest PoP where clients can POST events. We turn them into channel messages and fan out to listeners instantly. Universal webhook receiver with zero infrastructure for the client.
FastPubSub as a "network adapter" between external protocols and our channels. Connect existing systems without rewriting them for our SDK.
A customer-hosted node inside a private network. Exposes local WebSocket/HTTP endpoints and maintains an outbound-only mTLS tunnel (WebSocket or WebTransport over TLS) to the FastPubSub fabric. No inbound firewall ports needed.
Game-specific features on top of the existing WebTransport transport: unreliable datagrams, drop-old policies, adaptive tick rate, and spatial subscriptions. The transport itself is already in the SDKs.
Run tenant-provided WebAssembly logic in a sandbox at the FastPubSub edge. The module acts as a programmable session controller and message firewall for traffic from clients, traffic sent back to clients, and subscription changes.
An optional delivery mode for events that should become visible across distant regions at nearly the same moment. FastPubSub first propagates a message to the participating edge locations, optionally waits until all required edges report readiness, and then releases it using a shared target timestamp.
An optional SDK filter for ordered, acknowledged delivery between two clients when a live channel is not enough. Default pub/sub stays fire-and-forget.