| … | … | @@ -267,7 +267,24 @@ signed MST commits to and what any atproto reader sees. `record-vocabulary.md` |
| 267 | 267 | (delete cascades in the same batch, edit re-derives, the projection is never a source of truth, |
| 268 | 268 | `sign()` materialises both before signing) are **sync** requirements, not tidiness. |
| 269 | 269 | |
| 270 | | ### 10.3 The strip is consensus-critical — version it, and guard it in band |
| 270 | ### 10.3 ~~The strip is consensus-critical~~ — RESOLVED 2026-09-05: it leaves the signing path |
| 271 | |
| 272 | ⛔ **Superseded by `record-vocabulary.md` §7.2.** The atproto projection is now a **stored record**, |
| 273 | derived once at authoring on the author's device. A signer materialises it from a file and **strips |
| 274 | nothing**, so the strip is no longer inside the signing path and is no longer consensus-critical. |
| 275 | |
| 276 | `STRIP_VERSION` survives only as **provenance** — a stamp recording which strip produced a stored |
| 277 | projection, useful for diagnosis. It is **not** an in-band guard, and an under-versioned peer does not |
| 278 | refuse the signer role, because there is nothing left for it to get wrong. |
| 279 | |
| 280 | `markdown-strip.md` §1's cross-*implementation* determinism argument still stands on its own terms: a |
| 281 | second implementation must reproduce the vectors to be conformant. That is a **conformance** |
| 282 | requirement, not a consensus one. |
| 283 | |
| 284 | The superseded reasoning follows, because it is why the mechanism was designed and why removing it is |
| 285 | safe rather than merely convenient: |
| 286 | |
| 287 | #### 10.3.1 (superseded) The strip was consensus-critical |
| 271 | 288 | |
| 272 | 289 | `signer.js:1-5`: *"because ECDSA here is RFC6979-deterministic, any lease-holder that signs the |
| 273 | 290 | same linearized view + rev/prev produces byte-identical output."* That byte-identity is what makes |
| … | … | @@ -287,10 +304,11 @@ OrgEventLog, and the autobee migration guard. It converts a silent fork into a l |
| 287 | 304 | |
| 288 | 305 | ### 10.4 Two open questions become consensus hazards |
| 289 | 306 | |
| 290 | | - **Grapheme segmentation is unpinned** (`markdown-strip.md` §9 item 1) and the 300-grapheme |
| 291 | | truncation (§4.3) happens inside the record that gets **signed**. Two runtimes on different |
| 292 | | Unicode versions truncate at different byte counts and produce different CIDs. Pin the |
| 293 | | segmentation algorithm and its Unicode version; treat a bump as a `STRIP_VERSION` bump. |
| 307 | - ~~**Grapheme segmentation is unpinned**~~ **DOWNGRADED 2026-09-05** — it was a consensus hazard |
| 308 | only while every sign re-derived the projection. With the projection **stored** at authoring |
| 309 | (`record-vocabulary.md` §7.2) no other peer ever re-derives it, so a runtime with different Unicode |
| 310 | tables cannot produce a competing CID. What remains is a **quality** concern: a user editing from a |
| 311 | second device may truncate differently. Pinning is still worth doing; it is no longer load-bearing. |
| 294 | 312 | - **Round-trip byte-identity is not free** the way DAG-CBOR's is. `migrateInline` leans on |
| 295 | 313 | *"DAG-CBOR is canonical so the rewrite is byte-identical"* and **asserts** it, skipping any key |
| 296 | 314 | whose re-encoded oid differs rather than republishing changed content. Markdown's equivalent — |
| … | … | @@ -309,12 +327,17 @@ OrgEventLog, and the autobee migration guard. It converts a silent fork into a l |
| 309 | 327 | 3. **Community and list URIs** for `visibility` (§11 #4). |
| 310 | 328 | 4. **Reply visibility inheritance** (§11 #5) — almost certainly inherit, but the failure mode is |
| 311 | 329 | publishing to the wrong people, so it must be explicit rather than emergent. |
| 312 | | 5. ⚠ **Where `STRIP_VERSION` is stamped — RESOLVED 2026-09-05, but it is only HALF the answer.** |
| 313 | | hyper-social #43 (2026-08-11) decided **per-record `dialect` versioning** and it was never |
| 314 | | written. The two are not alternatives: |
| 330 | 5. ~~**Where `STRIP_VERSION` is stamped**~~ **CLOSED 2026-09-05 — the question dissolved.** |
| 331 | It was resolved twice in one day and both answers are superseded: first "the room's StateBase", |
| 332 | then "that is only half — hyper-social #43 also decided per-record `dialect`". **Neither is |
| 333 | needed.** Both existed to make *repeated derivation* agree, and the projection is now derived |
| 334 | **once, at authoring, and stored** (`record-vocabulary.md` §7.2). `STRIP_VERSION` remains as |
| 335 | provenance on a stored projection; there is no in-band guard and no per-record dialect. |
| 336 | |
| 337 | ★ The lesson worth keeping: **two mechanisms for making a recomputation deterministic were |
| 338 | cheaper to delete than to specify — by not recomputing.** |
| 315 | 339 | |
| 316 | | | | guards against | scope | |
| 317 | | |---|---|---| |
| 340 | ---|---|---| |
| 318 | 341 | | `STRIP_VERSION` | two peers on different strips signing one room ⇒ **fork** | concurrency, per room | |
| 319 | 342 | | per-record `dialect` | a record authored under v1 being re-stripped under v2 | **history**, per record | |
| 320 | 343 | |