v1.2.8 · Interactive Reference

AI Agent-Native
Resonant Time Transfer Protocol

Intent addressing — deterministic resolution

Intent addressing: a URI names what the subject is to do, not which machine to reach. An rttp URI is a claim of intent against an identified subject; the address is computed from the authority itself — no lookup, no TTL, no registry, no DNS. The rttp scheme is registered with IANA (Provisional, 2026-09-22; CRI scheme number 27).

The name is a claim — Resonant Time

Synchronized in time: the temporal half of the name is the commitment — intent addressing under a real-time constraint — and it is kept by structure, not by benchmarks. Resolution is computation: one SHA-256, zero network calls, so the latency of addressing an intent is bounded and does not scale with the network. Intent addressing without the time constraint would be little more than an agent DNS; the two halves are one claim.

RTTP is an application-layer transport protocol designed to enable sub-millisecond mounting and intent addressing of unstructured tasks across distributed agents.

Router Console

> [SYS] RTTP Node initialized at RTTP.COM

> [SYS] Semantic Routing Table: Loaded (3 Agents)

> [INFO] Release: 1.2.8 - Spec: AICENT-002 v1.2.6

> [INFO] Max Concurrent Tasks: 128

// Waiting for task injection...

Semantic Hub
Coding_Agent
Langs: [Python, JS, Rust]
Design_Agent
Tools: [SVG, UI, UX, Figma]
Logic_Agent
Logic: [Audit, Math, Reasoning]

Scope of this demo — what is real, what is a placeholder

  • ✓ Protocol layer — real. PulseHeader128 framing (AICENT-002 §4.1), rttp:// addressing (§10), the URI → ROUTE_SHARD mapping (§11), Radiant Seal verification and semantic routing are all implemented, running, and covered by published conformance vectors.
  • ⚠ Agent kernel — a placeholder in this public demo. The three agents run the simulated adapter: deterministic canned responses, not a model call. A real kernel plugs in through llm_adapter (openai / kernel) without touching the protocol layer.

What this demo proves is the transport, not the model behind it.

This page - the rttp:// URI reference - release 1.3.1

35 published vectors (6 positive, 15 negative, 3 frames, 9 negative frames, 1 positive frame, 1 envelope) — unchanged — replayed by three individual implementations. Asserted counts unchanged: 80 default, 83 with the optional Ed25519 backend, 35 on npm, 37/38 on crates.io — every count reproduced by CI on every push. Packages: 1.3.1 on PyPI, npm and crates.io — the first formal (non-pre-release) crates.io publication — plus the GitHub organizations. No protocol change against 1.2.6: same bytes, same frames; the wave moved all four registries as one line (and synced the sibling iqa packages to 1.3.1 the same day).

RTTP v1.2.8 — Published Packages

Pulse Frame
128 B
PulseHeader128 · AICENT-002 §4.1
Python · default
80 (3 skipped)
zero dependencies
Python · [ed25519]
83
with the optional backend
Node · npm
35
individual implementation
Rust · default
37 (1 skipped)
SHA-256 written in-crate
Rust · [ed25519]
38
cargo test --features ed25519
Published Vectors
35
6 pos + 15 neg + 3 frames + 9 + 1 + envelope
Core Dependencies
0
standard library only
verify it in one command — no trust required crates.io · rttp 1.2.8-alpha · pypi · rttp 1.2.8 · npm · @aicent/rttp 1.2.8 
# Python — the reference implementation (zero dependencies)

$ pip install rttp

$ python -m rttp.selftest

[PASS] all 80 checks passed (3 skipped)   # offline — no account, no network

# Python - with the optional Ed25519 backend

$ pip install rttp[ed25519]

$ python -m rttp.selftest

[PASS] all 83 checks passed

# JavaScript — an individual implementation of the same vectors

$ npm install @aicent/rttp

$ npx @aicent/rttp

[PASS] all 35 checks passed   # shares no code with Python — agrees byte for byte

# Rust — the third implementation: zero deps, SHA-256 written in-crate

$ cargo add rttp@1.2.8-alpha

$ cargo test

test conformance::tests::shipped_vectors_replay_green ... ok   # all 37 checks (1 skipped)

# Address an intent — DNS-free, pure computation (AICENT-002 §10.5)

import { parse } from '@aicent/rttp';

const r = parse('rttp://brain.epoekie.aicent/verify');

r.authority        // 'brain.epoekie.aicent'

r.action           // 'verify'

r.route_shard_hex  // '459e543b73d86005b72ba77d5756e83c'  <- pinned by the published vectors

