rttp 0.1.0__tar.gz

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,122 @@
1
+ # Changelog — `rttp` (Python)
2
+
3
+ All notable changes to the `rttp` package. Format follows
4
+ [Keep a Changelog](https://keepachangelog.com/); versioning is
5
+ [Semantic Versioning](https://semver.org/).
6
+
7
+ ---
8
+
9
+ ## [0.1.0] — 2026-09-17
10
+
11
+ First release. Scope is deliberately narrow: **framing, addressing and sealing**,
12
+ with zero dependencies and no transport.
13
+
14
+ ### Added
15
+
16
+ * **`rttp.pulse_header`** — `PulseHeader128` codec for the 128-byte
17
+ hardware-aligned frame header (RFC-002 §4.1), including the v1.2.6 extension
18
+ block:
19
+ * `SPEC_REV` `0x66` · `FLAGS` `0x67` · `ACTION_LEN` `0x68` · `ACTION` `0x69`(16B)
20
+ · `RESERVED` `0x79`(7B)
21
+ * bytes `0x00`–`0x65` are **not touched**, `VERSION_ID` stays 130 — readers
22
+ that only understand the original layout remain conformant
23
+ * `build()` · `build_for_uri()` · `parse()` · `verify()` · `to_hex()` /
24
+ `from_hex()`
25
+ * strict verification (R1–R7): unknown `SPEC_REV` rejected, `SPEC_REV=0` with a
26
+ non-zero block rejected, non-zero `RESERVED` rejected, unknown `FLAGS` bits
27
+ rejected, `ACTION` padding must be zero, `ACTION_LEN` must agree with the
28
+ payload
29
+ * **`rttp.rttp_uri`** — validation, canonicalisation and `ROUTE_SHARD`
30
+ derivation for `rttp://` URIs (RFC-002 §10.2 / §10.3):
31
+ * `ROUTE_SHARD = SHA-256(ASCII(canonical_authority))[0:16]` — deterministic,
32
+ pure computation, **no DNS** (§10.5)
33
+ * hash-intent (`8lowhex`) and name-intent forms; open-set `action` vocabulary
34
+ * fail-closed rejection of uppercase, `userinfo`, `port`, `query`,
35
+ `fragment`, multi-segment paths, wrong segment counts, leading/trailing `-`,
36
+ whitespace, and non-`rttp` schemes
37
+ * accepts both `rttp://` and `web+rttp://` — the second as a **tolerance** for
38
+ the browser protocol-handler form, which RFC-002 no longer defines
39
+ (2026-09-17). Not a conformance claim; see "Known gaps" below.
40
+ * **`rttp.seal`** — managed profile: HMAC-SHA256 over a pre-shared key table,
41
+ bidirectional switch↔agent signing, `ts|nonce` with a 120-second skew window.
42
+ * **`rttp.seal_asym`** — **sovereign profile**: Ed25519 seals with
43
+ `AID = SHA-256(public_key)`.
44
+ * self-certifying: the envelope carries the public key, so a verifier
45
+ recomputes the identity instead of trusting a claim — **no issuance, no
46
+ registry, no directory**
47
+ * `ts` and `nonce` are **inside** the signed input, so they cannot be rewritten
48
+ without breaking the signature
49
+ * freshness enforced by default (`|now - ts| <= 120 s`); archival verification
50
+ available explicitly via `check_freshness=False`
51
+ * lowercase-hex only — a case variant is rejected, not normalised
52
+ * `generate_keypair()` · `seal()` · `unseal()` · `verify_envelope()` ·
53
+ `verify_claims()` · `public_bundle()` · `signing_input()`
54
+ * requires the `ed25519` extra; without it every call raises `SealError` with
55
+ the install instruction rather than degrading to an unsigned path
56
+ * **`rttp.aid`** — Autonomous Identity derivation (RFC-001), shared by both
57
+ profiles so an AID means one thing across the stack.
58
+ * **`rttp.selftest`** — `python -m rttp.selftest`, **53 checks**:
59
+ * 25 conformance vectors (6 positive URIs · 15 rejections · 3 deterministic
60
+ frames · 1 `SPEC_REV=0` compatibility vector)
61
+ * RFC 8032 §7.1 TEST 1 / TEST 2, proving the signature backend is standard
62
+ Ed25519 — so a failure identifies *which* half broke
63
+ * 22 envelope checks, including a 14-case tamper matrix in which every single
64
+ alteration must be rejected, and an explicit replay-window test
65
+ * 4 static-scan checks proving the core modules import nothing outside the
66
+ standard library
67
+ * `--vectors` prints the deterministic envelope vector for the specification;
68
+ `--quiet` prints the summary line only
69
+ * **`rttp/vectors/rttp-conformance-v1.2.6.json`** — the published vectors, shipped
70
+ as package data so the self-test runs from an installed wheel, offline.
71
+ * Console entry point `rttp-selftest`.
72
+ * **`MANIFEST.in`** — the source distribution carries `README.md`,
73
+ `CHANGELOG.md`, `LICENSE`, `pyproject.toml` and the published vectors, and
74
+ excludes virtual environments and build noise. Both the wheel and the sdist
75
+ pass `twine check`.
76
+
77
+ ### Notes
78
+
79
+ * **Zero dependencies** in the core, and that is a machine-checked claim rather
80
+ than a promise — see the static-scan section of the self-test.
81
+ * The reference implementation evaluates the
82
+ **`iqa`** namespace nowhere: this package is the `rttp` protocol only.
83
+ * Distribution: PyPI `rttp`. The npm name `rttp` is held by an unrelated,
84
+ unmaintained project, so the JavaScript side will publish under the `@rttp`
85
+ scope.
86
+
87
+ ### Known gaps
88
+
89
+ Tracked in `SPEC/RTTP-SEAL-ENVELOPE-v1.2.6.md` §8 and §10. Deliberately listed
90
+ here so nobody has to discover them:
91
+
92
+ * No transport and no client. The core encodes, addresses and seals; sending is a
93
+ separate package's job.
94
+ * No revocation, and no key rotation story. Both belong to RFC-003.
95
+ * No replay **cache**: freshness (§3.4) bounds the window, but within it a replayed
96
+ envelope still verifies unless the verifier keeps a short-lived nonce store.
97
+ * No transport-origin binding: the seal proves who signed, not which connection
98
+ delivered it.
99
+ * Rust parity: the published `rttp` crate has no transport layer and no envelope.
100
+ Python and Node are the conforming implementations so far.
101
+ * ~~the browser-registration prefix is accepted because RFC-002 §10.6 requires
102
+ it…~~ — **superseded 2026-09-17.** That form was removed from both
103
+ specifications and will never be submitted to IANA. `rttp_uri` still accepts it
104
+ as a **tolerance** — a browser hands the handler that string, and refusing it
105
+ would break the protocol-handler path — but the specification defines no such
106
+ form, so the acceptance is **outside the specification** and a conforming
107
+ third-party implementation is not required to reproduce it.
108
+ * ~~**Open, and ours to fix:** the published vectors asserted things the
109
+ specification no longer said.~~ — **resolved 2026-09-18.** The generator now
110
+ classifies every forward case explicitly:
111
+ * `positive_uris` — each entry carries `tolerance` (boolean) and `note`. The
112
+ case whose `uri` carries the browser-registration prefix is `tolerance: true`,
113
+ with its reason recorded: it is accepted only because that is the scheme name
114
+ under which a handler is registered (RFC-002 §10.6) — never because the
115
+ specification defines it. It is **not** a conformance claim, and the 25-check
116
+ total is unchanged.
117
+ * `negative_uris` — the two case-clause citations were corrected from
118
+ `(RFC-002 §10.2)` to **`§10.3`**, the clause that actually carries the
119
+ lowercase rule. §10.2 now appears nowhere in the vector set.
120
+ Regenerated (`SPEC/tools/conformance.py --generate`), replayed (`--check`,
121
+ 25/25), and mirrored byte-identically into both packages. After the change:
122
+ Python self-test 53/53, Node runner 25/25.
rttp-0.1.0/LICENSE ADDED
@@ -0,0 +1,201 @@
1
+ Apache License
2
+ Version 2.0, January 2004
3
+ http://www.apache.org/licenses/
4
+
5
+ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
6
+
7
+ 1. Definitions.
8
+
9
+ "License" shall mean the terms and conditions for use, reproduction,
10
+ and distribution as defined by Sections 1 through 9 of this document.
11
+
12
+ "Licensor" shall mean the copyright owner or entity authorized by
13
+ the copyright owner that is granting the License.
14
+
15
+ "Legal Entity" shall mean the union of the acting entity and all
16
+ other entities that control, are controlled by, or are under common
17
+ control with that entity. For the purposes of this definition,
18
+ "control" means (i) the power, direct or indirect, to cause the
19
+ direction or management of such entity, whether by contract or
20
+ otherwise, or (ii) ownership of fifty percent (50%) or more of the
21
+ outstanding shares, or (iii) beneficial ownership of such entity.
22
+
23
+ "You" (or "Your") shall mean an individual or Legal Entity
24
+ exercising permissions granted by this License.
25
+
26
+ "Source" form shall mean the preferred form for making modifications,
27
+ including but not limited to software source code, documentation
28
+ source, and configuration files.
29
+
30
+ "Object" form shall mean any form resulting from mechanical
31
+ transformation or translation of a Source form, including but
32
+ not limited to compiled object code, generated documentation,
33
+ and conversions to other media types.
34
+
35
+ "Work" shall mean the work of authorship, whether in Source or
36
+ Object form, made available under the License, as indicated by a
37
+ copyright notice that is included in or attached to the work
38
+ (an example is provided in the Appendix below).
39
+
40
+ "Derivative Works" shall mean any work, whether in Source or Object
41
+ form, that is based on (or derived from) the Work and for which the
42
+ editorial revisions, annotations, elaborations, or other modifications
43
+ represent, as a whole, an original work of authorship. For the purposes
44
+ of this License, Derivative Works shall not include works that remain
45
+ separable from, or merely link (or bind by name) to the interfaces of,
46
+ the Work and Derivative Works thereof.
47
+
48
+ "Contribution" shall mean any work of authorship, including
49
+ the original version of the Work and any modifications or additions
50
+ to that Work or Derivative Works thereof, that is intentionally
51
+ submitted to Licensor for inclusion in the Work by the copyright owner
52
+ or by an individual or Legal Entity authorized to submit on behalf of
53
+ the copyright owner. For the purposes of this definition, "submitted"
54
+ means any form of electronic, verbal, or written communication sent
55
+ to the Licensor or its representatives, including but not limited to
56
+ communication on electronic mailing lists, source code control systems,
57
+ and issue tracking systems that are managed by, or on behalf of, the
58
+ Licensor for the purpose of discussing and improving the Work, but
59
+ excluding communication that is conspicuously marked or otherwise
60
+ designated in writing by the copyright owner as "Not a Contribution."
61
+
62
+ "Contributor" shall mean Licensor and any individual or Legal Entity
63
+ on behalf of whom a Contribution has been received by Licensor and
64
+ subsequently incorporated within the Work.
65
+
66
+ 2. Grant of Copyright License. Subject to the terms and conditions of
67
+ this License, each Contributor hereby grants to You a perpetual,
68
+ worldwide, non-exclusive, no-charge, royalty-free, irrevocable
69
+ copyright license to reproduce, prepare Derivative Works of,
70
+ publicly display, publicly perform, sublicense, and distribute the
71
+ Work and such Derivative Works in Source or Object form.
72
+
73
+ 3. Grant of Patent License. Subject to the terms and conditions of
74
+ this License, each Contributor hereby grants to You a perpetual,
75
+ worldwide, non-exclusive, no-charge, royalty-free, irrevocable
76
+ (except as stated in this section) patent license to make, have made,
77
+ use, offer to sell, sell, import, and otherwise transfer the Work,
78
+ where such license applies only to those patent claims licensable
79
+ by such Contributor that are necessarily infringed by their
80
+ Contribution(s) alone or by combination of their Contribution(s)
81
+ with the Work to which such Contribution(s) was submitted. If You
82
+ institute patent litigation against any entity (including a
83
+ cross-claim or counterclaim in a lawsuit) alleging that the Work
84
+ or a Contribution incorporated within the Work constitutes direct
85
+ or contributory patent infringement, then any patent licenses
86
+ granted to You under this License for that Work shall terminate
87
+ as of the date such litigation is filed.
88
+
89
+ 4. Redistribution. You may reproduce and distribute copies of the
90
+ Work or Derivative Works thereof in any medium, with or without
91
+ modifications, and in Source or Object form, provided that You
92
+ meet the following conditions:
93
+
94
+ (a) You must give any other recipients of the Work or
95
+ Derivative Works a copy of this License; and
96
+
97
+ (b) You must cause any modified files to carry prominent notices
98
+ stating that You changed the files; and
99
+
100
+ (c) You must retain, in the Source form of any Derivative Works
101
+ that You distribute, all copyright, patent, trademark, and
102
+ attribution notices from the Source form of the Work,
103
+ excluding those notices that do not pertain to any part of
104
+ the Derivative Works; and
105
+
106
+ (d) If the Work includes a "NOTICE" text file as part of its
107
+ distribution, then any Derivative Works that You distribute must
108
+ include a readable copy of the attribution notices contained
109
+ within such NOTICE file, excluding those notices that do not
110
+ pertain to any part of the Derivative Works, in at least one
111
+ of the following places: within a NOTICE text file distributed
112
+ as part of the Derivative Works; within the Source form or
113
+ documentation, if provided along with the Derivative Works; or,
114
+ within a display generated by the Derivative Works, if and
115
+ wherever such third-party notices normally appear. The contents
116
+ of the NOTICE file are for informational purposes only and
117
+ do not modify the License. You may add Your own attribution
118
+ notices within Derivative Works that You distribute, alongside
119
+ or as an addendum to the NOTICE text from the Work, provided
120
+ that such additional attribution notices cannot be construed
121
+ as modifying the License.
122
+
123
+ You may add Your own copyright statement to Your modifications and
124
+ may provide additional or different license terms and conditions
125
+ for use, reproduction, or distribution of Your modifications, or
126
+ for any such Derivative Works as a whole, provided Your use,
127
+ reproduction, and distribution of the Work otherwise complies with
128
+ the conditions stated in this License.
129
+
130
+ 5. Submission of Contributions. Unless You explicitly state otherwise,
131
+ any Contribution intentionally submitted for inclusion in the Work
132
+ by You to the Licensor shall be under the terms and conditions of
133
+ this License, without any additional terms or conditions.
134
+ Notwithstanding the above, nothing herein shall supersede or modify
135
+ the terms of any separate license agreement you may have executed
136
+ with Licensor regarding such Contributions.
137
+
138
+ 6. Trademarks. This License does not grant permission to use the trade
139
+ names, trademarks, service marks, or product names of the Licensor,
140
+ except as required for reasonable and customary use in describing the
141
+ origin of the Work and reproducing the content of the NOTICE file.
142
+
143
+ 7. Disclaimer of Warranty. Unless required by applicable law or
144
+ agreed to in writing, Licensor provides the Work (and each
145
+ Contributor provides its Contributions) on an "AS IS" BASIS,
146
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
147
+ implied, including, without limitation, any warranties or conditions
148
+ of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
149
+ PARTICULAR PURPOSE. You are solely responsible for determining the
150
+ appropriateness of using or redistributing the Work and assume any
151
+ risks associated with Your exercise of permissions under this License.
152
+
153
+ 8. Limitation of Liability. In no event and under no legal theory,
154
+ whether in tort (including negligence), contract, or otherwise,
155
+ unless required by applicable law (such as deliberate and grossly
156
+ negligent acts) or agreed to in writing, shall any Contributor be
157
+ liable to You for damages, including any direct, indirect, special,
158
+ incidental, or consequential damages of any character arising as a
159
+ result of this License or out of the use or inability to use the
160
+ Work (including but not limited to damages for loss of goodwill,
161
+ work stoppage, computer failure or malfunction, or any and all
162
+ other commercial damages or losses), even if such Contributor
163
+ has been advised of the possibility of such damages.
164
+
165
+ 9. Accepting Warranty or Additional Liability. While redistributing
166
+ the Work or Derivative Works thereof, You may choose to offer,
167
+ and charge a fee for, acceptance of support, warranty, indemnity,
168
+ or other liability obligations and/or rights consistent with this
169
+ License. However, in accepting such obligations, You may act only
170
+ on Your own behalf and on Your sole responsibility, not on behalf
171
+ of any other Contributor, and only if You agree to indemnify,
172
+ defend, and hold each Contributor harmless for any liability
173
+ incurred by, or claims asserted against, such Contributor by reason
174
+ of your accepting any such warranty or additional liability.
175
+
176
+ END OF TERMS AND CONDITIONS
177
+
178
+ APPENDIX: How to apply the Apache License to your work.
179
+
180
+ To apply the Apache License to your work, attach the following
181
+ boilerplate notice, with the fields enclosed by brackets "{}"
182
+ replaced with your own identifying information. (Don't include
183
+ the brackets!) The text should be enclosed in the appropriate
184
+ comment syntax for the file format. We also recommend that a
185
+ file or class name and description of purpose be included on the
186
+ same "printed page" as the copyright notice for easier
187
+ identification within third-party archives.
188
+
189
+ Copyright 2013-2019 Nikolay Kim and Andrew Svetlov
190
+
191
+ Licensed under the Apache License, Version 2.0 (the "License");
192
+ you may not use this file except in compliance with the License.
193
+ You may obtain a copy of the License at
194
+
195
+ http://www.apache.org/licenses/LICENSE-2.0
196
+
197
+ Unless required by applicable law or agreed to in writing, software
198
+ distributed under the License is distributed on an "AS IS" BASIS,
199
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
200
+ See the License for the specific language governing permissions and
201
+ limitations under the License.
rttp-0.1.0/MANIFEST.in ADDED
@@ -0,0 +1,20 @@
1
+ # The source distribution is the artifact that matches this project's claim:
2
+ # a protocol reference an air-gapped reviewer can read end to end. So it carries
3
+ # the documents, not just the code.
4
+ include README.md
5
+ include CHANGELOG.md
6
+ include LICENSE
7
+ include pyproject.toml
8
+
9
+ # The published conformance vectors are package data (see pyproject.toml), so the
10
+ # self-test works offline from an installed distribution.
11
+ include src/rttp/vectors/*.json
12
+
13
+ # Build and cache noise.
14
+ global-exclude *.py[cod]
15
+ global-exclude __pycache__/*
16
+ prune src/rttp.egg-info
17
+ prune .venv
18
+ prune .venv-clean
19
+ prune dist
20
+ prune build
rttp-0.1.0/PKG-INFO ADDED
@@ -0,0 +1,234 @@
1
+ Metadata-Version: 2.4
2
+ Name: rttp
3
+ Version: 0.1.0
4
+ Summary: RTTP reference implementation: PulseHeader128 framing, rttp:// addressing, and self-certifying Ed25519 seals (RFC-002 §4.1 / §10 / §11).
5
+ Author: RTTP Working Group
6
+ License-Expression: Apache-2.0
7
+ Project-URL: Homepage, https://rttp.com/
8
+ Project-URL: Specification, https://rttp.com/RFC-002/
9
+ Keywords: rttp,protocol,ai-agents,intent-addressing,uri-scheme,ed25519,conformance
10
+ Classifier: Development Status :: 3 - Alpha
11
+ Classifier: Intended Audience :: Developers
12
+ Classifier: Operating System :: OS Independent
13
+ Classifier: Programming Language :: Python :: 3
14
+ Classifier: Programming Language :: Python :: 3 :: Only
15
+ Classifier: Topic :: Internet
16
+ Classifier: Topic :: Software Development :: Libraries
17
+ Classifier: Typing :: Typed
18
+ Requires-Python: >=3.9
19
+ Description-Content-Type: text/markdown
20
+ License-File: LICENSE
21
+ Provides-Extra: ed25519
22
+ Requires-Dist: cryptography>=41; extra == "ed25519"
23
+ Provides-Extra: dev
24
+ Requires-Dist: build>=1.0; extra == "dev"
25
+ Requires-Dist: twine>=4.0; extra == "dev"
26
+ Dynamic: license-file
27
+
28
+ # rttp
29
+
30
+ **Reference implementation of RTTP (Resonant Time Transfer Protocol): the
31
+ 128-byte `PulseHeader128` frame, `rttp://` intent addressing, and self-certifying
32
+ Ed25519 seals.**
33
+
34
+ [RFC-002 §4.1](https://rttp.com/RFC-002/) · [§10](https://rttp.com/RFC-002/) · §11 · v1.2.6
35
+
36
+ ---
37
+
38
+ ## Verify it in one command — no trust required
39
+
40
+ ```console
41
+ $ pip install rttp
42
+ $ python -m rttp.selftest
43
+ rttp 0.1.0 self-test
44
+ python 3.14.2 on win32
45
+ ...
46
+ [PASS] all 53 checks passed
47
+ ```
48
+
49
+ That is the point of this package. A specification is worth exactly what an
50
+ independent implementation can reproduce from it — so instead of asking you to
51
+ believe a table of numbers, this ships the vectors and replays them locally:
52
+
53
+ * **25 conformance checks** — `rttp://` parsing, fail-closed rejections, and the
54
+ URI → `ROUTE_SHARD` → 128-byte frame chain, bit for bit.
55
+ * **2 RFC 8032 checks** — the Ed25519 backend is shown to be *standard* Ed25519,
56
+ not a lookalike, so a failure tells you which half broke.
57
+ * **22 envelope checks** — round-trip, self-certification, freshness, and a
58
+ 14-case tamper matrix where every alteration must be rejected.
59
+ * **4 zero-dependency checks** — a static scan proving the core imports nothing
60
+ outside the standard library.
61
+
62
+ Offline. No account. No network. `[PASS]` or it is not.
63
+
64
+ ---
65
+
66
+ ## Install
67
+
68
+ ```console
69
+ pip install rttp # core: zero dependencies, standard library only
70
+ pip install rttp[ed25519] # + sovereign-profile seals (Ed25519)
71
+ ```
72
+
73
+ Python 3.9+. No compiled extensions in the core.
74
+
75
+ The core deliberately has **no dependencies**. A protocol reference that cannot be
76
+ read without resolving a dependency tree is not much of a reference — and an
77
+ air-gapped reviewer should be able to check the frames.
78
+
79
+ ---
80
+
81
+ ## What is in the box
82
+
83
+ | Module | What it does | Authority |
84
+ |:---|:---|:---|
85
+ | `rttp.pulse_header` | `PulseHeader128` codec — build / parse / verify the 128-byte hardware-aligned header, including the v1.2.6 extension block at `0x66`–`0x7F` | RFC-002 §4.1 + `SPEC/RTTP-FRAME-EXT-v1.2.6.md` |
86
+ | `rttp.rttp_uri` | Validate, canonicalise and derive `ROUTE_SHARD` from an `rttp` URI | RFC-002 §10.2 / §10.3 ABNF |
87
+ | `rttp.seal` | **Managed profile** — symmetric HMAC-SHA256 over a pre-shared key table | — |
88
+ | `rttp.seal_asym` | **Sovereign profile** — Ed25519, self-certifying, no issuance and no registry | `SPEC/RTTP-SEAL-ENVELOPE-v1.2.6.md` (draft) |
89
+ | `rttp.aid` | Autonomous Identity derivation | RFC-001 |
90
+
91
+ Plus `rttp.vectors` — the published conformance vectors, shipped inside the wheel
92
+ so the self-test works from an installed package with no repository checkout.
93
+
94
+ ---
95
+
96
+ ## Quickstart
97
+
98
+ ### Address an intent
99
+
100
+ ```python
101
+ from rttp import rttp_uri
102
+
103
+ parsed = rttp_uri.parse("rttp://brain.epoekie.aicent/verify")
104
+ parsed["authority"] # 'brain.epoekie.aicent'
105
+ parsed["action"] # 'verify'
106
+ parsed["route_shard"].hex() # 16-byte routing hash, pure computation
107
+ ```
108
+
109
+ Addressing is **DNS-free** (RFC-002 §10.5): the routing hash is derived from the
110
+ authority by SHA-256, so no registry, resolver or network is involved. Malformed
111
+ input is rejected rather than normalised — a case variant is not a spelling
112
+ difference, it is a different string.
113
+
114
+ ### Build a frame from a URI
115
+
116
+ ```python
117
+ from rttp import pulse_header, rttp_uri
118
+
119
+ parsed = rttp_uri.parse("rttp://brain.epoekie.aicent/verify")
120
+ raw = pulse_header.build_for_uri(
121
+ sequence_id=1, ttl=255, priority=1,
122
+ uri=parsed["canonical_uri"],
123
+ aid_origin=bytes.fromhex("..."), # originator AID, 32 bytes
124
+ )
125
+ len(raw) # 128
126
+ pulse_header.verify(raw)["action"] # 'verify'
127
+ ```
128
+
129
+ `build_for_uri` performs the mapping RFC-002 §10.4 promises: the URI's authority
130
+ becomes `ROUTE_SHARD`, its path becomes `ACTION`. Readers that only understand
131
+ `0x00`–`0x65` keep working — the extension block occupies bytes that were already
132
+ zero, and `VERSION_ID` stays 130.
133
+
134
+ ### Seal with your own identity
135
+
136
+ ```python
137
+ from rttp import seal_asym
138
+
139
+ keypair = seal_asym.generate_keypair() # nothing is issued to you
140
+ print(keypair["aid_hex"]) # = SHA-256(public key): your identity
141
+
142
+ envelope = seal_asym.seal({"intent": "verify", "task_id": "t-1"}, keypair)
143
+
144
+ ok, reason, aid = seal_asym.verify_envelope(envelope)
145
+ # ok=True, signer identity recovered from the packet itself
146
+ ```
147
+
148
+ The verifier needs **only the envelope**. There is no key directory, no
149
+ credentials to obtain, and no operator who could refuse to issue them.
150
+
151
+ ---
152
+
153
+ ## Two profiles, and when each applies
154
+
155
+ | | **Managed** — `seal` | **Sovereign** — `seal_asym` |
156
+ |:---|:---|:---|
157
+ | Primitive | HMAC-SHA256 | Ed25519 |
158
+ | Key material | pre-shared table | self-generated |
159
+ | Identity | a role name | `AID = SHA-256(public key)` |
160
+ | Verifier needs | the same key table | only the envelope |
161
+ | A stranger can participate | no | **yes** |
162
+ | One leaked key | can forge any peer | forges one identity |
163
+
164
+ Inside a set of symmetric secrets there is no such thing as a stranger — whoever
165
+ holds the shared key can mint anybody's seal. The managed profile is therefore for
166
+ a closed organism, where a fixed set of roles genuinely do trust each other.
167
+
168
+ A protocol that invites third parties needs the sovereign profile. That is not a
169
+ preference; it is the difference between a private system and a public one.
170
+
171
+ ---
172
+
173
+ ## Scope — what this package is not
174
+
175
+ | | |
176
+ |:---|:---|
177
+ | ✅ **Framing** | Real, and specified. |
178
+ | ✅ **Addressing** | Real, and specified. |
179
+ | ✅ **Sealing** | Real, and specified (draft). |
180
+ | ❌ **Transport** | **Not here.** This package encodes, addresses and seals. It does not open sockets, and there is no `send()` — a client and its transport belong to a separate package, so that the codec stays dependency-free and auditable. |
181
+ | ❌ **Routing service** | Not here. `ROUTE_SHARD` is computed locally; delivering a frame to that hash is an operator's job, not the codec's. |
182
+ | ❌ **Confidentiality** | Signing is not encryption. |
183
+
184
+ **The seal is an envelope around the frame, not bytes inside it.** A reader that
185
+ parses only the 128-byte header sees no seal at all — which is why the two
186
+ concerns are specified separately.
187
+
188
+ Unknown revisions, algorithms and malformed input **fail closed** everywhere.
189
+ Nothing in this package is ever accepted because a check could not be performed.
190
+
191
+ ---
192
+
193
+ ## Conformance vectors
194
+
195
+ `rttp/vectors/rttp-conformance-v1.2.6.json` is generated, not hand-edited. Each
196
+ vector is deterministic: fixed sequence numbers, fixed timestamp, fixed AID — so
197
+ two implementations either agree byte for byte or they do not.
198
+
199
+ The vector set is the intended deliverable for third-party certification: pass it
200
+ and you interoperate; fail it and you know exactly which byte is wrong, without
201
+ needing to trust the authors.
202
+
203
+ ---
204
+
205
+ ## Naming
206
+
207
+ | Ecosystem | Name | Status |
208
+ |:---|:---|:---|
209
+ | crates.io | `rttp` | held by this project |
210
+ | PyPI | `rttp` | this package |
211
+ | npm | `@aicent/*` | the unscoped `rttp` name on npm is held by an unrelated, unmaintained 2017 REST helper, and the `rttp` scope cannot be claimed at all — a personal account already holds that name — so the JavaScript side is published under the organization this project controls |
212
+
213
+ ---
214
+
215
+ ## Specification status
216
+
217
+ * **`rttp` URI scheme** — submitted to IANA under RFC 7595, ticket **#1459939**,
218
+ Provisional (First Come, First Served), **under review**. It is **not yet
219
+ registered** — as of 2026-09-15 the IANA URI Schemes registry contains no
220
+ `rttp` entry. Please describe it that way.
221
+ * **Frame layout** — RFC-002 §4.1, extended by `SPEC/RTTP-FRAME-EXT-v1.2.6.md`.
222
+ * **Seal envelope** — `SPEC/RTTP-SEAL-ENVELOPE-v1.2.6.md`, a **draft**: the format
223
+ is implemented and vector-tested, but it is not yet a numbered RFC-002 section.
224
+ * **Managed profile** — implementation only; it predates the sovereign profile and
225
+ has no standalone specification.
226
+
227
+ Where this package and a specification disagree, **the specification wins and the
228
+ package is wrong.** Please report it.
229
+
230
+ ---
231
+
232
+ ## License
233
+
234
+ Apache-2.0. See `LICENSE`.