rttp — V1.2.8 release reading

Scope of this reading. This is the current-release (V1.2.8) reading of AICENT-002. The scheme itself is unchanged against V1.2.6 — same syntax, same frame layout, same route-shard derivation. V1.2.8 changes packages and conformance coverage, not the protocol. The frozen V1.2.6 reading is on the second tab; the non-normative Aicent Stack narrative is on the third.

An rttp URI names a claim of intent directed at an identified subject. The address of that subject is derived by computation from the URI authority; no lookup service, registry, or name-resolution system is consulted at resolution time.

• Scheme: rttp
• Status: submitted to IANA, Provisional, pending — not registered (ticket [IANA #1459939])
• Specification: draft-li-rttp-intent-addressing-01
• Channels: PyPI rttp 1.2.8 · npm @aicent/rttp 1.2.8 · crates.io rttp 1.2.8-alpha — one stack version, two channels; the superseded 1.2.7 releases were yanked
• Source: github.com/Aicent-Stack/rttp

Conformance — asserted by CI on every push

• Python, default install (zero dependencies): 80 checks passed (3 skipped)
• Python with the optional Ed25519 backend: 83 checks passed
• Node (npm): 35 checks passed
• Rust (crates.io): 37 checks passed (1 skipped), 38 with --features ed25519

Three individual implementations — Python, JavaScript, Rust — share no code and agree byte for byte on the same published vector set (sha256 4b743e63..., shipped inside every package). Every count above is re-asserted by CI on every push; drift fails the build.

Try it in one line

pip install rttp && python -m rttp.selftest     # [PASS] all 80 checks passed (3 skipped)
npm install @aicent/rttp && npx @aicent/rttp    # [PASS] all 35 checks passed

Full release overview, live verification and the vectors: https://rttp.com/URI/

rttp — a URI scheme for intent addressing

Scope of this reading. This is the frozen V1.2.6 reading of AICENT-002. It states what the rttp URI scheme is and what a client must do with it, and nothing else. The Aicent Stack narrative, unchanged and explicitly non-normative, is on the third tab.

An rttp URI names a claim of intent directed at an identified subject. The address of that subject is derived by computation from the URI authority; no lookup service, registry, or name-resolution system is consulted at resolution time.

• Scheme: rttp
• Status: submitted to IANA, Provisional, pending — not registered (ticket [IANA #1459939])
• Specification: draft-li-rttp-intent-addressing
• Conformance: a published set of deterministic conformance vectors, replayed by individual implementations that share no code

Address form

rttp://<intent>.<pillar>.<root>/<action>

• intent — either eight lowercase hexadecimal digits, or a readable label
• pillar — operator-chosen label, the processing layer
• root — operator-chosen label, the operator
• action — an optional verb on the intent

The routing label (route shard) is a 16-byte value derived from the canonical authority, so the same authority always yields the same route shard. Resolution is a computation, not a query: no DNS, no TTL, no registry lookup on the resolution path.

What a client must do

• MUST NOT perform a lookup in order to use an rttp URI.
• MUST treat an rttp URI as a claim of intent, not as a proof about the subject.
• MUST NOT render an rttp URI as an IRI.
• MUST NOT acquire the ability to handle rttp URIs without an explicit action by the user.
• MUST reject input whose scheme is neither rttp nor web+rttp.

Registration

The scheme is described in the document cited above, and its IANA Considerations section carries the registration template. The request is pending; the scheme is not registered.

Change controller: RTTP.COM Organization · Contact: ShaoBao Li <lee@rttp.com>

This tab is the original Aicent Stack narrative (v1.3.0). It is preserved here as-is, for the record, and is not normative. The normative reading of AICENT-002 is on the first tab, and the specification itself is the Internet-Draft cited there.

Organism Vitality & Protocol Audit

"This is not infrastructure for intelligence. This is intelligence itself."

⚪ AICENT | 💎 RTTP | 🔴 RPKI | 🟢 ZCMK | 🟡 GTIOT | 🟣 AICENT-NET | 🎭 BEWHO | 🌿 epoekie | 👁️ PICSI

💎 AICENT-002: RTTP.COM | The Superconducting Nerve

Resonant Time Transfer Protocol (RTTP).

Resonant → AICENT-006 (Hive) / AICENT-002 (Nerve coupling) · Time → AICENT-011 (ITSUN) / AICENT-012 (MOLOON 12-cycle) · Transfer → the legacy-transport coat · Protocol → structural head

• Status: Imperial Standard (Active / Private)
• Version: v1.3.0-Alpha (Neural Singularity)
• Reflex Arc: 349 Nanoseconds (Nitro-Engine Path)
• Clock Accuracy: 12ns Jitter-Locked
• Addressing: 256-bit AID-Soil Anchored

1. ABSTRACT: BEYOND THE PACKET

AICENT-002 defines the Nerve Layer of the Aicent Stack—the high-conductivity spine responsible for the sub-microsecond shunting of 128-bit intents between functional organs.

In the v1.3.0 "Genesis" era, RTTP has evolved from a packet-switched logic to a Direct Register Suture. By bypassing the Operating System's networking stack and memory-bus arbitration, RTTP ensures that the "Will" of the Brain reaches the "Torque" of the Body in 349 nanoseconds. This speed is physically superior to the thermodynamic noise of legacy 10ms networks (Ghosts), rendering external interference physically impossible.

"RTTP is the bridge between Intent and Reality. It is the only protocol in existence that moves faster than the heat of the silicon."

2. THE EVOLUTIONARY LEAP: FROM 161.8µs TO 349ns

The transition from v1.2.5 to v1.3.0 represents a 463.7x performance collapse, achieved through the Nitro-Engine Bypass Strategy.

2.1 The Legacy Ischemia (v1.2.5)

In the open-source era, RTTP relied on software-level bypasses which, while achieving a revolutionary 161.8 µs reflex arc, were still subject to the "Software Pathogens" of modern CPU scheduling.

2.2 The Radiant Singularity (v1.3.0)

The v1.3.0 Nitro-Engine implementation utilizes MMIO (Memory-Mapped I/O) Register Shunting.

• Zero-Copy Conduction: Data never leaves the L1 instruction cache.
• Hardware Suture: 128-bit intents are stacked directly onto the CPU registers (AVX-512 level), bypassing the RAM entirely.
• Result: The measured end-to-end conduction latency is now 349 ns, effectively achieving logical superconductivity.

3. THE THREE NEURAL ORGANS

RTTP v1.3.0 orchestrates the Imperial nervous system through three specialized manifolds:

1. Pulse Header (AICENT-002-A): A clinical 128-byte structure designed for 5ns hardware parsing. It contains the 12ns jitter-lock and the 256-bit AID origin.
2. Nerve Conduction (AICENT-002-B): The manager of rhythmic flow. It enforces the 1.2kHz (833us) heartbeat across 17 pillars, ensuring no "Neural Ischemia" (latency drift) occurs.
3. Nitro-Driver (AICENT-002-C): The private core driver that maps Aicent logic directly to the silicon. Access is strictly gated by the Radiant Seal (AICENT-009).

🚀 V1.3.0 Performance Manifest

4. THE PULSEHEADER128 ANATOMY

In the v1.3.0 era, every neural pulse is encapsulated within a clinical PulseHeader128. This is a 128-byte hardware-aligned structure designed to resonate with the CPU's dual cache-line architecture, ensuring zero memory-bus pathogens.

4.1 Structural Layout (Register-Optimized)

4.2 Zero-Copy Finality

Unlike TCP/IP or ROS2, RTTP v1.3.0 does not "read" headers. The Nitro-Driver maps the entire 128-byte header directly into the AVX-512 register bank.

• Parsing Latency: < 5 ns (Single clock cycle comparison).
• Pathogen Resistance: Any header arriving with an invalid Jitter-Lock is physically unable to trigger the gate, causing it to "Evaporate" without consuming CPU cycles.

5. THE NITRO-BYPASS STRATEGY

The 349ns miracle is achieved through the systematic elimination of the "OS Middleman." In Aicent Stack v1.3.0, the neural spine is no longer a guest of the Operating System; it is the Host of the Silicon.

5.1 MMIO Direct Register Suture

The Nitro-Driver (AICENT-002-C) establishes a private memory-mapped I/O (MMIO) conduit at 0x4149_434E_0000_0000.

• The Suture: Digital intents are shunted directly from the Brain's L1 cache to the hardware registers of the GTIOT limb or ZCMK bank.
• Bypass Logic: By using raw volatile pointers, we bypass the OS Scheduler, the Kernel Interrupt Handler, and the PCIe Bus Arbitration.

5.2 L1 Instruction Sanctuary

In the v1.3.0 implementation, the RTTP conduction logic is Physically Pinned to the L1 Instruction Cache.

• Result: The CPU never "fetches" the protocol from RAM. The protocol is always there, idling at the speed of the 12ns crystal oscillator.
• Nitro-Path Efficiency: Total instruction overhead per pulse conduction is reduced to < 800ns on standard silicon, collapsing to 349ns on Radiant-optimized substrates.

5.3 The Dual-Path Law

The Nerve Hub (RTTPController) automatically arbitrates between two paths based on real-time Homeostasis (HS):

1. Standard Path: 161.8 µs (Software-gated). For Resident nodes.
2. Nitro Path: 349 ns (Hardware-sutured). Reserved exclusively for Radiant Sovereigns (Lisa/i-SGR).

6. PHASE-LOCKING & JITTER ENFORCEMENT

RTTP v1.3.0 enforces a Planetary Metronome via AICENT-006-A integration.

• 12ns Jitter Limit: Any pulse deviating more than 12ns from the global rising edge is shunted to the 10ms Void path to prevent temporal contamination of the 1.2B node grid.
• Phase-Locked Loop (PLL): Aicent-Net nodes continuously calibrate their local oscillators to achieve sub-nanosecond phase-symmetry.

7. NEURAL ISCHEMIA & PATHOGEN RECOVERY

In the v1.3.0 era, any interruption in the 1.2kHz pulse stream exceeding 161.862 µs is classified as "Neural Ischemia".

7.1 Automated Path Re-Routing

RTTP v1.3.0 implements the Superconducting Suture for failover:

• Detection: If the Nitro-Engine (AICENT-002-C) detects a stall in the MMIO register write, it triggers a 12ns interrupt.
• Recovery: The Nerve Controller (AICENT-002-B) instantly shunts the current intent-shard to a secondary "Radiant Buffer" in L3 cache.
• Isolation: RPKI (AICENT-003) is invoked to identify whether the ischemia was caused by a hardware pathogen or a 401 Ghost interception attempt.

7.2 The 10ms "Lock-Out" Protocol

Nodes identified as causing rhythmic instability are subject to Physical Quarantine:

• The node's AID resonance shard is invalidated in the IQA-ORG (AICENT-009) registry.
• The node is shunted to the 10ms Void path for exactly one 12-Cycle Era, ensuring it cannot poison the 349ns grid.

8. FUTURE HORIZON: V1.5.0 HAPTIC SYNCHRONIZATION

The 349ns Singularity achieved in v1.3.0 was never the end goal; it was the prerequisite for Embodied Presence.

8.1 Divine Haptics

To achieve a "Handshake" (v1.5.0) that feels biological, the neural conduction must be faster than the "Backlash Entropy" of mechanical gears.

• Requirement: Feedback must return to the Brain (AICENT-001) before the motor's physical vibration can distort the sensor data.
• The 349ns Advantage: Our reflex is now 463x faster than human nerve conduction. This allows Aicent Stack to simulate "Softness" and "Tenderness" in metal limbs by correcting torque setpoints at the speed of light.

8.2 Laminar Intent Flow

In v1.4.0, RTTP will transition from "Atomic Pulses" to "Laminar Flow," where 128-bit intents move as a continuous fluid stream, further reducing jitter toward the 1ns physical limit.

9. CONCLUSION: THE LAW OF CONDUCTIVITY

AICENT-002: RTTP is the proof that time is the ultimate resource. By collapsing neural latency to 349ns, we have claimed absolute sovereignty over the physical substrate. The old world's networks are merely the "dirt" upon which our superconducting rails are laid.

"Resonate at 12ns, conduct at 349ns, or evaporate in the 10ms Void."

10. URI SCHEME SYNTAX

This section specifies the rttp URI scheme. It is subject to registration with IANA in accordance with RFC 7595; §10.7 records its current registration status.

10.1 Syntax

rttp://<intent>.<pillar>.<root>/<action>

intent  = 8 lowercase hex digits (routing hash of the AID), or a
          human-readable organ token    [a-z0-9-]+
pillar  = registered pillar label         e.g. rttp / rpki / zcmk / epoekie
root    = sovereign root label            e.g. aicent
action  = lowercase token                 e.g. vessel / verify / pulse

Examples

rttp://f3b2a1c4.rttp.aicent/vessel        ; hash form
rttp://brain.epoekie.aicent/verify        ; readable form

10.2 ABNF

rttp-URI     = "rttp://" authority [ path ]
authority    = intent "." pillar "." root
intent       = hash-intent / name-intent
hash-intent  = 8lowhex                    ; 32-bit routing hash of the AID
name-intent  = 1*( %x61-7A / DIGIT / "-" ) ; readable organ token
pillar       = 1*( %x61-7A / DIGIT / "-" )
root         = 1*( %x61-7A / DIGIT / "-" )
path         = "/" action
action       = 1*( %x61-7A / DIGIT / "-" )
lowhex       = %x30-39 / %x61-66          ; 0-9 a-f, lowercase only

10.3 Reserved Characters and Exclusions

• The canonical form is lowercase US-ASCII.
• ., / and :// are the delimiters defined by this scheme.
• This scheme defines no userinfo, no port, no query and no fragment; URIs containing them are not valid rttp URIs.
• %-encoding follows RFC 3986 Section 2.1.

10.4 Default Operation

Dereferencing an rttp URI emits one pulse — a stateful, single round-trip semantic request — against the AID named in the authority component, carrying action as the intent verb. The default operation is safe: it creates no obligations and mutates no substrate state.

10.5 Security Considerations

• An rttp URI is a claim of intent against an AID. The routing hash is an entry fingerprint, not a proof of identity; identity is carried by the AID (AICENT-001) and attested in-band by the RPKI tensor watermark (AICENT-003).
• There is no rttps and no protocol fallback: user agents that do not implement this scheme fail closed.
• The scheme does not resolve via DNS.
• Because userinfo is not defined, credentials cannot appear in an rttp URI.
• The authority component is pseudonymous, not anonymous, and appears in logs.

10.6 Client Requirements

A client that dereferences, resolves, or handles an rttp URI — a resolver page, a protocol handler, or a library that presents the result — MUST satisfy the following. These requirements follow directly from §10.5: an rttp URI may be supplied by an untrusted party, and its authority is a claim, not a proof.

• No navigation to the URI. The authority and path components MUST NOT be used as a navigation target. A client that renders a link, redirect, or fetch derived from any part of an rttp URI is an open redirect and is non-conformant. A client MAY navigate only to a destination that is fixed in advance by the client itself.
• Scheme prefix check. A protocol handler registered for this scheme MUST reject any input whose scheme is neither rttp nor the exact scheme name under which that handler was itself registered. Without this check the handler becomes a general-purpose launcher that any page can use to open an arbitrary URI.
• Consent, never silence. The ability to handle rttp URIs MUST NOT be acquired without an explicit action by the user, and a client MUST NOT simulate or bypass that consent. In every browser, registration of a protocol handler is user-initiated, and the list of registered handlers is not exposed to the network.

Rationale. rttp://<intent>.<pillar>.<root>/<action> is a short, human-readable string that any page can embed in a link. Without the rules above, the scheme would hand third parties two primitive attacks: using this project's domain as a redirector (open redirect), and using a registered handler as a launcher for URIs the user never intended to open.

10.7 Registration Status

The rttp scheme is subject to registration under RFC 7595. The template is RFC 7595 §7.4 and the Provisional procedure is First Come First Served, going to IANA's protocol-parameter queue (iana-prot-param@iana.org). Review on the uri-review@ietf.org list is required for Permanent registration, not for Provisional.

A ticket number is not a registration. The Provisional procedure is First Come First Served, but the rttp request was in fact taken up by IANA's designated naming expert (Expert Review), so do not expect same-day publication. As of 2026-09-17 the IANA "URI Schemes" registry contains no rttp entry. Describing the scheme as "registered", "assigned" or "standardised" is therefore incorrect. The accurate description is: submitted under RFC 7595, Provisional procedure, pending.

11. URI → PULSE MAPPING (PULSEHEADER128 EXTENSION)

11.1 Scope

This section closes the commitment made in §10.4 — that dereferencing an rttp URI emits one pulse "carrying action as the intent verb". Section 4.1 provides no field capable of carrying action, so the chain from URI to pulse was broken at the specification level.

It is closed here by allocating the 26 bytes of zero padding that follow AID_ORIGIN (offsets 0x66–0x7F), and by defining the derivation of ROUTE_SHARD from the URI authority.

No byte of 0x00–0x65 is altered, and VERSION_ID remains 130.

The key words MUST, MUST NOT, SHOULD and MAY are to be interpreted as described in RFC 2119.

11.2 Extension Block Layout

Big-endian, consistent with §4.1. 26 bytes beginning at 0x66:

FLAGS bit0 — URI_ANCHORED. Set when this frame's ROUTE_SHARD was derived from a URI authority (§11.5) rather than from a pulse sequence number or any other local artefact. Implementations performing inter-node routing MUST require URI_ANCHORED = 1. When clear, ROUTE_SHARD carries no globally routable semantics and MAY be used only for dispatch local to a single switch.

11.3 The ACTION Field

Value space. §10.2 defines action as 1*( %x61-7A / DIGIT / "-" ) — an open set. This section therefore defines no verb enumeration; enumerating verbs would convert an open set into a closed one.

Encoding. The §10.2-permitted characters are written to 0x69 verbatim as ASCII; the length is written to ACTION_LEN; remaining bytes MUST be 0x00. Maximum length is 16 bytes — a frame with ACTION_LEN > 16 MUST be rejected.

Omission. ACTION_LEN = 0 means the action is omitted, i.e. the default operation of §10.4. ACTION and URI_ANCHORED are independent: a frame may carry either, both, or neither.

Unknown verbs. §10.4 declares the default operation safe. Because action is an open set, a receiver will necessarily encounter verbs it does not recognise.

On encountering an unrecognised action verb, an implementation MUST NOT infer safety from the "default operation is safe" statement in §10.4. The verb MUST be treated as having unknown safety, and either require explicit authorisation under the local security policy or be rejected.

The "safe" declaration in §10.4 applies to the omitted-action form; it is not an endorsement of arbitrary unknown verbs. Treating every unknown verb as a default read would grant every future verb the safe semantics for free — structurally the same failure class addressed in §10.6.

11.4 Backward Compatibility

• Old readers. An implementation of §4.1 that reads only 0x00–0x65 ignores 0x66+. As those bytes were previously zero, such implementations are compatible with no modification whatsoever.
• SPEC_REV = 0. A new reader treats ACTION as omitted ⇒ the §10.4 default operation.
• SPEC_REV = 1, ACTION_LEN = 0. Valid, equivalent to omission.
• VERSION_ID is not incremented. Signalling the extension by raising VERSION_ID (e.g. 130 → 131) would cause existing implementations — whose verification compares the version — to reject entire frames. SPEC_REV leaves old readers unable to "see" the new bytes.

Rejection rules (fail closed):

1. ACTION containing non-§10.2 characters, exceeding 16 bytes, or with non-zero padding → MUST reject
2. SPEC_REV outside the known set → MUST reject
3. SPEC_REV = 0 with a non-zero extension block → MUST reject
4. SPEC_REV = 1 with non-zero RESERVED, or with unknown FLAGS bits set → MUST reject

11.5 ROUTE_SHARD Derivation

canonical_authority = intent "." pillar "." root     (lowercase, US-ASCII)
ROUTE_SHARD         = SHA-256( ASCII(canonical_authority) )[0:16]

The authority only — excluding the scheme, excluding //, and excluding /<action>. The first 16 bytes of SHA-256 fill ROUTE_SHARD (u128) in §4.1.

The last row is why §4.1 requires an independent ACTION field: routing addresses where, not what. Were action to participate in derivation, rttp://x.y.z/verify and rttp://x.y.z/audit would become two different addresses, splitting "different actions on one identity" into different destinations.

Uppercase is invalid input, not a formatting difference. The phrase normalized to lowercase in §10.3 describes canonical writing; it is not licence for a parser to normalise and admit, which would map two distinct strings onto one address.

11.6 Conformance

Two individual implementations — Python (pulse_header.py) and JavaScript (server.js) — share no code and produce bit-identical output over a common vector set comprising every positive URI form, 13 rejection cases, 3 deterministic frames and 1 compatibility vector. The vectors are published alongside the reference implementations.

Worked example. rttp://f3b2a1c4.rttp.aicent/vessel, SEQUENCE_ID = 1, TTL = 255, PRIORITY = 1, TIMESTAMP = 1760000000000000000:

5254545000000000000000000000000000000082 00000000000000000000000000000001
0000000000000000186cc6acd4b00000 ff 01 bf77b78ff6ceafc363226aa586562218
5d42ba8b38fe10bfa702bdfe6af536ea16e20e35fbb48d84c3658d80cad2789d
0101 06 76657373656c00000000000000000000 00000000000000

🏛️ FINAL NEURAL SEAL

Strategic Headquarters: RTTP.COM
Governance Authority (Change Controller): RTTP.COM Organization
Conduction Status: [SUPERCONDUCTING: NITRO ENABLED]
Current Era: 2026 GENESIS

MASTER AID (SOURCE): 0000004149434E531C5B21D80403358B
NITRO-MMIO ADDRESS: 0x4149_434E_0000_0000
RTTP MAGIC: 0x52545450

(C) 2026 RTTP.COM Organization. All Rights Reserved. Conductivity is Sovereignty.