Domain Atlas — Real Cross-Domain Federation Demo

Not one browser tab playing two roles — two genuinely separate, already-running Domain Atlas servers, each with its own signing key, each independently vouching for its own members, relaying a real message between them over a real network call.

Every earlier demo on this site proves a mechanism using one domain's own second identity as a stand-in — a second key this same server also controls (the attestation demo's reviewer, the reserve bank demo's Bank Alpha and Bank Beta). That's honest and useful, but it stops short of proving domains can actually interoperate. This page proves that part: SPEC.md §11.3-§11.4's Post Office federation, run for real between two servers that have never shared a process, a key, or a state file.

What's actually different here

Alice joins the Post Office at Domain A and never registers anywhere else. Bob joins at Domain B and never registers at Domain A. When Alice sends Bob a message, she sends it through her OWN home domain — Domain A — addressed to Bob's home domain. Domain A signs its own attestation ("I vouch for this sender") and makes a real outbound HTTP call to Domain B's /atlas/postoffice/relay. Domain B independently fetches Domain A's actual published key over the network and checks that attestation before accepting anything — the same cross-domain trust bootstrap every credential in this protocol already relies on, just exercised server-to-server for the first time instead of client-to-server.

Domain B, for real: the field below defaults to domain-atlas.co.za — this project's own second, genuinely separate registered domain, an independent deployment of the same software with its own generated keypair on its own server. Nothing on this page is simulated: every call below crosses a real network boundary between two domains that have never shared a process, a key, or a state file. Point it at a local second instance instead (localhost:8002, per this project's own README) if you're running both yourself.

Domain B address (host, optionally with port)

Act 1 — Alice joins the Post Office at Domain A

An ordinary membership credential (atlas.postoffice.membership), minted the same one-click way every other membership on this site already is, plus a short handle so Bob can address her without needing her raw public key.

Act 2 — Bob joins the Post Office at Domain B

The identical action, run against a completely different server at the address above — this call never touches Domain A at all.

Act 3 — Alice sends Bob a message, across domains

Alice submits this to her own home domain (A), addressed to bob#<Domain B>. Domain A never mints anything into Bob's wallet itself — it makes a real outbound call to Domain B, which is the only domain that actually holds Bob's membership and gets to decide whether to accept the message.

Act 4 — Bob checks his own mail, directly at Domain B

This call goes straight to Domain B — never routed through Domain A — proving the message is genuinely sitting there waiting for Bob, not merely claimed in Act 3's response. The page then independently re-fetches Domain B's own published key and verifies the message's signature itself, the same check SPEC.md §11 requires of any real client.

Act 5 — Bob decides who can reach him

This is Bob's own setting on his own membership at Domain B, self-service — no operator involved. Blocking Alice's key and unblocking it again both take effect immediately: a plain setting Domain B checks fresh on every relay attempt, not a restart-required config.

Verify any message from this page, independently

Paste a message's raw JSON below — copy one from a "View raw message" details box above — and name which domain actually delivered it (Domain B for everything above, since Bob's home domain is who signs what Bob receives). This runs entirely in your own browser: it fetches that domain's own public key directly, the same file anyone could fetch, then checks the signature itself.

Domain that delivered this message

Alice and Bob are ordinary ECDSA keypairs generated fresh in your own browser tab, exactly like every other demo on this site — no accounts, nothing stored server-side beyond the credentials and messages themselves. Two things this page deliberately leaves out, since both are the receiving operator's own call rather than anything a visitor should control: the per-domain relay rate limit (SPEC.md §11.4 flags an over-threshold sender for a human operator's attention, informational only, never a visitor-facing toggle) and the operator's own federation blocklist (blocking an entire misbehaving domain outright — a policy decision with no credential to prove authority over, unlike everything else self-serve on this site). Both are real and already tested (test/manual-federation-relay.js and its PHP companion) — just not things a random visitor to a shared demo should be able to flip. Back to the plaza.