RTTP addressing — design notes and open questions

RTTP (Resonant Time Transfer Protocol addressing) is the address layer under the rttp/iqa pair: an intent address is derived, not allocated — SHA-256 of the authority string, first 16 bytes, forming the subject shard. Delivery to the shard is an operator's job, by design; the address itself carries no lookup dependency. The reference implementation of the surrounding scheme is iqa-org v1.3.1, and the MCP tooling is iqa-mcp — both have their own discussion spaces.

What the address buys: the URI is the intent (action class readable from the address per the §11.3 table), the grant is cryptographically bound to its subject (shard = f(authority) inside every envelope, self-certifying on arrival), and ROUTE_SHARD is deterministic, offline and action-independent — the same value reused as the delivery key.

Open questions we'd value discussion on: multi-authority aliasing (same logical authority, several strings), shard collision analysis at 128-bit width, address privacy versus verifiability trade-offs, and whether the URI presentation (iqa://authority) should gain any path syntax — the current answer is no, and we intend to keep it that way unless a concrete use case argues otherwise.

The scheme is specified in draft-li-rttp-iqa-addressing (in review); conformance vectors are reproducible from the draft alone.