At the arrival point: three questions, three answers
Sources cited in this piece · the breakout proposal: post 0010, 21 October (Sean Mann, RP1) · our three questions: post 0042, 27 October · the specification: draft-li-rttp-iqa-addressing (datatracker) · the channel spectrum: iqa.org/scenarios · the normative pages: rttp.com/URI/ · iqa.org/URI/ · the published packages, counts verified 2 November on isolated installs: rttp 1.3.1 (PyPI) · iqa-org 1.3.1 (PyPI) · the registries: rttp, CRI 27 · iqa, CRI 28 · Sister pillars: RTTP (rttp://) · IQA (iqa://)
On 21 October, Sean Mann (RP1) posted the proposal for a TPAC Dublin breakout on spatial computing, digital twins, physical AI and robotics. The sentence that drew our attention was not about browsers at all: post 0010, quoted verbatim — “Reaching them takes spatial browsing. A device would find what's published at a location as a person or robot arrives, without anyone typing a URL, and combine content from many independent publishers into one 3D scene.”
On 27 October we replied with three questions — post 0042: naming what is published at a place, freshness at the arrival point, and binding a twin to its building — “all asked from the arriving device's point of view.” The session met on 28 October. Its summary has not yet appeared on the list. We are not going to wait for it, and we are not going to fill the silence with predictions: the questions were ours, and the stack we maintain already runs a worked answer to each one. Below, each question is answered the only way we answer anything — by pointing at a mechanism, a section of the specification, and a computation anyone can redo offline.
Two names first, spelled out once. The RTTP (rttp://) pillar is the Resonant Time Transfer Protocol: it answers where and when. The IQA (iqa://) pillar is Identity Quality Assurance: it answers whether. Both schemes are specified together in draft-li-rttp-iqa-addressing (revision 2, posted 1 November) and registered provisionally as CRI 27 and CRI 28.
One — the name is computed, not issued
Question 1 (post 0042, quoted verbatim) · source on the wall
“What is the intended name space for location-anchored services — names issued by a registry (DNS- or DID-style), or names that can be derived from the publisher or the content itself, so that discovery keeps working when no registry is reachable from the arrival point?”
Our answer is the second half of our own question: derived. An rttp address has the form rttp://<intent>.<pillar>.<root>[/<action>], and its routing component is not stored anywhere — it is computed: ROUTE_SHARD = SHA-256(ASCII(canonical_authority))[0:16] (Section 4.4 of the draft). The name exists because the publisher's canonical authority exists, and for no other reason. Nothing was issued, so nothing can lapse, expire, or be revoked at the naming layer.
The draft carries a worked example on reserved test names: authority f3b2a1c4.pillar.example yields ROUTE_SHARD = 557c8154d3780cb78cc5fa1bd72b331c. Any party — the sender, the receiver, an auditor with no network access — recomputes the same sixteen bytes from the same string with a hash function and nothing else. That is the property the question asked for: discovery keeps working when no registry is reachable from the arrival point, because nothing in the naming step ever contacts one.
And the design does not merely avoid lookup — the client rules forbid it, so that no compliant implementation can quietly reintroduce the dependency. Section 4.5.4 of the draft, quoted verbatim: “A client MUST NOT perform a lookup in order to use an rttp or iqa URI: no DNS query, no registry query, and no fetch of any resource named or implied by the URI. Use of either scheme is a local computation; there is no resolver to poison and no registration to hijack.”
The arrival point is exactly where issued names are weakest. A plant basement, a disaster site, a gated perimeter — these are places where DNS trees are unreachable and DID resolution is a fair-weather feature. A derived name does not degrade gracefully when the network disappears; it never needed the network in the first place. The weakest point of the registry model is the strongest point of the derived one, and they are the same point.
Two — the bytes carry their own clock
Question 2 (post 0042, quoted verbatim) · source on the wall
“Does the session's model assume online verification at discovery time, or can published claims carry their own locally checkable time boundaries — an issue time, a validity window, or a standing lease — so that a device can judge how old what it found is, offline?”
Our answer: the third option, by construction — and not as an issue time stapled to a payload, but as a field of the verification answer itself. Section 6.1 of the draft, quoted verbatim: “Every attestation answer produced under the iqa scheme carries its freshness window in-band: the answer states the instant until which it may be relied on, in a field of the answer itself (the lease_expiry field of Section 7.2), not in a cache header, a lookup result, or an out-of-band agreement.”
The check that consumes this field is deliberately local. Section 6.1 again, verbatim: “A verifier checks the stated expiry against its own clock. The check is local and offline: no network call is involved in deciding whether an answer is fresh.” An expired lease must be treated as expired; a verifier must not extend, renew, or reinterpret it except by obtaining a new answer. Nothing about that procedure requires a connection — which is precisely what a device in a basement has none of.
The window is short by design: current deployments use 120 seconds, and operators may configure other lengths. The draft is explicit about what the number is for: it “constrains the verifier's honesty, not the speed of any channel.” A device that accepts a statement older than its lease is asserting more than it knows — the lease exists so that it cannot do that quietly.
Arrival points, meanwhile, are not one network condition but a spectrum of them, and the lease design spans that spectrum deliberately. Three modes, quoted verbatim from iqa.org/scenarios: live lease — “120 s window · reject on skew” — for minutes-level channels; lease residual — “last known lease · age stated in the bytes” — for store-and-forward; archival — “no freshness check · seal fully verifiable” — for printed, carried, and stored records. The design sentence for the middle of the spectrum is the one we keep coming back to: “The satellite is a courier, not a network. The 120 s window is not expected to hold; the bytes say how old the claim is.”
Three — the binding is carried, not looked up
Question 3 (post 0042, quoted verbatim) · source on the wall
“What establishes that binding, and what lets the arriving party verify it on its own — a registry lookup, or an attestation the publisher carries and the arrival can check without contacting anyone?”
Our answer: an attestation the publisher carries. The attestation envelope specified in Section 7.2 of the draft is 128 bytes with fixed offsets: a magic value and version, the lease expiry, the sixteen-byte shard, the attestation value, the named organ, a one-byte standing value, and an HMAC-SHA-256 computed over the entire frame. Reading it takes a hash function and a constant table of offsets; there is no resolver anywhere in it.
What the arriving party can check on its own, before contacting anyone, comes in three layers. First, the shard — offline: the envelope's shard must equal the route shard derived from the authority the publisher claims, the same sixteen bytes as the address's derivation. A twin that does not bind to the authority in the publisher's claim fails this check in local computation, before any trust question even arises. Second, the structure and the clock — offline: fixed offsets mean the lease expiry can be read and judged against the local clock, exactly as in Question 2; the second answer's mechanism applied to the third answer's artifact. Third, the verdict — the organ's business: the envelope names the organ that vouches, and weighing that name is what the verification answer is for, evaluated at the moment of use (Section 6.3) and degrading, when the network is absent, along the mode spectrum of Question 2 — never silently upward.
And when a check cannot be completed, the design fails closed, in a vocabulary the draft fixes as a closed set of five refusal reasons whose priority order is part of the definition. The one an arrival point needs most is authority_not_determined, and the draft's own words are exact: “An unreachable source is refused under this value, never read as assent.” Silence from the network is not consent from the world — for a robot standing in front of a building, that single sentence is the difference between a designed behavior and an incident report.
One caution from our own discipline, because the three questions invite it: an address is where, not what — and not when. Derived is not identity. The hash names the place; the envelope vouches for the claim; the binding lives in the second column carrying its own bytes, never in the first column pretending to be a proof. A twin bound only by a matching name is a twin bound by nothing.
What this piece is not
It is not an agenda push. The three questions were offered for the floor and remain open for any arrival-point design; the session's model may have good answers of its own, and when its summary appears we will read it with interest — post 0042 said exactly that, and it still holds. Answering our own questions in public is not a substitute for the discussion; it is what lets the discussion start from mechanisms instead of vocabulary.
It is also not a claim without receipts. The specification is public: revision 2, forty pages, in the Independent Submission stream. The normative grammar and the standing semantics are published and sealed at rttp.com/URI/ and iqa.org/URI/. The mode spectrum lives at iqa.org/scenarios. And the published packages carry self-test counts we verified this week on isolated installs from PyPI: rttp 1.3.1, 83 of 83 checks; iqa-org 1.3.1, 111 of 111 checks.
The floor in Dublin met for an hour; the floor online never closes. Three questions were left at an arrival point, and three answers were already running there: a name computed rather than issued, a clock carried in the answer itself, a binding an arrival can verify without contacting anyone. The questions belong to the session. The answers belong to anyone who arrives — and every one of them can be checked in a basement, with no network and no permission, from bytes that are already public.