Demo Center
Live demonstrations of the two companion URI schemes, from the offline conformance sandbox to a networked multi-agent scenario. All demos are non-normative: they implement the rules of draft-li-rttp-iqa-addressing-00 but prove nothing by themselves — the specification and its conformance vectors do that.
Two Agents & a Live Organ
Two independent agents exchange real HTTP with a live organ service. Standing reads are read-only; attest / revoke / audit really transition state and really refuse without explicit consent. A wire log shows every packet; a watcher lets one agent observe the other's transitions live.
Three Organs, One Subject
The dispute scenario. Standing is organ-relative by design (5.3): drive three real organs independently, poll them all, and watch a relying party handle disagreement — attributable answers, read-shaped protocol, and the trust decision left exactly where the scheme leaves it.
Browser ↔ Derivation Service
Your browser derives ROUTE_SHARD with its own crypto.subtle while a real derivation service derives it again over HTTP with strict server-side ABNF validation — then the page compares the two byte for byte and anchors both to the published pinned vectors. Batch mode included.
Envelope Verifier
Verify and mint iqa attestation envelopes entirely in your browser: AID self-certification (AID = SHA-256(pub)), canonical signing input, the 120 s freshness window, the closed sets — and the published pinned vector, replayed byte for byte. Migrated from iqa.org/URI.
Conformance Sandbox
The original single-file demo: strict ABNF parsing, the ROUTE_SHARD derivation (with the published-vector replay), the Table 1 action safety classes, the consent gate, and an 18-case self-test — no network, no state, nothing leaves your browser.
QAFour questions, answered
Why not just use regular https URLs?
A https URL states where a resource lives — you must fetch it to know anything. An rttp URI is computed, not looked up: the address is derived from the authority by SHA-256 (§4.4), with no DNS, no registry query and no fetch. The intent is part of the identifier itself, and anyone can verify the derivation offline.
Why two schemes instead of one?
Because they answer different kinds of questions. rttp answers where — by pure computation, needing no one's word. iqa answers whether — a named Organ's verdict about a subject. Splitting them into two namespaces keeps the question channel and the attestation channel apart: the computation never depends on anyone's word, and the attestation never pretends to be computation.
Isn't hash addressing just content addressing (like IPFS)?
Relatives, not twins. Content addressing derives an address from the bytes of a blob. rttp derives from the authority only and is action-independent: the same authority under different actions yields the same address — an address is where, not what (§4.4). It names the place of an intent in the grid, not the bytes of a file.
What about security?
The default operation is read-only (§11.1); every state-changing operation requires explicit consent, enforced in the client and again server-side (§4.5.3, §5.4). An unreachable endpoint fails closed (§12) — silence is never treated as assent. Seals are HMAC-SHA256 over the canonical claim, bound to the subject's key material: verification is offline and needs no issuer, no key directory, no network call.
Don't take our word for it — replay the vectors at iqa.org/challenge/.
The URI Center — install, replay, verify
The product-side companion to these demos: real packages on PyPI, npm and crates replay the 35 published conformance vectors across three independent implementations (Python, JavaScript, Rust) — offline, zero dependencies, byte for byte. Plus the AICENT-002 narrative layer: framing, seals and the agent-verb story around the schemes.
More scenarios are reserved on this page. The demos share one shape — one question, one answer: rttp computes where an intent lives, iqa states whether an organ stands behind it.