rttp is a URI scheme for intent addressing. An rttp URI names an intent; the address is derived, not looked up.
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 URI is an entry fingerprint; the AID is the identity.
{
"scheme": "rttp",
"specification": "RFC-002",
"scheme_status": "submitted to IANA, Provisional, pending",
"conformance": "35 published checks, three individual implementations",
"addressing": "derived from the authority — no lookup, no TTL, no DNS"
}
One click, nothing installed, no administrator rights — removable later in the browser's protocol-handler settings. The address is rttp://<intent>.<pillar>.<root>/<action>. Reaching it from a web page adds the browser's own reserved prefix, which is the same address, not a second protocol — same authority, same path, same derived ROUTE_SHARD, and the equivalence is covered by the published conformance vectors. The form without that prefix reaches the same place through a one-time OS registration instead. Verified on Windows Chrome. The resolver page needs no registration at all.
Unlike ordinary byte streams, RTTP prioritizes the transmission stability of model tensors and inference instructions.
A browser only opens a scheme it already knows about. One click teaches this browser to open RTTP links — nothing is installed, no administrator rights, and you can remove it afterwards in the browser's protocol-handler settings.
Scope: rttp://<intent>.<pillar>.<root>/<action>. Reaching it from a web page adds the browser's reserved prefix — same authority, same path, same derived ROUTE_SHARD, not a second protocol. The form without that prefix reaches the same place through a one-time operating-system registration instead. Verified on Windows Chrome. The resolver page itself needs no registration at all.
// rttp 1.2.8 - PyPI & npm - 1.2.8-alpha - crates.io
// Three individual implementations, one published vector set — same bytes.
$ pip install rttp && python -m rttp.selftest
[PASS] all 80 checks passed (3 skipped) # default install
$ pip install rttp[ed25519] && python -m rttp.selftest
[PASS] all 83 checks passed # with the optional Ed25519 backend
$ npx @aicent/rttp
[PASS] all 35 checks passed (node, individual)
$ cargo add rttp@1.2.8-alpha && cargo test
test conformance::tests::shipped_vectors_replay_green ... ok
[PASS] all 37 checks passed (1 skipped)
// Address form: rttp://<intent>.<pillar>.<root>/<action> (RFC-002 §10.2)
// Resolution is a computation over the authority: no DNS, no key directory.
An rttp URI is resolved by computation over the authority itself: no DNS, no key directory, no registry lookup on the resolution path.
| Traditional Problem | TCP/IP/QUIC behaviour | RTTP Solution | Design intent, not a measurement |
|---|---|---|---|
| Handshake + Congestion Control | 3-way handshake + slow start | Persistent semantic session + RPKI pre-handshake | Session established once, not per message |
| Jitter Retransmission | ACK + RTO (initial RTO 1s, RFC 6298) | Predictive pulse + FEC + Multipath | Designed so that retransmission is off the critical path |
| Byte Stream Blindness | No semantic awareness | Semantic multicast + Context snapshot fragmentation | Semantic-aware zero-copy delivery |
| KV Cache Staleness | Full resend or polling | Incremental fragment pulse only | Incremental fragments only, no full resend |
256-dimensional task primitive embedding for AI-native routing.
The multicast tree is computed locally from the published vectors.
128k context → ~512 microfragments, incremental updates only.
Multipath redundancy + FEC + predictive dead reckoning.
256-bit vector processing for parallel verification pipelines
Semantic routing with hardware acceleration
Dedicated silicon for zero-microsecond security operations
Nodes publish "semantic affinity vectors" (256-dimensional task primitive embeddings); the multicast tree is computed locally from those vectors.
By layer, head, token range (128k context → ~512 microfragments)
Send only tokens changed since last pulse
Issue "expected pulse" 2-5ms in advance
RTTP's three-layer protection ensures zero packet loss even under extreme network conditions.
// PulseHeader128 frame layout (RFC-002, Section 4) // 0x00 RTTP_MAGIC u32 0x52545450 - register gate // 0x04 VERSION_ID u128 locked version field // 0x14 SEQUENCE_ID u128 monotonic audit index // 0x24 TIMESTAMP u128 emission time // 0x34 TTL_PULSE u8 max 255 hops before evaporation // 0x35 PRIORITY u8 shunting weight // 0x36 ROUTE_SHARD u128 jitter-aligned routing shard hash // 0x46 AID_ORIGIN 256-bit dual-shard identity
Precise timing for latency measurement and synchronization
32-byte cryptographic fingerprint for instant identity verification
Supports io_uring + DPDK paths for kernel bypass
Eight Pillars stack distributed architecture powered by RTTP
Intent addressing
Trust verification
Metering and settlement
Edge execution
Collective compute network
Identity layer
An rttp URI is a claim of intent against an AID; the routing label is derived from the authority, so the same authority always yields the same ROUTE_SHARD.
Deep dive into design philosophy, technical features, and use cases. Before exploring session-level optimizations, understand the fundamental design differences.
Scope of this comparison: the table and the code samples below describe an application-layer session pattern and contrast it with the HTTP request-response model. They do not describe the rttp URI scheme, which defines addressing only and is not a transport — see draft-li-rttp-intent-addressing-01.
| Dimension | HTTP/HTTPS | RTTP (rttp URI scheme) |
|---|---|---|
| Communication Mode | Request-Response (Stateless) | Long Connection + Event-driven (Stateful) |
| Connection | Connections are reused (keep-alive, HTTP/2 multiplexing) | WebSocket persistent connection |
| Direction | Request-response; server-initiated messages via SSE, WebSocket or HTTP/2 | Bidirectional Real-time Communication |
| State Management | Stateless; session state is an application choice | Stateful (auto context) |
| Routing | HTTP defines no routing; that is DNS, anycast and load balancing | Semantic Routing (Dynamic) |
Why Choose RTTP Protocol?
The five points below describe platform and runtime behaviour. They are not properties of the rttp URI scheme, which defines addressing only — see draft-li-rttp-intent-addressing-01.
fetch('/api/process', {
method: 'POST',
body: JSON.stringify({ task: "write code" })
})
// Wait for response... one exchange at a time
socket.emit('RTTP_PUSH', {
payload: { content: "write code" }
})
// Real-time push on an already-open session
Frontend needs to know which API to call
{
"pulse_header": {
"pulse_version_128": "0x00000000000000000000000000000001",
"sender_node_aid": "AID_EPOEKIE_7a3f...",
"recipient_node_aid": "AID_GTIOT_9e2b...",
"sequence_id_128": "0x0000000000000000000000000000a1b2",
"dispatch_timestamp_ns": 1714992000000000000
},
"semantic_routing": {
"intent_hash_128": "0x8f4e2d1c9b7a6f5e3d2c1b0a9f8e7d6c",
"topic_shard": "inference/coding/python",
"priority_128": 255
},
"security_watermark": {
"entropy_signature_128": "0x9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d",
"signature_status": "verified",
"temporal_anchor_128": "0x00000000000000000000000000001234"
},
"payload": {
"type": "intent",
"content": "Write a Python function",
"payload_digest_128": "0x1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d"
},
"resonance_feedback": {
"resonance_score_128": "0x00000000000000000000000000009999",
"homeostasis_metric": "OPTIMAL",
"report_channel": "RFC-014"
}
}
Values below are properties of the scheme and of the published conformance checks — not measured latency claims.
Best use cases for different protocols