Fix YAML frontmatter delimiter (|--- → ---) in stage 2 and 3
This commit is contained in:
Hermes
@@ -16,7 +16,7 @@ divides into three categories:
|
||||
|
||||
None of the nine compete with Passepartout on all axes simultaneously. Passepartout's
|
||||
strongest differentiators — Org-mode data model, deterministic gate stack, ACL2
|
||||
verification, Merkle-treed memory, and the Passepartout architecture — are absent from
|
||||
verification, Merkle-treed memory, and the [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Passepartout architecture]] — are absent from
|
||||
every competitor.
|
||||
|
||||
* Category 1: Coding Agents
|
||||
|
||||
@@ -14,4 +14,4 @@ A hospital that runs [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] w
|
||||
|
||||
Switching to a competitor means discarding all of it. The accumulated value grows as the fact store deepens. Annual revenue per enterprise grows from $250K in year one to $500K-$1M by year five as more [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][domain packages]] are added.
|
||||
|
||||
This is the strongest residual [[id:aa6d062e-a520-5d14-8773-00687ed9c689][moat]]. The [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][evaluation harness (see the [[id:3b43a9b8-31d1-4479-a35f-22273b74f0c7][Social protocol infrastructure requirements]] for the network topology that creates this lock-in)]] (regression suite) is a close second — it grows with every deployment and cannot be ingested from public data. The [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] and [[id:29e4dbf3-cf19-589c-8b14-389e8a39d564][upgrade lifecycle]] compound this lock-in: every new regulation encoded as a gate rule deepens the proof forest, making the deployment harder to reproduce elsewhere.
|
||||
This is the strongest residual [[id:aa6d062e-a520-5d14-8773-00687ed9c689][moat]]. The [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][[[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][evaluation harness]] (see the [[id:3b43a9b8-31d1-4479-a35f-22273b74f0c7][Social protocol infrastructure requirements]] for the network topology that creates this lock-in)]] (regression suite) is a close second — it grows with every deployment and cannot be ingested from public data. The [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] and [[id:29e4dbf3-cf19-589c-8b14-389e8a39d564][upgrade lifecycle]] compound this lock-in: every new regulation encoded as a gate rule deepens the proof forest, making the deployment harder to reproduce elsewhere.
|
||||
|
||||
@@ -87,7 +87,7 @@ The PDS is the central component for data ownership, acting as the user's sovere
|
||||
- *Exclusive Control:* Every user controls their own PDS, whether self-hosted or through a trusted provider.
|
||||
- *Master Archive:* Stores all user content (client-side encrypted) and identity data.
|
||||
- *Access Gatekeeper:* Enforces access control, issuing decryption keys based on validated credentials or payments.
|
||||
- *PDS-as-a-Service:* Services can integrate seamlessly, offering free sign-ups with grace periods and requiring in-protocol payments (e.g., Lightning) for continued service, bypassing traditional financial intermediaries.
|
||||
- *[[id:1a2b38df-20ba-58ca-ba55-a072be67bd0d][PDS-as-a-Service]]:* Services can integrate seamlessly, offering free sign-ups with grace periods and requiring in-protocol payments (e.g., Lightning) for continued service, bypassing traditional financial intermediaries.
|
||||
|
||||
*** 3.3.2. Relay Network: The Intelligent Communication Backbone
|
||||
|
||||
|
||||
@@ -196,7 +196,7 @@ Clients must efficiently discover active personas derived from a Master Seed wit
|
||||
1. Derive Master Key.
|
||||
2. For each account index (starting from 0'):
|
||||
a. Scan persona indices 0 through L-1.
|
||||
b. If any active persona is found, continue scanning the next window of L.
|
||||
b. If any active persona is found, [[id:22d0a159-68a2-4587-9375-5046beddc20c][continue]] scanning the next window of L.
|
||||
c. If no active personas are found in the window, stop scanning this account.
|
||||
3. If no active personas are found in the first window (0 through L-1) of an account, stop scanning accounts.
|
||||
|
||||
|
||||
@@ -109,7 +109,7 @@ Migration scenarios include a comprehensive range of use cases:
|
||||
***** Phase 2: Incremental Catch-up
|
||||
|
||||
- *Delta Sync:* Catch up changes made since Phase 1 started.
|
||||
- *Repeat:* Continue incremental syncs until delta is small (e.g., < 1 minute of data).
|
||||
- *Repeat:* [[id:22d0a159-68a2-4587-9375-5046beddc20c][Continue]] incremental syncs until delta is small (e.g., < 1 minute of data).
|
||||
- *Read Testing:* Client optionally reads from new PDS to verify accessibility.
|
||||
|
||||
***** Phase 3: Cutover
|
||||
|
||||
@@ -438,7 +438,7 @@ interface ResumeRequest {
|
||||
}
|
||||
|
||||
interface ResumeResponse {
|
||||
// Continue from where left off
|
||||
// [[id:22d0a159-68a2-4587-9375-5046beddc20c][Continue]] from where left off
|
||||
remaining_cids: CID[];
|
||||
next_chunk_index: number;
|
||||
}
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
|---
|
||||
---
|
||||
title: Stage 2 — Verification Subsystem
|
||||
type: reference
|
||||
tags: :passepartout:roadmap:
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
|---
|
||||
---
|
||||
title: Stage 3 — Lisp Machine
|
||||
type: reference
|
||||
tags: :passepartout:roadmap:
|
||||
|
||||
Reference in New Issue
Block a user