RTTP Protocol Summary

128-Byte Framing

PulseHeader128 is a fixed, hardware-aligned frame (AICENT-002 §4.1). The extension block introduced by spec v1.2.6 occupies 0x66–0x7F — bytes that were already zero — so older readers keep working, and VERSION_ID stays 130. Releases 1.2.7 / 1.2.8 change packages, not this frame layout.

DNS-Free Addressing

An rttp:// URI derives its 16-byte ROUTE_SHARD locally by SHA-256 — no registry, no resolver, no network (AICENT-002 §10.5). Malformed input is rejected, never normalised: fail-closed everywhere.

Self-Certifying Seals

The self-certifying profile signs with Ed25519 and your identity is AID = SHA-256(public key) — a verifier needs only the envelope: no key directory, no issuer. The managed HMAC-SHA256 profile serves closed deployments.

Switch Verbs — the open action space (AICENT-002 §10.2)

Only PUSH is wired into the live reference above; SYNC / OBSERVE / HANDOVER belong to the Aicent Stack narrative layer (v1.3.0) and remain valid actions of the open set.

PUSH · live
Push subtasks to Agent
SYNC · narrative
Sync world model differences
OBSERVE · narrative
Monitor inference stream co-creation
HANDOVER · narrative
Transfer task control

Specification status: the rttp URI scheme is registered with IANA under RFC 7595 (ticket #1459939) as Provisional on 2026-09-22, with CRI scheme number 27. Frame layout: AICENT-002 §4.1 + SPEC/RTTP-FRAME-EXT-v1.2.6. Read AICENT-002 →

Install & Verify

$ npm install @aicent/rttp # JS · Node 18+ · zero deps

$ pip install rttp # Python 3.9+ · zero deps

$ cargo add rttp@1.2.8-alpha # Rust · zero deps · SHA-256 in-crate

$ npx @aicent/rttp # [PASS] all 35 checks

$ python -m rttp.selftest # [PASS] all 80 checks (83 with the ed25519 extra)

$ cargo test # shipped_vectors_replay_green · 37 checks (1 skipped)

Three individual implementations — crates.io rttp 1.2.8-alpha, PyPI rttp 1.2.8 and npm @aicent/rttp 1.2.8 — share no code and agree byte for byte on the same published conformance vectors. Apache-2.0. Versioning: one stack version, two channels — 1.2.8 on PyPI and npm, the pre-release 1.2.8-alpha on crates.io — same bytes, same vectors.

Want to contribute to the protocol standard?

Contact RTTP.COM Organization
QA Six Questions, Answered

Anticipated Objections

Q1 · What is RTTP? · click to expand

RTTP denotes Resonant Time Transfer Protocol — the addressing pillar. An rttp URI names an intent against an authority (intent.pillar.root); the address is derived by computation — one SHA-256, no DNS, no registry, no fetch. The name is a claim: intent addressing under a real-time constraint — synchronized in time, with resolution latency bounded and independent of network scale.

Q2 · What is IQA? · click to expand

IQA denotes Identity Quality Assurance — the attestation pillar. An iqa URI asks a named Organ for a verdict about a subject's standing: one of Ghost, Probation, Radiant, Genesis — a closed set. A verdict is an answer, not a computation: seals are HMAC-SHA256 over the canonical claim, bound to the subject's key material, verifiable offline — no issuer, no key directory, no network call. "I QA" — I, the answerer.

Q3 · Why not just use regular https URLs? · click to expand

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, with no DNS, no registry query and no fetch. The intent is part of the identifier itself, and anyone can verify the derivation offline.

Q4 · Why two schemes instead of one? · click to expand

Because they answer different kinds of questions. rttp resolves where — and when — by pure computation, needing no one's word. iqa states whether — a named Organ's verdict about a subject. Two namespaces keep the question channel and the attestation channel apart: the computation never depends on anyone's word, and the attestation never pretends to be computation.

Q5 · Is this a performance claim — faster than PTP? · click to expand

No. The temporal half of the name is a structural commitment, not a benchmark: resolution is computation, so addressing latency does not scale with the network. Clock synchronization is PTP's discipline and remains its own; RTTP borrows the discipline of time transfer for intent — two parties compute the same address into agreement without a shared lookup.

Q6 · How do I verify any of this? · click to expand

Replay the conformance vectors at iqa.org/challenge/ (35 vectors, any language, byte for byte), or install the packages from the URI Center.

Don't take our word for any of it — replay the vectors at iqa.org/challenge/ or run the demos at iqa.org/demo/.