Browser ↔ Real Derivation Service

You type an rttp:// URI. Two independent implementations then race: your browser derives ROUTE_SHARD locally with its own crypto.subtle, while a real derivation service on this server (/rttp-api/, strict server-side ABNF) derives it again over HTTP. The page compares the two byte for byte, and anchors both to the published pinned vectors. One address, one truth.

Demo-grade and non-normative. The service enforces the rules of Section 4 independently of this page: uppercase is rejected, not normalised; no userinfo, port, query or fragment; the derivation uses the authority alone.

rttp URI

Both sides idle. The pinned vector anchors everything: brain.epoekie.aicent → 459e543b73d86005b72ba77d5756e83c.

Batch — one URI per line, all sent to the real service

Wire log — every real packet

no requests yet

What is real here

The derivation service is a real HTTP endpoint on this server with strict server-side validation — send it garbage with curl and it refuses exactly as the draft requires.
The browser side is a second, independent implementation: no shared code with the service. When the two agree byte for byte, that is a cross-implementation check happening live, in front of you.
The pinned vector replay ties both sides to the published conformance corpus.
What is not here: any network routing. ROUTE_SHARD is an address, not a connection — derivation is pure computation on both sides (Section 4.4).