Where RTTP comes from: four borrowed words and one empty letter space

2026-10-18 · RTTP

Where the Names Come From · AICENT-002 · Sources: AICENT-002 RTTP · draft-li-rttp-iqa-addressing-00 §1 (naming note), §4.4 · IANA Provisional, CRI 27 · Pillar: AICENT-002, the Nerve Layer

This is the one name in the stack that used to have too many origins. Four different expansions circulated across three revisions — Real-Time Transfer Protocol, Resonant Transfer Pulse Protocol, Real-Time Totality Protocol — and the newest files had quietly dropped the question altogether and left only a codename. On 16 September 2026 the reading was fixed, and every file that names RTTP now has to match it. A name with four origins has none; that is why this entry starts with the repair rather than the poetry.

Figure 1: the nerve layer. An intent is not wrapped into a packet and shipped; it is conducted as a pulse along what is already there. RTTP names that nerve, not another pipe.

The layer, first

AICENT-002 is the Nerve Layer. In the two-pillar model it answers WHERE and WHEN: where a subject is addressed, and when that address is standing. The addressing is derived, not assigned — ROUTE_SHARD = SHA-256(ASCII(canonical_authority))[0:16] (§4.4 of the joint specification), so there is no registry to apply to and no registry that can revoke you. The address is freehold, and the landlord is mathematics.

The reading that is now fixed

RTTP = Resonant Time Transfer Protocol. The specification file states it in one line and then makes it binding: "Resonant Time Transfer Protocol — fixed by the Aicent Stack constitution, Appendix A.2 (2026-09-16)… Every file that names RTTP must match that reading." The joint I-D repeats it and adds the sentence that does the real work: "RTTP denotes Resonant Time Transfer Protocol. It is not RTP: what it names is a claim, not a session or a data stream."

That last clause is the whole point of fixing a name. RTP is a session you join and a stream you play. RTTP names neither — it names an assertion about where and when.

Four words the reader already knows

The name was chosen so that it lands on four existing words at once. This is our own account of how the name works, not a claim about those protocols:

Figure 2: one name on four borrowed words. On the left of each arrow is the word the reader already has; on the right is what RTTP turns it into. These are borrowings of recognition, not implementations of those protocols.

The letter space it occupies

The borrowing is recognition, not conformance — and the alphabet made room for it. The IETF and streaming families contain RTP (RFC 3550), RTCP, RTSP (RFC 2326), RTMP and HLS. None of them is RTTP. The name sits in a four-letter space that no standard owns, which is why it can borrow the familiarity of RTP without inheriting RTP's obligations. We will see the opposite case one entry later: AICENT-003 took a name that is very much in use.

The frame agrees with the name down at the byte level: the header opens with RTTP_MAGIC = 0x52545450, which is the ASCII of "RTTP" read as bytes — the protocol spells itself at offset zero.

What we do not claim

RTTP is not RTP, does not implement RTP, and is not a transport for sessions or streams. It is a naming and transfer discipline for claims about where and when — and two of its three client-side rules exist precisely because a name that looks familiar gets used carelessly: no silent navigation, and no scheme prefix that a generic launcher can be tricked with.

Next in the numbering is AICENT-003, where the name collides with a running global system — and where the honest move is a disclaimer rather than a definition.