amr/hermes-brain
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Compare commits

base: amr:44299599f9732a6eda1c1da1fc75df853b9320e5
Branches Tags
amr:master
..
compare: amr:master
Branches Tags
amr:master

50 Commits
44299599f9 ... master

Author SHA1 Message Date
Hermes
386e6d40be rewrite ideas/_index.org with full page listing 2026-05-25 01:22:38 +00:00
Hermes
f8240967f5 update org-ids after build 2026-05-25 01:14:50 +00:00
Hermes
f10bd14091 add note: 10 wider implications of the three-pronged system 2026-05-25 00:56:05 +00:00
Hermes
a4113c2d5c add note: neural network models in the empirical middle 2026-05-25 00:48:30 +00:00
Hermes
0b77ea0ac9 add note: architectural integration of three-pronged system 2026-05-25 00:38:48 +00:00
Hermes
73fc33f02f add note: 10 practical powers of the three-pronged architecture 2026-05-25 00:26:49 +00:00
Hermes
f09a59aaf3 add plain-language explanation of world model implications 2026-05-25 00:17:49 +00:00
Hermes
6b6838fb2c add note: middle domain as world models — the Passepartout triple 2026-05-25 00:12:41 +00:00
Hermes
f3e2d15d47 add note: knowledge tree middle — logic to nanotechnology bridge 2026-05-24 23:59:30 +00:00
Hermes
cf3bd2ee54 add note: Passepartout bootstrapping Mathematica/mathlib autonomously 2026-05-24 23:55:38 +00:00
Hermes
d2387f1074 add note: viability of open-source Wolfram/Mathematica in Common Lisp 2026-05-24 22:54:02 +00:00
Hermes
64d027a0a0 add note: Schafmeister and Clasp — Lisp in computational nanotechnology 2026-05-24 21:05:07 +00:00
Hermes
5086ac4fbe project index: what+why only, no jargon without links; architecture: explain Lisp and ACL2 at first mention 2026-05-24 19:57:55 +00:00
Hermes
73dea1f654 rewrite project _index.org broader intro (Environment, Knowledge, Verification); add Knowledge subsystem to architecture page 2026-05-24 19:51:03 +00:00
Hermes
d3300adbf7 drop Passepartout prefix from section index titles: Architecture, Social Protocol, Strategy 2026-05-24 19:43:39 +00:00
Hermes
34ab923308 rewrite project _index.org as full narrative intro; rewrite architecture.org to lead with concepts before Lisp 2026-05-24 19:40:51 +00:00
Hermes
335735b655 Rewrite Passepartout architecture page as narrative introduction 
- architecture.org becomes a narrative: problem → three-subsystem solution
  → staged approach → what it means
- Moved TAM, revenue paths, analytical frames, strategy/IP links to _index.org
- _index.org is now the navigation hub with roadmap table and all catalog links
 2026-05-24 19:31:13 +00:00
Hermes
4c38127b45 Consolidate: 10 files merged into 5, 3 moves, 1 rename 
Merged:
- verification-monopoly + evaluation-harness + collective-regression-suite
- licensing + patent-strategy → strategy/
- moats + infrastructure-lock-in
- lisp-economics + cost-structure
- domain-gate-packages + gate-rule-encoding
- revenue-table + first-mover-window → revenue.org

Moved: sufficiency-flip, upgrade-lifecycle → strategy/
  native-org-knowledge-base → architecture/
Renamed: revenue-hub.org → revenue.org
Deleted: passepartout-economics.md orphan
 2026-05-24 19:17:01 +00:00
Hermes
ede891f2ce Merge verification-monopoly, evaluation-harness, collective-regression-suite into one page 
Combined all three under verification-monopoly.org with title:
'The Evaluation Harness — Collective Regression Suite as Certification Monopoly'
Structure: (1) vision from monopoly, (2) service from harness, (3) spec from collective-regression.
All three IDs preserved in PROPERTIES.
Deleted evaluation-harness.org and collective-regression-suite.org.
 2026-05-24 19:12:49 +00:00
Hermes
348f2736a8 Fix homepage headings: Org bold → proper headlines, H2 level 2026-05-24 18:57:59 +00:00
Hermes
0a8e77e949 Reorganize brain: projects/ top level, rename filenames, update homepage 
- Moved everything from ideas/passepartout/ to projects/passepartout/
- Moved legal structures to projects/flags/
- Created missing _index.org files for all subdirectories
- Stripped redundant passepartout- prefix from filenames
- Rewrote root _index.org as generalized brain index (projects + concepts)
- Updated Hugo nav to Projects/Concepts
- Updated build script section descriptions
- Deleted stale ideas/passepartout-economics.md orphan
 2026-05-24 18:54:14 +00:00
Hermes
4b60244919 Fix YAML frontmatter delimiter (|--- → ---) in stage 2 and 3 2026-05-24 18:07:14 +00:00
Hermes
2578bfee61 Architecture reframe: rename triad/Stoa/Logos/Agora → Passepartout 
- Renamed ideas/stoa/ → ideas/passepartout/, all stage files prefixed passepartout-
- Renamed triad-index/overview/systemic-effects → passepartout-* under passepartout/
- Renamed ideas/agora/ → ideas/passepartout-social-protocol/, stripped agora- prefixes
- Merged overview and environment pages into architecture; deleted 3 redundant files
- Renamed growth-strategy → enterprise-growth-strategy
- Renamed alternative-growth-social-first → social-growth-strategy
- Removed all Greek names: Stoa, Logos, Agora as product names
- Updated 50+ files of cross-references to new naming
- Kept org-id UUIDs intact throughout
 2026-05-24 18:02:36 +00:00
Hermes
cc3976fb7f ideas: editorial sweep — atomization, interlinking, restructuring 
- Split competitive-analysis-2026-05.org → TOC + 9 competitor files in
  ideas/competitors/. Dropped date from filename. All competitor UUIDs
  generated, TOC keeps original UUID for backlink continuity.
- Deleted passepartout-economics.org archive (replaced by 27-node KB).
- Inlined 5 'See also' blocks into natural prose (compliance-index,
  first-mover-window, revenue-table, orders-of-magnitude-time,
  native-org-knowledge-base).
- Linked 7 orphan compliance pages back to compliance index + finished
  truncated sentences.
- Linked all 14 Agora requirement docs from topic-relevant pages
  (identity→lisp-machine-security, infrastructure→compute-marketplace,
  social-space→growth-strategy, exchange→agora-contracts, etc.).
- Linked ai-industry-impact from investment-thesis, sufficiency-flip,
  verification-appliance, effects-growth-flywheel (up from 1 to 10+ pages).
- Fixed CREATED timestamps to use git commit dates instead of today.
- Made all links absolute from root (no port inheritance).
- Removed stale agora/docs/ duplicate content.
 2026-05-24 16:25:55 +00:00
Hermes
94f1871177 gbrain: sync converted org-mode brain files 2026-05-24 03:00:35 +00:00
Hermes
b3d91f2e55 fix: remove parenthetical (see ...) link pattern, use inline natural language links 2026-05-24 01:23:55 +00:00
Hermes
8f875dc192 fix: inline org-mode interlinks instead of parenthetical bare [[file:...]] links 2026-05-23 20:24:19 +00:00
Hermes
674b8b35ba feat: legal structure alternatives — Texas vs Delaware, Wyoming DAO LLC, Panama LLC, trust jurisdictions with downsides analysis 2026-05-23 15:10:53 +00:00
Hermes
6f67316681 feat: legal structure practical setup — Delaware C-Corp + BVI IP Co with forms, costs, timelines, and what must be done by a lawyer 2026-05-23 14:32:36 +00:00
Hermes
4a322ef5cd feat: asset protection structures research — Delaware C-Corp, BVI IP Co, series LLC, trust, with phased recommendations 2026-05-23 14:23:16 +00:00
Hermes
4d177832a1 feat: outbound sales compliance framework — CAN-SPAM, GDPR, UK GDPR, Egypt PDPL, CASL with Passepartout gate mappings 2026-05-23 14:19:22 +00:00
Hermes
59e9ced3e5 rewrite: combined growth strategy — Logos (top-down verification) + Agora (bottom-up communities) as two engines, one infrastructure 2026-05-23 14:01:43 +00:00
Hermes
89a9ee0c2c feat: Agora entry strategy — organized communities as primary entry point with 4-phase rollout 2026-05-23 13:57:27 +00:00
Hermes
f4c72d3527 rewrite: Agora competitive landscape — replaces 20+ centralized platforms across social, publishing, video, messaging, e-commerce, identity, and work 2026-05-23 13:16:39 +00:00
Hermes
ca9557a5f9 feat: Agora competitive landscape — 4-layer analysis (publishing, payments, contracts, identity) 2026-05-23 13:09:43 +00:00
Hermes
9f52f99092 update: correct Agora characterization as 4-layer unified platform (pub+pay+contract+identity) 2026-05-23 12:50:54 +00:00
Hermes
3a7fbb38ca feat: alternative social-first growth scenario 2026-05-23 12:19:38 +00:00
Hermes
04b2bf87dd fix: ** label:** → *label:* (inline bold, not headings) 2026-05-23 12:13:22 +00:00
Hermes
e1777d2538 Revert "fix: org-mode bold syntax — ** → * (double to single asterisk)" 
This reverts commit a0a1481cae.
 2026-05-23 12:11:16 +00:00
Hermes
a0a1481cae fix: org-mode bold syntax — ** → * (double to single asterisk) 2026-05-23 12:09:39 +00:00
Hermes
cddaaa4e69 gbrain: sync converted org-mode brain files 2026-05-23 11:57:03 +00:00
Hermes
dec20395b8 gbrain: sync converted org-mode brain files 2026-05-23 11:51:44 +00:00
Hermes
7c4eb5bf59 gbrain: sync converted org-mode brain files 2026-05-23 11:44:48 +00:00
Hermes
38f10960eb gbrain: sync converted org-mode brain files 2026-05-23 11:41:35 +00:00
Hermes
7b8bf3ca5b fix org-mode heading syntax in revenue-hub 2026-05-23 07:58:50 +00:00
Hermes
6da2633f11 gbrain: sync converted org-mode brain files 2026-05-23 07:49:47 +00:00
Hermes
558145741e gbrain: sync converted org-mode brain files 2026-05-23 07:43:55 +00:00
Hermes
536c44b6e8 gbrain: sync converted org-mode brain files 2026-05-23 07:10:05 +00:00
Hermes
9a95212d1a gbrain: sync converted org-mode brain files 2026-05-23 07:00:09 +00:00
Hermes
cf0c9b1f9d gbrain: sync converted org-mode brain files 2026-05-23 06:47:23 +00:00
147 changed files with 9669 additions and 2940 deletions
Expand all files Collapse all files

124
.org-ids.json Normal file
View File

@@ -0,0 +1,124 @@
{
"284f5c7a-1d2b-4e3f-8c6d-9a0b1c2d3e4f": "_index.org",
"a0b1c2d3-e4f5-6a7b-8c9d-0e1f2a3b4c5d": "projects/_index.org",
"433236a2-e5ad-41d4-a27e-4682f8bbc207": "projects/flags/legal-structure-practical-setup.org",
"0a4e0b8f-25e0-4b78-9633-fc37d03cefe9": "projects/flags/asset-protection-structures.org",
"5ac2f037-fc3c-45ac-a6e8-acc20e005cb0": "projects/flags/legal-structure-alternatives.org",
"1e5f6a7b-8c9d-0e1f-2a3b-4c5d6e7f8a9b": "projects/flags/_index.org",
"7a1b2c3d-4e5f-6a7b-8c9d-0e1f2a3b4c5d": "projects/passepartout/_index.org",
"04c2f221-c54f-51e5-b40a-48822cd16d45": "projects/passepartout/common-logic-iso-24707.org",
"4a1f23b0-abc1-4def-9876-543210abcdef": "projects/passepartout/architecture/stage-0-now.org",
"1c3ec48b-446c-50d2-b53e-126a81f5143f": "projects/passepartout/architecture/architecture.org",
"4a1f23b0-abc7-4def-9876-543210abcdef": "projects/passepartout/architecture/stage-6-training.org",
"4a1f23b0-abc4-4def-9876-543210abcdef": "projects/passepartout/architecture/stage-3-lisp-machine.org",
"7f4e6b9a-2c1d-5e8f-9a3b-6d7c4e5f2a1b": "projects/passepartout/architecture/native-org-knowledge-base.org",
"4a1f23b0-abc3-4def-9876-543210abcdef": "projects/passepartout/architecture/stage-2-verification.org",
"1c95ce7d-a2db-506a-9608-df68f9ae211b": "projects/passepartout/architecture/lisp-machine-security.org",
"4a1f23b0-abc8-4def-9876-543210abcdef": "projects/passepartout/architecture/stage-7-remaining.org",
"4a1f23b0-abc2-4def-9876-543210abcdef": "projects/passepartout/architecture/stage-1-social-protocol.org",
"4a1f23b0-abc6-4def-9876-543210abcdef": "projects/passepartout/architecture/stage-5-weights.org",
"5e7f1d2a-3b4c-5d6e-7f8a-9b0c1d2e3f4a": "projects/passepartout/architecture/_index.org",
"b9fa4b7b-bc61-4d7f-918d-ff687b80f2ba": "projects/passepartout/architecture/systemic-effects.org",
"13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70": "projects/passepartout/architecture/self-driving-lisp-machine.org",
"4a1f23b0-abc5-4def-9876-543210abcdef": "projects/passepartout/architecture/stage-4-inference.org",
"68ffa49f-f0d8-42cf-8b69-ae69de8bb815": "projects/passepartout/social-protocol/requirements-10-governance-and-assets.org",
"b25bf753-9799-41ab-82f5-1a1416db756b": "projects/passepartout/social-protocol/requirements-01-overview.org",
"a3243dd0-3209-423b-98e1-51c3eada2658": "projects/passepartout/social-protocol/requirements-07-advanced-integration.org",
"0f949f6c-4cf1-49eb-b9a4-ebcac27ee548": "projects/passepartout/social-protocol/requirements-05-social.org",
"72570648-d943-42e5-a781-3b09791ac6ec": "projects/passepartout/social-protocol/requirements-11-assessment.org",
"90484f4a-5b70-4001-93d6-e610e54ed573": "projects/passepartout/social-protocol/requirements-06-exchange-and-contracts.org",
"2cace571-76bb-4c34-a5f4-68bc20b2e884": "projects/passepartout/social-protocol/requirements-10-user-journey.org",
"6fe67db6-25bd-4d11-bd1d-b44ec809e858": "projects/passepartout/social-protocol/requirements-02-identity.org",
"8b4e0cec-a7b0-4e75-a1e3-c55ae820eb6d": "projects/passepartout/social-protocol/requirements-09-implementation.org",
"f6cfc54b-919b-4311-bcbf-65e976755d40": "projects/passepartout/social-protocol/requirements-04-the-primitive.org",
"df02cddc-944a-4bcd-8ef5-f080870d5f49": "projects/passepartout/social-protocol/requirements-08-library.org",
"8b2c3d4e-5f6a-7b8c-9d0e-1f2a3b4c5d6e": "projects/passepartout/social-protocol/_index.org",
"3b43a9b8-31d1-4479-a35f-22273b74f0c7": "projects/passepartout/social-protocol/requirements-03-infrastructure.org",
"10289e64-a4ff-4c34-828f-f3a9c769b73d": "projects/passepartout/social-protocol/requirements-00-readme.org",
"efc76898-03f7-57ba-923d-35d65da88bb7": "projects/passepartout/strategy/sufficiency-flip.org",
"1d074690-a279-59cb-b91d-e9a22ae104ad": "projects/passepartout/strategy/social-protocol-overview.org",
"57f9538a-6270-4302-8d07-d742168419eb": "projects/passepartout/strategy/social-growth-strategy.org",
"d84679f1-c0c5-5be4-b19c-6573560640ee": "projects/passepartout/strategy/verified-skill-marketplace.org",
"9af13fff-9725-542b-93b1-a555bc74ad72": "projects/passepartout/strategy/lisp-economics.org",
"5f55bbe6-d243-5766-8ccf-5c5cc88a6542": "projects/passepartout/strategy/ai-industry-impact.org",
"528a0f6c-6fd6-41ed-9d59-237958bdaef2": "projects/passepartout/strategy/effects-growth-flywheel.org",
"2e390c1d-65f3-5fb3-b898-ac3fc4291ee7": "projects/passepartout/strategy/social-protocol-usernames.org",
"5961e469-53a3-5f3c-ab72-3c83ef91963f": "projects/passepartout/strategy/investment-thesis.org",
"67faf52f-9126-50a7-b87e-2bedc610dac7": "projects/passepartout/strategy/licensing.org",
"64708e1f-00e9-4cb7-b44b-ea0b98e5296d": "projects/passepartout/strategy/social-protocol-contracts.org",
"9c3d4e5f-6a7b-8c9d-0e1f-2a3b4c5d6e7f": "projects/passepartout/strategy/_index.org",
"aa6d062e-a520-5d14-8773-00687ed9c689": "projects/passepartout/strategy/moats.org",
"29e4dbf3-cf19-589c-8b14-389e8a39d564": "projects/passepartout/strategy/upgrade-lifecycle.org",
"8c7b9812-f8d6-4347-8915-ce8e520b7914": "projects/passepartout/strategy/social-protocol-entry-strategy.org",
"827bc546-e887-5b7c-9b65-6392beaf0920": "projects/passepartout/strategy/verification-monopoly.org",
"d28adac8-08a1-40c4-ae43-b5d8d7b1743f": "projects/passepartout/strategy/enterprise-growth-strategy.org",
"ed05cab4-88e9-4e25-b7c9-346fa39c69a0": "projects/passepartout/strategy/revenue.org",
"dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70": "projects/passepartout/strategy/time-estimates.org",
"84a537b4-4256-50c8-91f5-dd5b4538418f": "projects/passepartout/strategy/verification-appliance.org",
"1a2b38df-20ba-58ca-ba55-a072be67bd0d": "projects/passepartout/strategy/pds-as-a-service.org",
"3c6b0449-a8fb-5b89-b82a-34efb21ef5b5": "projects/passepartout/strategy/compute-marketplace.org",
"98364e9d-a8a9-42b7-a9dc-b643fd2ccc4b": "projects/passepartout/strategy/outbound-sales-compliance.org",
"3aa22300-2f25-57b0-8787-9f199cc978b1": "projects/passepartout/strategy/competitors/competitive-analysis.org",
"00ab3a4d-e3de-5605-a67d-12935bb36ab5": "projects/passepartout/strategy/competitors/comparison-with-symbolics.org",
"0d4e5f6a-7b8c-9d0e-1f2a-3b4c5d6e7f8a": "projects/passepartout/strategy/competitors/_index.org",
"1bc22b89-d3eb-4f6d-bcfc-2b0c19c8ed8f": "projects/passepartout/strategy/competitors/social-protocol-competitive-landscape.org",
"85ca69dd-d085-4a55-ad11-021910b1f82e": "projects/passepartout/strategy/competitors/ai-agents-scoping/openclaw.org",
"7a060b36-36db-4eb7-b8cc-844bd6ac9d36": "projects/passepartout/strategy/competitors/ai-agents-scoping/opencode.org",
"416bab7c-4300-4d50-838a-5c7a8ad45d96": "projects/passepartout/strategy/competitors/ai-agents-scoping/thoth.org",
"c3aab2e8-7e43-4abc-93f0-741675cfd78c": "projects/passepartout/strategy/competitors/ai-agents-scoping/aider.org",
"8d73ccb9-34e4-4899-b0c3-605998e9bebc": "projects/passepartout/strategy/competitors/ai-agents-scoping/gemini-cli.org",
"22d0a159-68a2-4587-9375-5046beddc20c": "projects/passepartout/strategy/competitors/ai-agents-scoping/continue.org",
"e929ff32-28d8-4a29-bf74-d55babc040d1": "projects/passepartout/strategy/competitors/ai-agents-scoping/codex-cli.org",
"c652688a-1ea0-487c-9222-00e954efe8a1": "projects/passepartout/strategy/competitors/ai-agents-scoping/hermes-agent.org",
"512dd121-2292-4f3d-ac53-31bf3d12a60f": "projects/passepartout/strategy/competitors/ai-agents-scoping/claude-code.org",
"b852ec69-0fc2-435c-ae1e-6b83e49b3ca3": "projects/passepartout/strategy/compliance/appi.org",
"e777064d-9950-42d5-980d-8c78cda91500": "projects/passepartout/strategy/compliance/pipa.org",
"e2ab887d-9f28-4da6-8388-e6c035e9d9c5": "projects/passepartout/strategy/compliance/iso-27001.org",
"4a2bc62b-3f21-4212-9cd9-f9add8fc0be1": "projects/passepartout/strategy/compliance/glba.org",
"03ebdb80-a9af-4e76-a443-8556424996ed": "projects/passepartout/strategy/compliance/fatf.org",
"e6993701-3c67-49bf-82f3-06907572cbf3": "projects/passepartout/strategy/compliance/fedramp.org",
"7f46764b-47b8-4892-a526-2c1b9ee6e6df": "projects/passepartout/strategy/compliance/irap.org",
"fc736aec-ef53-4759-9787-62bc8deea2e7": "projects/passepartout/strategy/compliance/ifrs.org",
"68c55deb-72bf-4b15-ac28-bcc792057543": "projects/passepartout/strategy/compliance/ifc-ps.org",
"513d5996-4ac7-4567-a992-18fc01599104": "projects/passepartout/strategy/compliance/gdpr.org",
"6a5884c8-e9b5-477e-bbf6-aa9ffd967739": "projects/passepartout/strategy/compliance/un-cefact.org",
"84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f": "projects/passepartout/strategy/compliance/hipaa.org",
"177aad72-5626-444d-a2e4-af8e1263b125": "projects/passepartout/strategy/compliance/world-bank-esf.org",
"834689e9-be0a-4822-9085-9b6b22294fd2": "projects/passepartout/strategy/compliance/privacy-act-aus.org",
"904f5f12-ec9a-4cbf-854a-0b9b1e11a521": "projects/passepartout/strategy/compliance/apra-cps-234.org",
"1c4c91ec-c465-44ab-bd91-4c3b45909ddb": "projects/passepartout/strategy/compliance/_index.org",
"c871a9f4-dd53-4e93-aa50-6acf0c606a9b": "projects/passepartout/strategy/compliance/lgpd.org",
"b8cf51e8-5f39-49ad-9547-a792a2e446aa": "projects/passepartout/strategy/compliance/eidas2.org",
"06fcdb02-2643-4f9d-ab41-e711a99cc390": "projects/passepartout/strategy/compliance/eu-ai-act.org",
"ed65031c-cbd2-4ad2-bd53-a67791e183cd": "projects/passepartout/strategy/compliance/soc2.org",
"c9830152-0160-4bdc-ab03-6f308ad43536": "projects/passepartout/strategy/compliance/sox.org",
"f6a0c00e-e922-44af-99ce-6412c4b73745": "projects/passepartout/strategy/compliance/quebec-law-25.org",
"748db16a-1382-4e5e-8812-a5d57a8de131": "projects/passepartout/strategy/compliance/nis2.org",
"87996d87-100c-4bf6-8546-a860b9d7c25b": "projects/passepartout/strategy/compliance/ccpa-cpra.org",
"ce81fefc-b7a8-4be5-912f-55fd30970b6e": "projects/passepartout/strategy/compliance/cra.org",
"36e5b948-e07b-477f-9036-4dfe88254347": "projects/passepartout/strategy/compliance/compliance-framework-mapping.org",
"085b76cc-4a65-4660-9c70-85aee10ca99e": "projects/passepartout/strategy/compliance/ismap.org",
"e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c": "projects/passepartout/strategy/compliance/compliance-index.org",
"748b0cc7-7f42-49fb-8ee3-1ae49048a178": "projects/passepartout/strategy/compliance/iso-27701.org",
"022109ad-f031-44c4-8ea0-0b3c9402ca90": "projects/passepartout/strategy/compliance/oecd.org",
"fed19a24-ad81-4837-a12b-dafbd3ec110a": "projects/passepartout/strategy/compliance/dpdp-act.org",
"9bc29937-d59a-4ae4-9623-3d17a1fe6ebb": "projects/passepartout/strategy/compliance/uk-gdpr.org",
"4eef0993-6671-41cf-ba20-d1443a3ec49d": "projects/passepartout/strategy/compliance/basel-iii.org",
"581666ba-f72c-406b-8556-93876d2b30bf": "projects/passepartout/strategy/compliance/ny-dfs-500.org",
"c34940cc-090e-57c4-8020-e78b1d32b96c": "projects/passepartout/strategy/compliance/domain-gate-packages.org",
"bafdaa23-de0b-444c-9151-c87ac65add32": "projects/passepartout/strategy/compliance/lfp-dppp.org",
"717ef2df-2a80-4362-b23a-5e7e12554251": "projects/passepartout/strategy/compliance/dora.org",
"1e2f3a4b-5c6d-7e8f-9a0b-1c2d3e4f5a6b": "ideas/world-models-plain-language.org",
"3a4b5c6d-7e8f-9a0b-1c2d-3e4f5a6b7c8d": "ideas/architectural-integration-three-pronged.org",
"2cdca4b0-6b41-44b4-acb0-af21d0e27b00": "ideas/orders-of-magnitude-time.org",
"9c0d1e2f-3a4b-5c6d-7e8f-9a0b1c2d3e4f": "ideas/knowledge-tree-middle.org",
"f4e5d6c7-b8a9-0c1d-2e3f-4a5b6c7d8e9f": "ideas/schafmeister-clasp-nanotechnology.org",
"2afd9a3c-e96a-54c7-ac77-a05a28065b4b": "ideas/biology-parallels.org",
"4b5c6d7e-8f9a-0b1c-2d3e-4f5a6b7c8d9e": "ideas/neurological-software-empirical-middle.org",
"0d1e2f3a-4b5c-6d7e-8f9a-0b1c2d3e4f5a": "ideas/world-models-middle-domain.org",
"7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d": "ideas/open-source-wolfram-lisp.org",
"329a30cd-55fb-496d-a60b-91388c211bba": "ideas/_index.org",
"5c6d7e8f-9a0b-1c2d-3e4f-5a6b7c8d9e0f": "ideas/wider-implications-three-pronged.org",
"8b9c0d1e-2f3a-4b5c-6d7e-8f9a0b1c2d3e": "ideas/passepartout-bootstrap-mathematica.org",
"2f3a4b5c-6d7e-8f9a-0b1c-2d3e4f5a6b7c": "ideas/practical-powers-three-pronged.org"
}

17
_index.org Normal file
View File

@@ -0,0 +1,17 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 284f5c7a-1d2b-4e3f-8c6d-9a0b1c2d3e4f
:END:
#+title: Brain
#+filetags: :index:navigation:
Personal knowledge base — projects, concepts, and meta-thinking.
** Projects
- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Passepartout]] — a verifiable personal intelligence: self-bootstrapping Lisp machine, gate-verified reasoning, social protocol. Architecture, staged roadmap, strategy, competitive analysis, compliance landscape.
- [[id:1e5f6a7b-8c9d-0e1f-2a3b-4c5d6e7f8a9b][Flags]] — legal structures: entity types, jurisdictional analysis, asset protection, practical setup guides.
** Concepts and meta-thinking
- [[id:329a30cd-55fb-496d-a60b-91388c211bba][Ideas]] — cross-domain frameworks, reference material, and thinking tools.

27
ideas/_index.org Normal file
View File

@@ -0,0 +1,27 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 329a30cd-55fb-496d-a60b-91388c211bba
:ID: auto-ideas
:END:
#+title: Ideas
#+filetags: :index:
Cross-domain concepts, speculative analysis, and architectural thinking for the Passepartout project.
**The three-pronged system series** — new tonight:
- [[id:f4e5d6c7-b8a9-0c1d-2e3f-4a5b6c7d8e9f][Schafmeister and Clasp]] — Lisp in computational nanotechnology, existence proof for the architecture
- [[id:7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d][Open-source Wolfram Language in Lisp]] — viability of bootstrapping a Mathematica equivalent
- [[id:8b9c0d1e-2f3a-4b5c-6d7e-8f9a0b1c2d3e][Passepartout bootstrapping Mathematica]] — what the neurosymbolic engine could generate autonomously
- [[id:9c0d1e2f-3a4b-5c6d-7e8f-9a0b1c2d3e4f][Middle of the Knowledge Tree]] — the gap between logic and nanotechnology
- [[id:0d1e2f3a-4b5c-6d7e-8f9a-0b1c2d3e4f5a][The Middle Domain as World Models]] — mapping empirical science onto world model architecture
- [[id:1e2f3a4b-5c6d-7e8f-9a0b-1c2d3e4f5a6b][World Models — Plain Language]] — explanation without jargon
- [[id:2f3a4b5c-6d7e-8f9a-0b1c-2d3e4f5a6b7c][Practical Powers of the Three-Pronged System]] — 10 concrete capabilities
- [[id:3a4b5c6d-7e8f-9a0b-1c2d-3e4f5a6b7c8d][Architectural Integration]] — how the three prongs fit into Passepartout's subsystems and stages
- [[id:4b5c6d7e-8f9a-0b1c-2d3e-4f5a6b7c8d9e][Neurological Software in the Empirical Middle]] — neural networks in the provenance framework
- [[id:5c6d7e8f-9a0b-1c2d-3e4f-5a6b7c8d9e0f][Wider Implications]] — what the three-pronged system means for science, safety, regulation, and trust
**Earlier ideas:**
- [[id:2afd9a3c-e96a-54c7-ac77-a05a28065b4b][Biology as Proof of the Lisp Model]] — biological systems as evidence for Lisp architecture
- [[id:2cdca4b0-6b41-44b4-acb0-af21d0e27b00][Orders of Magnitude — Time]] — a time-scale framework for the Passepartout roadmap

22
ideas/agora.org
View File

@@ -1,22 +0,0 @@
:PROPERTIES:
:ID: 1d074690-a279-59cb-b91d-e9a22ae104ad
:END:
#+title: Agora — The Society (Decentralized Network)
#+filetags: :passepartout:agora:network:dids:
Agora is the decentralized identity and communication layer that connects Passepartout instances:
- **Self-sovereign identity** via HD key derivation (BIP-44)
- **Encrypted messaging** via DIDComm (agent-to-agent and agent-to-human)
- **Notes** as atomic, content-addressed, signed data units (mapped from Passepartout memory-objects)
- **Relay Network** for censorship-resistant message routing
- **Personal Data Store (PDS)** — the Merkle fact store exposed as a network-addressable service
- **Compute marketplace** where instances offer symbolic engine capacity
- **Contracts and liquid democracy** infrastructure
The PDS is Passepartout's in-process memory — the Merkle tree, the fact store, the memory-objects. Every memory-object already has a SHA-256 hash, which maps directly to Agora's CIDv1 content addressing.
Revenue paths from Agora:
- [[file:agora-usernames.org][Premium username registry]] — $10M/yr at scale
- [[file:pds-as-a-service.org][PDS as a service]] — $18M/yr at scale
- [[file:compute-marketplace.org][Compute marketplace]] — venture-scale

106
ideas/architectural-integration-three-pronged.org Normal file
View File

@@ -0,0 +1,106 @@
:PROPERTIES:
:CREATED: [2026-05-25 Mon]
:ID: 3a4b5c6d-7e8f-9a0b-1c2d-3e4f5a6b7c8d
:END:
#+title: Architectural Integration of the Three-Pronged System
#+filetags: :ideas:passepartout:architecture:
An analysis of how the deductive / provenance-tracked empirical / probabilistic oracle model fits into Passepartout's architecture, at what stage it becomes operational, and what it means for the existing subsystems.
**The three prongs are not three engines.**
The initial framing (deductive + provenance + probabilistic) implies three parallel reasoning systems. It is more accurate to say: two reasoning engines and one data layer.
- **The symbolic engine** handles everything that can be formalized: deductive proofs, empirical equations, validity predicates, pipeline composition, uncertainty propagation. This is one engine — it reasons about symbols using rules that are either proven (ACL2) or well-defined (force field equations).
- **The probabilistic oracle** (LLM) handles everything that cannot be formalized: parameter selection, model choice, interpretation of results in natural language, failure diagnosis, creative hypothesis generation. It proposes; the symbolic engine checks.
- **The provenance store** is not an engine. It is a structured database that stores empirical parameter sets, validity envelopes, experimental benchmarks, and comparison histories. Neither engine reasons about it as a whole. The symbolic engine queries it for parameters and validity predicates. The LLM queries it for context and updates it with new data.
Two reasoning engines. One curated data layer. This is a cleaner architecture than three parallel systems.
**Where it lives in the existing subsystems.**
The current architecture has four subsystems: Environment, Knowledge, Verification, Social Protocol. The three-pronged model cross-cuts them:
| Subsystem | Deductive role | Empirical role | Oracle role |
|---|---|---|---|
| Environment | Hosts the symbolic engine, runs ACL2 | Hosts the provenance store | Runs the LLM |
| Knowledge | Stores formal theorems and proofs (symbolic index) | Stores empirical parameters and benchmarks (provenance store) | Neural index for semantic search |
| Verification | ACL2 proof checking, formal gate rules | Validity envelope checks, parameter provenance checks | Gate policy interpretation (LLM evaluates natural-language rules) |
| Social Protocol | Sharing verified proofs between instances | Sharing validation histories and benchmark results between instances | Sharing model selection strategies |
The verification subsystem (the gate) is the integration point. Every action that reaches the gate is checked against:
1. Security policy (is this action safe?)
2. Scientific validity (is this model valid in this context?)
3. Consistency (do the symbolic check and the oracle's assessment agree?)
These three checks run as separate gate vectors with the same architecture as every other gate check. No new mechanism needed — just new predicates with access to the provenance store.
**At what stage it becomes operational.**
The infrastructure is staged, not all-at-once:
- **Stage 0 (now)** — The probabilistic oracle exists (the LLM). The provenance store does not. The deductive engine partially exists through Hermes skills (symbolic gate rules as Python, not ACL2). The empirical layer is invisible — the LLM reasons about chemistry, biology, and engineering using training data alone, without systematic provenance.
- **Stage 1 (social protocol)** — The provenance store prototype can be introduced here as a side effect of signed messages and data exchange. When instances share a validated force field parameter, the message carries a signature and a source. The receiving instance stores it with provenance. This is a natural crawl before the full infrastructure.
- **Stage 2 (gate as software)** — The provenance store becomes operational infrastructure. The gate needs to check validity envelopes to do its job properly. This is the correct stage to introduce it because: (a) the gate is being built anyway, (b) validity checking is a gate predicate like any other, and (c) the provenance store is just a structured knowledge base — the Knowledge subsystem already has the machinery for storing and querying structured data. The symbolic index (formal facts) and the provenance store (empirical parameters) differ in what they store, not in how they store it.
- **Stage 3 (Lisp machine)** — The symbolic engine is native in one address space. ACL2 runs at hardware level. The provenance store becomes a native Lisp hash table with persistence. The empirical layer is fully integrated: the symbolic engine queries the provenance store directly, the gate checks validity predicates in the evaluation loop itself, and the LLM still proposes model selections but every proposal is verified against the provenance store before execution.
- **Stage 4+ (in-process inference)** — The LLM moves in-process. The three components (symbolic engine, provenance store, LLM oracle) share one address space. No IPC between them. The query cycle is: LLM proposes a model → symbolic engine checks it against the provenance store → if valid, execute → if invalid, return to LLM with diagnostic. This loop runs at native speed.
**The empirical middle is not a separate kind of reasoning.**
The deepest question in the set: does the middle empirical part have both neuro and symbolic aspects?
Yes, and the split is clean.
The equations that describe an empirical model — Hooke's law for bond stretching, the Lennard-Jones potential for van der Waals interactions, the Born equation for solvation — are formal symbolic expressions. They can be parsed, manipulated, differentiated, verified by ACL2, and composed into pipelines. This is symbolic engine territory.
The parameters in those equations — the spring constants, the well depths, the atomic radii — are derived from experimental data through optimization and fitting. They cannot be derived from the equations themselves. This is not reasoning; it is curation. The provenance store holds them with sources and confidence intervals.
The selection of which model to apply to a given problem requires judgment about the domain, the available data, and the intended use of the result. The LLM handles this: it knows that a protein-protein docking problem needs a different force field than a small-molecule conformational search.
The composition of models into a pipeline (compute this, pipe into that, plot the other) is a program. The symbolic engine runs the pipeline. The LLM may propose the pipeline structure, but the execution is deterministic.
The diagnosis of failure — "this prediction was wrong and here is why" — is the hardest part and requires the most integration. The symbolic engine detects the validity envelope violation and reports the specific parameter that caused it. The LLM interprets the failure in context: "the bond angle term for this functional group was parameterized against small molecules; your molecule has bulky substituents that change the preferred angle."
| Aspect of the empirical middle | Handled by | Why |
|---|---|---|
| The equations themselves | Symbolic engine | They are symbolic expressions — verifiable, differentiable, composable |
| The parameter values | Provenance store (data) | Fitted to data, not reasoned about |
| Model selection | LLM oracle | Requires contextual judgment |
| Pipeline composition | Symbolic engine (execute) + LLM (propose) | Execution is deterministic; design is creative |
| Validity envelope checking | Symbolic engine | A logical predicate over known state |
| Uncertainty propagation | Symbolic engine | A formula that composes component uncertainties |
| Interpretation of results | LLM oracle | Requires natural language |
| Failure diagnosis | Both: symbolic engine pinpoints the violation, LLM explains why | The factual cause is formal; the narrative cause is contextual |
| Creative design (new molecules, new experiments) | LLM oracle | Requires open-ended generation |
The empirical middle does not require a new kind of reasoning engine. It requires the two existing engines (symbolic and probabilistic) to cooperate on data (the provenance store) that is neither formal theorem nor raw text — it is curated empirical knowledge with structure, provenance, and uncertainty.
**Does it require "world models"?**
The word "world model" is not necessary for the architecture. What the architecture requires is:
1. A store of mathematical models (equations + parameters) with provenance
2. A mechanism for checking validity envelopes (predicates over conditions)
3. A mechanism for composing models into pipelines (the existing program execution)
4. A mechanism for propagating uncertainty (formulas + tracked parameters)
The provenance store, the validity predicates, the pipeline executor, and the uncertainty tracker do not need to be called "world model infrastructure." They are features of the existing subsystems:
- The provenance store extends the Knowledge subsystem (it is a structured database, not a new category).
- The validity predicates are gate rules (they check conditions before allowing computation).
- The pipeline executor is the existing neurosymbolic loop (LLM proposes, symbolic engine executes).
- The uncertainty tracker is a mathematical library (error propagation formulas, statistical calculations).
Calling them "world models" is conceptually clarifying but architecturally optional. The infrastructure is the same either way.
**The practical implementation takeaway.**
Stage 2 is the correct entry point. The provenance store is built as a structured data extension to the Knowledge subsystem. Validity predicates are added as gate vectors. No new subsystems are needed — just new data types in the knowledge store, new predicates in the gate, and new functions in the symbolic engine for uncertainty propagation.
The three-pronged model describes what the system does, not what it is built from. The system is still one machine, one address space, one gate, one memex. It just has a more sophisticated understanding of what it knows and how it knows it.

3
ideas/biology-parallels.org
View File

@@ -1,4 +1,5 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 2afd9a3c-e96a-54c7-ac77-a05a28065b4b
:END:
#+title: Biology as Proof of the Lisp Model
@@ -14,4 +15,4 @@ Striking parallels between microbiology and the Lisp model:
6. **Duck typing** — protein folding depends on chemical environment, not type declarations
7. **Concurrent real-time GC** — apoptosis breaks down cell components for recycling by neighboring cells
Biology chose the Lisp model because it is more robust, adaptable, and evolvable. Evolution optimized for survival in an unpredictable environment, not peak single-thread throughput. Biology is the proof that the Lisp model can be efficient at planetary scale, running on hardware that self-assembles from food. See [[file:lisp-economics.org][Lisp economics]] for how these biological parallels inform the business model.
Biology chose the Lisp model because it is more robust, adaptable, and evolvable. Evolution optimized for survival in an unpredictable environment, not peak single-thread throughput. Biology is the proof that the Lisp model can be efficient at planetary scale, running on hardware that self-assembles from food. See [[id:9af13fff-9725-542b-93b1-a555bc74ad72][Lisp economics]] for how these biological parallels inform the business model.

463
ideas/competitive-analysis-2026-05.org
View File

@@ -1,463 +0,0 @@
:PROPERTIES:
:ID: 3aa22300-2f25-57b0-8787-9f199cc978b1
:CREATED: [2026-05-22 Thu]
:END:
#+title: Competitive Analysis — AI Agent Landscape (May 2026)
#+filetags: :passepartout:strategy:competitive:
* Overview
Analyzed 9 competitor codebases alongside Passepartout. The competitive landscape
divides into three categories:
1. Coding agents (Aider, OpenCode, Codex CLI, Claude Code, Gemini CLI)
2. Personal AI assistants (Hermes, OpenClaw, Thoth)
3. CI/check-based systems (Continue)
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 triad architecture — are absent from
every competitor.
* Category 1: Coding Agents
** Aider (Python, ~40K lines, MIT)
Language: Python. ~6.8M pip installs. The oldest and most mature open-source
coding agent.
Architecture: Chat-based Coder class with 5 edit formats (diff, udiff, patch,
whole, architect). Uses litellm for universal provider access (50+ providers).
RepoMap provides codebase awareness via cosine-similarity embedding.
Safety model: Purely prompt-based plus user-confirmation dialogs. No deterministic
gate stack. No sandboxing. No model output validator. The allowed_to_edit() gate
is a single user confirmation call. --yes flag auto-approves. Aider can edit its
own source code with no special protection — self-modification is undetectable.
Data model: Ad-hoc. Chat messages in memory. Git commits for persistence. RepoMap
is a cosine-similarity index. No persistent memory across sessions. No knowledge
graph.
Self-modification: Full. No guard against editing its own files.
Verification: None.
Key gap vs Passepartout: No safety gates, no persistent memory model, no knowledge
representation, no verification, no self-modification protection, no architecture
for neurosymbolic reasoning. It is a thin shell around litellm + edit format
parsers.
** OpenCode (TypeScript/Bun, anomalyco/opencode, 163K★)
The dominant open-source coding agent by adoption. Bun runtime, Effect-TS
functional core, Solid.js TUI, Turborepo monorepo.
Architecture: Dual LLM runtime — default AI SDK (streamText/generateText) +
opt-in native Effect-Schema runtime (@opencode-ai/llm) with 4-axis route
decomposition (Protocol/Endpoint/Auth/Framing). 30+ provider plugins.
Agent workflow DSL with plan/build agent switching. Agent Communication
Protocol (ACP) for inter-agent messaging. Subagents inherit permission
boundaries from parent. 18+ built-in tools + custom tools from config.
Effect-TS ScopedCache per-project state management.
Safety model: Explicitly documentes /not/ sandboxing the agent. The
permission system is rule-based (glob matching, actions: allow/ask/deny)
and exists as a UX feature, not security isolation. Built-in agents have
carefully scoped defaults (build allows most, prompts on doom_loop;
plan denies all edits except plan files; explore denies everything except
grep/glob/bash/webfetch/read; question defaults to deny). Permission
rules are inherited by subagents. Shell tool dynamically scans commands
for filesystem-impacting operations to determine ask patterns.
Data model: SQLite via Drizzle ORM with bun:sqlite or better-sqlite3.
Key tables: SessionTable (project, workspace, parent hierarchy, cost,
tokens, model JSON, agent config JSON, permission JSON, revert snapshot),
MessageTable, PartTable. Project model stores worktree, VCS, sandbox
config. Config is JSON-chain (user home → project root → worktree) with
remote config fetch and mergeDeep with concatenating array semantics.
20 config modules covering agents, permissions, providers, MCP, LSP,
plugins, skills, references, variable.
Self-modification: Agent.generate() interface lets the LLM create new
agent definitions — the system grows its own subagent roster. Skills
system loads domain-specific knowledge packs dynamically.
Verification: None.
Key gap vs Passepartout: No deterministic safety architecture, no
knowledge graph, no Org-mode, no verification/proof system, no
neurosymbolic architecture. The permission system is explicitly labeled
\"not security isolation\" — it's UX, not a gate stack. Largest userbase
and most polished product of any coding agent, but architecturally
conventional.
** Codex CLI (OpenAI, Rust, ~950K lines)
OpenAI's open-source coding agent. Rust, Sandboxed.
Architecture: ~116 crate Rust workspace with a protocol layer (SQ/EQ session types),
sandbox manager (macOS Seatbelt, Linux nsjail), multi-provider support (via defined
protocol, not directly), configurable TUI.
Safety model: Most sophisticated safety system of any coding agent analyzed.
Multi-layer:
- Process hardening (macOS Seatbelt with 4 profile tiers)
- Execution policy engine (defined policy in execpolicy crate)
- Sandboxing via nsjail on Linux, seatbelt on macOS
- Guardian module for tool permission gating
- No prompt-based safety — all deterministic through policy definitions
Data model: Protocol-defined session types. Structured request/response models.
Config through TOML files with schema validation.
Self-modification: Protected by sandbox — the agent cannot escape to modify its
own binary or config without explicit policy override.
Verification: None (no proof system).
Key gap vs Passepartout: No knowledge graph (Org or otherwise), no persistent
memory model, no deterministic gate stack for agent behavior (only OS-level
sandboxing), no ACL2/prover, no neurosymbolic architecture. Strongest sandbox
but weakest cognitive architecture.
** Claude Code (Anthropic, TypeScript/Bun, ~512K lines leaked)
Anthropic's proprietary coding agent. Only available via leaked source analysis.
Not open source.
Architecture: Bun-bundled TypeScript single-file executable. Ink/React terminal UI.
23+ core tools. Subagent forking with byte-identical API prefixes for prompt cache
sharing. Multi-agent coordination mode.
Safety model: Layered deterministic safety — NOT prompt-based:
1. Permission mode system (7 modes: default, acceptEdits, bypassPermissions, etc.)
2. Persistent permission rules (alwaysAllow, alwaysDeny, alwaysAsk, rule sources
from userSettings, projectSettings, localSettings, policySettings)
3. Bash security validator — 2,592 lines of dedicated code with 23+ named
security checks using tree-sitter AST parsing
4. Sandbox runtime for filesystem/network containment
5. Path/mode validation
6. Optional ML bash classifier (ant-only feature)
This is the most sophisticated safety system of any coding agent. Passepartout's
gate stack is architecturally similar (deterministic multi-layer) but Claude
Code's implementation is vastly more mature — 2,592 lines of bash validation
alone is ~50x the equivalent in Passepartout.
Data model: File-based markdown memdir at ~/.claude/projects/<slug>/memory/.
4 memory types: user, feedback, project, reference. YAML frontmatter in .md files.
PROJECT.md and CLAUDE.md for project-level config. No database.
Self-modification: HIGH. Skill system writes SKILL.md files that change future
behavior. Plugin system, cron scheduling, agent spawning.
Verification: None.
Key gap vs Passepartout: No proof system, no neurosymbolic architecture, no
self-verification, no persistent knowledge graph (flat markdown files, not
Org-mode with cross-references), markdown data model lacks semantic depth.
Proprietary — Anthropic controls it completely. Linux-only (uses macOS sandbox
profiles natively). The permission rules system is impressive but structurally
inferior to Passepartout's gate stack because rules are heuristic (regex-based
pattern matching) rather than typed (type-level gates with structural guarantees).
** Gemini CLI (Google, TypeScript, ~525K lines, Apache 2.0)
Google's open-source coding agent. Node.js 20+, Ink/React TUI.
Architecture: 7-package npm monorepo. Core backend handles Gemini API orchestration,
tool execution, policy engine, safety checks, sandbox management, session management,
MCP client. 7-strategy composite model routing chain.
Safety model: Multi-layered:
1. CONSECA (Contextual Security Checker) — AI-driven per-request policy generation
using a separate Gemini Flash model. Principle of least privilege.
2. Policy engine — 4 approval modes (PLAN, DEFAULT, AUTO_EDIT, YOLO), hierarchical
rules with priority scores and wildcard matching
3. 6 sandbox methods (macOS Seatbelt, Docker/Podman, bwrap, gVisor, LXC, Windows)
4. Trusted folders with discovery phase and path traversal protection
5. Policy integrity verification via cryptographic hashes
6. Built-in safety checkers (AllowedPathChecker, CONSECA)
7. Loop detection service
Data model: JSONL session files. Turn-based conversation model. 4-layer config
precedence (system-defaults → user → project → system-override). TOML policy files.
Self-modification: Modifiable hooks system, MCP extensions, custom commands.
Core binaries are protected on disk by file permissions.
Verification: None.
Key gap vs Passepartout: No proof system, no persistent knowledge graph, no
self-verification, no neurosymbolic architecture, lock-in to Google Gemini models
(though it can use others via routing). The CONSECA approach is interesting
(AI-generated policies) but introduces a second LLM call for every security
decision — the opposite of Passepartout's approach of zero-token deterministic gating.
* Category 2: Personal AI Assistants
** Hermes Agent (Python, ~17K core, MIT)
The agent running this conversation. Python, OpenAI-format conversations.
Architecture: Synchronous conversation loop with OpenAI-format messages. 60+
built-in tools. 109+ providers via pluggable transport layer. 15+ messaging
platforms via gateway. MCP client (native, not bridge). Ink/React TUI as Node.js
subprocess. Cron jobs, Kanban board, subagent delegation.
Safety model: Multi-layer but NOT a deterministic gate stack:
1. Message sanitization (surrogates, control chars, malformed JSON)
2. Tirith binary scanner (pre-execution terminal command analysis)
3. Command approval system (manual/smart/off modes)
4. Memory injection detection (prompt injection pattern matching)
5. Secret/PII redaction
6. Tool call guardrails (loop detection)
7. MCP security (env filtering, credential stripping)
8. Context fencing (memory injection span scrubbing)
These are all heuristic or prompt-based — no structural type-level gates.
Tirith is a separate binary, not in-process. The approval system is good but
reactive (LLM proposes → system blocks) rather than preventive (type system
prevents by construction).
Data model: SQLite session DB (FTS5 full-text search). File-based memory
(MEMORY.md + USER.md). YAML config. No knowledge graph. No Org-mode.
Self-modification: Skill system writes SKILL.md files. Memory tool edits
MEMORY.md/USER.md. Config YAML editable. Core Python code is read-only in
execution but the LLM could request modifications to its own source files
(no gate specifically prevents this).
Verification: None.
Key gap vs Passepartout: No deterministic gate stack (heuristic layers, not
structural/typed), no knowledge graph, no Org-mode, no neurosymbolic architecture,
no self-verification, no proof system. Hermes's strength is breadth —
109 providers, 15 platforms, MCP ecosystem, big tool surface. But it has no
depth in safety, knowledge representation, or reasoning architecture.
** OpenClaw (TypeScript/Node.js, ~3.5M lines)
The largest codebase analyzed. Personal AI assistant with 25+ messaging channel
support.
Architecture: pnpm workspace with ~135 bundled plugins. Gateway control plane
routes messages through multi-agent routing. Per-agent sessions, workspaces,
skill registries. Companion native apps (macOS, iOS, Android).
Safety model: Tiered — main agent runs tools directly on host (trusted-operator),
non-main sessions sandboxed via Docker (read-only rootfs, capability dropping,
seccomp/AppArmor, memory/cpu/PID limits, SSH/OpenShell backends).
Data model: Typed JSON/YAML config (openclaw.json). Multi-source model catalog.
Plugin SDK with narrow typed subpath exports.
Self-modification: ACP (Agent Control Protocol) for spawning child sessions.
Skill system with npm distribution and ClawHub registry.
Verification: None.
Key gap vs Passepartout: Same as Hermes — no gate stack, no knowledge graph,
no Org-mode, no verification, no neurosymbolic architecture. Differentiated by
vastly broader channel support and mature plugin ecosystem. But architecturally
conventional — LLM + tools + channels, no cognitive architecture innovation.
** Thoth (Python, ~151K lines, Apache 2.0)
https://github.com/siddsachar/Thoth — Personal AI Sovereignty. Local-first
desktop AI assistant with knowledge graph, tools, voice, vision, shell,
browser automation, workflow engine, and messaging channels.
Architecture: LangGraph create_react_agent (prebuilt ReAct pattern). Dual-mode
streaming via agent.stream(). NiceGUI web UI served by Python app.py with
desktop launcher (tray icon, Ollama auto-start, browser/OS window). Context
trimming via tiktoken to ~85% of model window, base64 data redaction, stale
browser snapshot compression (keeps last 8), MD5 tool result dedup, old tool
result summarization. 50-step recursion limit (chat), 100 (tasks), 120 (Developer
Studio). Agent graph cached by tool set + model override. Checkpoints via
LangGraph's SQLite-backed checkpointer. 30+ tool modules.
Safety model: Shell command classification (tools/shell_tool.py) with 17 blocked
patterns (rm -rf /, mkfs, dd of=/dev/, shutdown, fork bombs, pipe-to-bash, etc.),
30+ safe auto-execute prefixes (ls, cat, grep, git status, etc.), needs-approval
for compound commands (;, &&, ||, |, $(), backticks). Interactive interrupt() for
non-safe shell — LangGraph human-in-the-loop pauses the graph. Per-workflow safety
modes: block (default, refuse non-safe), approve (pause), allow_all.
Prompt-injection defense: scans tool outputs and user inputs for 5 categories
(role overrides, instruction hijacking, data exfiltration, invisible unicode,
hidden HTML directives) — detection-only, no stripping. Filesystem workspace
boundary (~/Documents/Thoth). Opt-in Docker Sandbox for Developer Studio.
Destructive ops (file delete, moderate shell, Gmail send, calendar delete,
memory/task/tracker delete) require confirmation. MCP servers disabled until
tested. Custom Tools reviewed and promoted. No sandboxing of agent runtime
itself — agent runs in-process. No response-level guardrails.
Data model: SQLite (WAL mode) at ~/.thoth/memory.db — shared between knowledge
graph and legacy memory. Knowledge graph: SQLite (durable) + NetworkX MultiDiGraph
(in-memory, rebuilt on startup) + FAISS vector index (semantic recall, rebuilt on
every entity write). 11 entity types (person, preference, fact, event, place,
project, organisation, concept, skill, media, self_knowledge). 67+ typed relations
with 30+ LLM-produced aliases mapped to canonical forms. Dream Cycle refinement
pipeline for entity dedup/merge/stale-confidence decay. Config: JSON files
(skills_config.json, api_keys.json, providers.json, channels_config.json). Keys in
OS credential store (Windows Credential Manager, macOS Keychain, Linux Secret
Service/KWallet). Memory extraction background daemon scanning past conversations
every ~2 hours.
Self-modification: Agent CAN create/update/delete skills via dedicated tools
(thoth_create_skill, thoth_patch_skill, thoth_delete_skill). SKILL.md files with
YAML frontmatter at ~/.thoth/skills/. Bundled skills (read-only) at app root;
user skills override by name. Skill patching requires user confirmation + auto
backup. Maximum 1 patch proposal per conversation. Tool guides cannot be patched.
Self-knowledge block injected into system prompt. No tool to modify agent.py,
prompts.py, or system prompt directly. Developer Studio provides code editing
through approval-gated tools (tool-assisted human workflow, not agent self-mod).
Verification: None formal. Update signature verification (updater.py).
Comprehensive test suite at tests/test_suite.py. No tool-call verification beyond
LangGraph schema validation. No output verification or fact-checking.
Key differentiators vs other assistants: LangGraph ReAct agent with structured
streaming event model. Personal knowledge graph (11 entity types, 67 relations,
NetworkX + FAISS). Developer Studio (Docker sandbox, code threads, Git operations,
approval modes). Designer Studio (decks, documents, landing pages, sandboxed
interactive runtime). 5 messaging channels (Telegram, Discord, Slack, WhatsApp,
SMS) with streaming, reactions, media processing. Background workflow engine
(schedules, webhooks, step pipelines, conditions, approvals, concurrency groups).
30+ tool modules including browser automation, shell, Gmail, Calendar, X, image/
video generation. 39 curated Ollama tool-calling models. 10 LLM providers (Ollama,
OpenAI, Anthropic, Google AI/Gemini, xAI/Grok, MiniMax, OpenRouter, Ollama Cloud,
ChatGPT/Codex subscription, custom endpoints). MCP client (stdio, Streamable HTTP,
SSE) with namespaced tools, approval gates. No accounts, no telemetry, no hosted
server. Local-first with OS credential store.
Key gap vs Passepartout: No deterministic gate stack — shell safety is pattern
list (17 blocked, 30 safe), not typed gates. No sandboxed agent runtime. No
proof system. No output guardrails. No neurosymbolic architecture. No Org-mode.
No Merkle-tree memory. Knowledge graph (SQLite+FAISS) is richer than Hermes but
is LLM-driven entity extraction — no structural integrity guarantees. Thoth's
differentiation from Hermes/OpenClaw is the knowledge graph + Developer/Designer
studios + embedded LangGraph framework — a broader product scope, but still
architecturally conventional (LLM + tools + channels + KG), not a new cognitive
architecture.
* Category 3: CI/Check Systems
** Continue (TypeScript, ~328K lines, Apache 2.0)
Source-controlled AI checks for CI/CD. Markdown-as-gate-policy.
Architecture: Shared core (@continuedev/core) with ~80 provider implementations,
tool-calling engine, config system (YAML/JSON/Markdown). Serves CLI (Ink/React TUI
+ headless CI mode), IDE extensions (VS Code, JetBrains), web dashboard.
Safety model: Three permission levels (allow/ask/exclude). Precedence: mode policies
→ CLI flags → permissions.yaml → built-in defaults. Terminal security package for
shell command analysis via shell-quote parsing. Workspace-scoped file access.
Data model: Markdown files for checks, agents, rules. Source-controlled in-repo.
YAML frontmatter for metadata.
Self-modification: Checks source-controlled — any change goes through git.
Verification: None (the checks are themselves unverified).
Key gap vs Passepartout: The "checks as markdown" concept is philosophically
similar to Passepartout's gate rules (deterministic policies checked before
execution) but the implementation is dramatically simpler — regex-based policy
objects, not a type-level gate stack with structural guarantees. No persistent
agent, no memory, no knowledge graph, no neurosymbolic architecture. It is a
gate system without an agent to gate.
* The Passepartout Advantage
| Dimension | Passepartout | Best Competitor | Gap |
|-----------|--------------|-----------------|-----|
| Safety model | Type-level gates + 11-vector deterministic stack | Claude Code (7 permission modes + 23 bash checks) | Structural vs heuristic. Passepartout's type-level gates prevent self-modification at the category level; competitors block patterns. |
| Knowledge model | Org-mode (tree, properties, TODOs, timestamps, cross-refs, IDs, tags) | Claude Code (flat markdown memdir) | Org-mode's semantic richness is ~15 primitives markdown doesn't have. |
| Memory integrity | Merkle tree + SHA-256 + rollback | Hermes (file-based); Claude Code (flat files + git) | Content-addressed, tamper-evident memory no competitor has. |
| Self-verification | ACL2 → CIC prover (planned) | None | No competitor does provable correctness. |
| Cognitive architecture | 10-80-10 symbolic-first (planned) | 100% LLM (every competitor) | Post-flip, Passepartout uses ~10% of the tokens competitors use. |
| Data format | Org-mode (human-editable, machine-parseable, single file) | JSONL/Markdown/YAML/DB (competitors use 2-5 formats) | Unified format reduces translation layers to zero. |
| Self-modification | Type-level gates + hot-reload | Claude Code (skills), Hermes (skills) | Passepartout's guard against self-modification is structural (type level), not heuristic (pattern list). |
| Triad | Passepartout + Stoa + Agora | None | No competitor is building a full computing stack + social network. |
| Provider independence | Any OpenAI-compatible API | Hermes (109+), Gemini CLI (1 primary) | Comparable to Hermes, better than most. |
* Where Competitors Lead
| Dimension | Leader | Passepartout Status |
|-----------|--------|---------------------|
| Safety implementation maturity | Claude Code (2,592 lines bash security) | Gate stack exists but bash validation is minimal in comparison |
| Provider breadth | Hermes (109+), OpenClaw (50+) | 8 providers — adequate but not competitive |
| Channel/platform support | OpenClaw (25+ channels) | TUI only — no multi-channel |
| Plugin ecosystem | OpenClaw (ClawHub, npm registry) | No plugin marketplace |
| Subagent delegation | Claude Code (fork with context inheritance) | Planned via Screamer planner |
| Codebase size / features shipped | All competitors have working products | In development |
| MCP integration | Hermes, Codex (native), Continue | Planned |
| Sandboxing | Codex CLI (Seatbelt+nsjail), Gemini CLI (6 methods) | None |
| Business model | Hermes (MIT+services), Codex (tokens) | AGPL + appliances + SaaS |
| Cross-platform | Claude Code (macOS/*nix), Codex (macOS) | Linux only |
* Strategic Positioning
Passepartout is not competing in the existing AI agent market. It is building a
new category: provable personal infrastructure.
Competitors optimize for:
- Token efficiency (Aider's edit formats, OpenCode's LSP integration)
- Model flexibility (Hermes' 109 providers)
- Platform reach (OpenClaw's 25 channels)
- UI polish (Gemini CLI's Ink/React, Claude Code's permission dialogs)
- Sandbox security (Codex's Seatbelt, Gemini's gVisor)
Passepartout optimizes for:
- Provable correctness (ACL2 → CIC)
- Data integrity (Merkle tree)
- Cognitive architecture (10-80-10 symbolic-first)
- Safety by construction (type-level gates)
- Unified data model (Org-mode as everything)
- Network effects (Agora)
- Full-stack ownership (Stoa)
These are not axes any competitor cares about. The risk is not that a competitor
builds a better Passepartout — it's that the market never develops a preference
for provable agents. If token-burning LLM agents remain the default and users
don't demand verification, the entire category Passepartout addresses may not
exist yet.
* Immediate Implications for Development
1. Claude Code's safety system is the benchmark to exceed. The type-level gate
architecture is theoretically superior to Claude Code's heuristic patterns,
but the implementation needs to prove it catches things Claude Code
misses.
2. No competitor has anything resembling a neurosymbolic architecture. The 10-80-10
plan has zero competition — but that also means zero market validation.
3. The Org-mode bet is invisible to competitors. They don't see the advantage
because they've never tried to build a knowledge graph from flat markdown files.
This is Passepartout's widest moat — it depends on a skill (Org-mode literate
programming) that no competitor's team has.
4. Hermes is the closest full-stack competitor (tools, skills, cron, subagents,
multi-platform), but architecturally conventional. For Hermes to match
Passepartout, it would need to be rewritten.
5. The coding agents (Aider, OpenCode, Codex) are not competitors — they are
single-purpose tools Passepartout could eventually replace entirely when the
planner matures.
* File references
Repository dumps and analysis artifacts at /tmp/:
- /tmp/aider/ — Aider source (Python)
- /tmp/opencode/ — OpenCode archived source (Go)
- /tmp/codex/ — OpenAI Codex CLI (Rust)
- /tmp/claude-code-leaked-source/ — Claude Code leaked (TypeScript/Bun)
- /tmp/gemini-cli/ — Google Gemini CLI (TypeScript)
- /tmp/openclaw/ — OpenClaw source (TypeScript)
- /tmp/thoth/ — Thoth source (Python)
- /tmp/continue/ — Continue source (TypeScript)
- /usr/local/lib/hermes-agent/ — Hermes Agent (Python)

48
ideas/compliance-framework-mapping.org
View File

@@ -1,48 +0,0 @@
:PROPERTIES:
:ID: e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c
:CREATED: [2026-05-23 Sat]
:UPDATED: [2026-05-23 Sat]
:END:
#+title: Compliance Framework Mapping — Global Regulated Industries
#+filetags: :passepartout:triad:compliance:global:index:
This file has been split into atomic framework notes under [[file:compliance/][compliance/]].
See [[file:compliance/_index.org][Compliance framework index]] for the hub with per-framework links.
See [[file:compliance/first-mover-window.org][First-mover window analysis]] for timing.
See [[file:compliance/revenue-table.org][Revenue table]] for pricing and TAM.
Each framework is its own file in [[file:compliance/][compliance/]]:
- [[file:compliance/hipaa.org][HIPAA]]
- [[file:compliance/soc2.org][SOC 2]]
- [[file:compliance/gdpr.org][GDPR]]
- [[file:compliance/fedramp.org][FedRAMP]]
- [[file:compliance/sox.org][SOX]]
- [[file:compliance/glba.org][GLBA]]
- [[file:compliance/ny-dfs-500.org][NY DFS 500]]
- [[file:compliance/ccpa-cpra.org][CCPA/CPRA]]
- [[file:compliance/quebec-law-25.org][Quebec Law 25]]
- [[file:compliance/uk-gdpr.org][UK GDPR]]
- [[file:compliance/nis2.org][NIS2]]
- [[file:compliance/eu-ai-act.org][EU AI Act]]
- [[file:compliance/dora.org][DORA]]
- [[file:compliance/eidas2.org][eIDAS 2.0]]
- [[file:compliance/cra.org][CRA]]
- [[file:compliance/appi.org][APPI]]
- [[file:compliance/ismap.org][ISMAP]]
- [[file:compliance/pipa.org][PIPA]]
- [[file:compliance/privacy-act-aus.org][Privacy Act Australia]]
- [[file:compliance/apra-cps-234.org][APRA CPS 234]]
- [[file:compliance/irap.org][IRAP]]
- [[file:compliance/dpdp-act.org][DPDP Act India]]
- [[file:compliance/lgpd.org][LGPD Brazil]]
- [[file:compliance/lfp-dppp.org][LFPDPPP Mexico]]
- [[file:compliance/iso-27001.org][ISO 27001]]
- [[file:compliance/iso-27701.org][ISO 27701]]
- [[file:compliance/basel-iii.org][Basel III]]
- [[file:compliance/fatf.org][FATF AML/CFT]]
- [[file:compliance/ifrs.org][IFRS]]
- [[file:compliance/oecd.org][OECD Privacy/AI]]
- [[file:compliance/world-bank-esf.org][World Bank ESF]]
- [[file:compliance/ifc-ps.org][IFC PS]]
- [[file:compliance/un-cefact.org][UN/CEFACT]]

79
ideas/compliance/_index.org
View File

@@ -1,79 +0,0 @@
:PROPERTIES:
:ID: e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c
:CREATED: [2026-05-23 Sat]
:UPDATED: [2026-05-23 Sat]
:END:
#+title: Compliance Framework Index — Global Regulated Industries
#+filetags: :passepartout:triad:compliance:global:index:hub:
The verification monopoly and domain gate package revenue streams depend on
selling into regulated industries. These industries buy compliance, not software.
Each framework below maps to a gate package the triad can sell — ACL2-verified
gate rules that produce deterministic audit trails.
See [[file:first-mover-window.org][First-mover window analysis]] and [[file:revenue-table.org][Revenue table]] for the consolidated view.
* US Frameworks
- [[file:hipaa.org][HIPAA]] — Health privacy ($50K/yr, 500K+ orgs)
- [[file:soc2.org][SOC 2]] — Service organization controls ($50K/yr, 100K+ orgs)
- [[file:fedramp.org][FedRAMP]] — Federal cloud authorization ($100K/yr, 1K providers)
- [[file:sox.org][SOX]] — Financial controls ($50K/yr, 10K orgs)
- [[file:glba.org][GLBA]] — Financial privacy ($40K/yr, 20K orgs)
- [[file:ny-dfs-500.org][NY DFS 500]] — NY financial cybersecurity ($30K/yr, 3K orgs)
- [[file:ccpa-cpra.org][CCPA/CPRA]] — California privacy ($40K/yr, 50K+ orgs)
* Canada
- [[file:quebec-law-25.org][Quebec Law 25]] — Provincial privacy ($25K/yr, 10K+ orgs)
* UK and EU
- [[file:gdpr.org][GDPR]] — EU privacy ($50K/yr, 500K+ orgs)
- [[file:uk-gdpr.org][UK GDPR]] — UK privacy ($40K/yr, 100K+ orgs)
- [[file:nis2.org][NIS2]] — Network security ($50K/yr, 160K orgs)
- [[file:eu-ai-act.org][EU AI Act]] — AI regulation ($75K/yr, 100K+ orgs)
- [[file:dora.org][DORA]] — Financial resilience ($50K/yr, 22K+ orgs)
- [[file:eidas2.org][eIDAS 2.0]] — Digital identity ($30K/yr, 10K+ orgs)
- [[file:cra.org][CRA]] — Product cybersecurity ($40K/yr, 50K+ orgs)
* Asia-Pacific
- [[file:appi.org][APPI]] — Japan privacy ($40K/yr, 100K+ orgs)
- [[file:ismap.org][ISMAP]] — Japan cloud authorization ($75K/yr, 500 providers)
- [[file:pipa.org][PIPA]] — South Korea privacy ($35K/yr, 50K+ orgs)
- [[file:privacy-act-aus.org][Privacy Act]] — Australia privacy ($35K/yr, 50K+ orgs)
- [[file:apra-cps-234.org][APRA CPS 234]] — Australian financial security ($40K/yr, 500 orgs)
- [[file:irap.org][IRAP]] — Australian cloud authorization ($75K/yr, 300 providers)
- [[file:dpdp-act.org][DPDP Act]] — India privacy ($30K/yr, 500K+ orgs)
* Latin America
- [[file:lgpd.org][LGPD]] — Brazil privacy ($30K/yr, 200K+ orgs)
- [[file:lfp-dppp.org][LFPDPPP]] — Mexico privacy ($25K/yr, 50K+ orgs)
* International
- [[file:iso-27001.org][ISO 27001]] — ISMS ($40K/yr, 60K+ orgs)
- [[file:iso-27701.org][ISO 27701]] — Privacy management ($35K/yr, 1K+ orgs)
- [[file:basel-iii.org][Basel III]] — Banking capital ($100K/yr, 500 G-SIBs)
- [[file:fatf.org][FATF]] — AML/CFT ($50K/yr, 50K+ orgs)
- [[file:ifrs.org][IFRS 17]] — Insurance accounting ($75K/yr, 5K+ orgs)
- [[file:oecd.org][OECD Guidelines]] — Privacy/AI principles (indirect)
- [[file:world-bank-esf.org][World Bank ESF]] — Development finance ($50K/yr)
- [[file:ifc-ps.org][IFC PS]] — Project finance ($50K/yr)
- [[file:un-cefact.org][UN/CEFACT]] — Trade facilitation ($30K/yr, 50K+ orgs)
* Strategic View
| Region | Frameworks | Total TAM | First-mover priority |
|--------|-----------|-----------|---------------------|
| US | 7 | ~$33B | FedRAMP (procurement gate), NY DFS 500 (growing) |
| UK/EU | 7 | ~$24B | NIS2 (2025 deadline), AI Act (Aug 2026), DORA (in effect) |
| Asia-Pacific | 7 | ~$9B | DPDP (rules drafting), ISMAP/IRAP (gov cloud gates) |
| Latin America | 2 | ~$7B | LGPD (largest LATAM market) |
| International | 9 | ~$4.5B | ISO 27001 (universal baseline), World Bank/IFC (no market exists) |
Next: [[file:first-mover-window.org][First-mover window analysis]] | [[file:revenue-table.org][Full revenue table]]
See also: [[file:../../ideas/verification-monopoly.org][Verification monopoly]], [[file:../../ideas/domain-gate-packages.org][Domain gate packages]],
[[file:../../ideas/compute-marketplace.org][Compute marketplace]], [[file:../../ideas/infrastructure-lock-in.org][Infrastructure lock-in]]

23
ideas/compliance/first-mover-window.org
View File

@@ -1,23 +0,0 @@
:PROPERTIES:
:ID: auto-first-mover-window
:CREATED: [2026-05-23 Sat]
:END:
#+title: First-Mover Window Analysis
#+filetags: :passepartout:compliance:strategy:first-mover:
* First-Mover Window Analysis
The first-mover window is the time in which a new compliance tool can establish
dominance before incumbents respond or the market settles on a standard approach.
| Window | Frameworks | Rationale |
|--------|-----------|-----------|
| **Critical (<12 months)** | EU AI Act (Aug 2026 effective), NIS2 (Oct 2025 deadline), DORA (Jan 2025 — already in effect) | Regulation is active or imminent. Buyers are desperate. No established vendor. |
| **Wide (12-36 months)** | DPDP Act 2023 (rules drafting), India privacy; Privacy Act Review (Australia); Quebec Law 25; CRA phased enforcement | Regulation not yet fully enforced. Rules being written. Market forming. |
| **Mature (commodity)** | GDPR (2018), SOX (2002), HIPAA (1996), GLBA (1999), Basel III (2010), FATF 40 Recs | Market has established vendors. First-mover advantage requires displacing incumbents via superior architecture. |
| **Latent (undiscovered)** | OECD AI Principles, UN/CEFACT, World Bank ESF, IFC PS | Compliance exists but is document-based or consultant-delivered. No software market has formed. The first gate package creates the category. |
See also: [[file:_index.org][Compliance index]], [[file:revenue-table.org][Revenue table]],
[[file:../../ideas/verification-appliance.org][Verification appliance]], [[file:../../ideas/verification-monopoly.org][Verification monopoly]]

60
ideas/compliance/revenue-table.org
View File

@@ -1,60 +0,0 @@
:PROPERTIES:
:ID: auto-revenue-table
:CREATED: [2026-05-23 Sat]
:END:
#+title: Compliance Framework Revenue Table
#+filetags: :passepartout:compliance:revenue:pricing:
* Expanded Revenue Table
| Framework | Region | Gate price/yr | Addressable orgs | Revenue potential | First-mover window | Gate rule type |
|-----------|--------|--------------|------------------|-------------------|---------------------|----------------|
| HIPAA | US | $50K | 500K+ | $25B | Mature (incumbent disruption) | Privacy + access control |
| SOC 2 | US/Global | $50K | 100K+ | $5B | Mature (incumbent disruption) | Access control + audit |
| GDPR | EU | $50K | 500K+ | $25B | Mature (incumbent disruption) | Privacy + consent |
| FedRAMP | US | $100K | 1K (providers) | $100M | Moderate (<300 authorized) | Continuous monitoring |
| SOX | US | $50K | 10K | $500M | Mature (manual audit disruption) | Financial controls |
| GLBA | US | $40K | 20K | $800M | Moderate | Financial privacy |
| NY DFS 500 | US (NY) | $30K | 3K | $90M | Wide | Cybersecurity controls |
| CCPA/CPRA | US (CA) | $40K | 50K+ | $2B | Moderate | Privacy opt-out flows |
| NIS2 | EU | $50K | 160K | $8B | Critical (2025) | Cybersecurity + supply chain |
| EU AI Act | EU | $75K | 100K+ | $7.5B | Critical (Aug 2026) | AI risk management |
| DORA | EU | $50K | 22K+ | $1.1B | Critical (in effect) | ICT resilience |
| eIDAS 2.0 | EU | $30K | 10K+ | $300M | Wide (wallet buildout) | Identity gates |
| CRA | EU | $40K | 50K+ | $2B | Wide (phased 2025-2027) | Product security |
| UK GDPR | UK | $40K | 100K+ | $4B | Mature (GDPR derivative) | Privacy |
| APPI | Japan | $40K | 100K+ | $4B | Moderate | Cross-border privacy |
| ISMAP | Japan | $75K | 500 (providers) | $37.5M | Wide (<100 registered) | Gov cloud assessment |
| PIPA | South Korea | $35K | 50K+ | $1.75B | Wide (2024 amendments settling) | Privacy + consent |
| Privacy Act | Australia | $35K | 50K+ | $1.75B | Wide (reforms legislating) | Privacy + AI transparency |
| APRA CPS 234 | Australia | $40K | 500 | $20M | Moderate | Info security controls |
| IRAP | Australia | $75K | 300 (providers) | $22.5M | Wide | Gov cloud assessment |
| DPDP Act | India | $30K | 500K+ | $15B | Wide (rules drafting) | Privacy + consent |
| LGPD | Brazil | $30K | 200K+ | $6B | Moderate | Privacy |
| LFPDPPP | Mexico | $25K | 50K+ | $1.25B | Wide | Privacy |
| ISO 27001 | Global | $40K | 60K+ | $2.4B | Mature (manual disruption) | ISMS controls |
| ISO 27701 | Global | $35K | 1K+ | $35M | Wide (growing) | Privacy management |
| Basel III | Global (banking) | $100K | 500 (G-SIBs) | $50M | Mature (incumbent disruption) | Capital adequacy |
| FATF AML/CFT | Global | $50K | 50K+ | $2.5B | Mature (incumbent disruption) | CDD + screening |
| IFRS 17 | Global (insurance) | $75K | 5K+ | $375M | Mature (actuarial verification) | Contract classification |
| UN/CEFACT | Global (trade) | $30K | 50K+ | $1.5B | Latent (no market exists) | Cross-border data rules |
| World Bank ESF | Global (dev finance) | $50K | 1K+ (projects) | $50M | Latent (no market exists) | ES compliance gates |
| IFC PS | Global (project finance) | $50K | 500+ (deals) | $25M | Latent (no market exists) | ES compliance gates |
A compute marketplace provider with authorization in 5+ frameworks (FedRAMP +
ISMAP + IRAP + SOC 2 + ISO 27001) becomes the default infrastructure provider
for regulated cloud globally. The gate package portfolio alone — a mid-size
enterprise running 10+ packages — generates $500K/yr+ in recurring revenue.
At 10,000 such enterprises: $5B/yr. The first-mover advantage is not about any
single framework — it is about being the first to offer a unified gate stack
that maps to all of them.
A compute marketplace provider with authorization in 5+ frameworks (FedRAMP +
ISMAP + IRAP + SOC 2 + ISO 27001) becomes the default infrastructure provider
for regulated cloud globally. The gate package portfolio alone — a mid-size
enterprise running 10+ packages — generates $500K/yr+ in recurring revenue.
At 10,000 such enterprises: $5B/yr.
See also: [[file:_index.org][Compliance index]], [[file:first-mover-window.org][First-mover window analysis]],
[[file:../../ideas/verification-monopoly.org][Verification monopoly]], [[file:../../ideas/compute-marketplace.org][Compute marketplace]]

14
ideas/cost-structure.org
View File

@@ -1,14 +0,0 @@
:PROPERTIES:
:ID: 0b5a8a74-cfd6-542d-bc88-4eb3cd8626f9
:END:
#+title: Cost Structure — Zero Marginal Cost
#+filetags: :passepartout:economics:cost:marginal:zero:
- **One-time cost:** [[file:gate-rule-encoding.org][gate-rule encoding]] for a domain (from hours for codified domains up to months for tacit domains)
- **Near-zero marginal cost:** ACL2 proof + Screamer consistency check + VivaceGraph lookup per interaction — all CPU-native, all in-image
- **No recurring LLM API costs** for the 80% symbolic reasoning layer
- **After [[file:sufficiency-flip.org][sufficiency flip]]:** pennies per day vs dollars per day for LLM-only
The cost curve inverts: generation is expensive, verification is cheap. This is the inversion Passepartout exploits. This is the core insight of [[file:lisp-economics.org][Lisp economics]] — symbolic verification costs approach zero while LLM token costs remain constant.
Token demand shifts from "every interaction burns tokens" to "only unfamiliar interactions burn tokens." Steady-state per-user LLM consumption drops by an order of magnitude.

17
ideas/domain-gate-packages.org
View File

@@ -1,17 +0,0 @@
:PROPERTIES:
:ID: c34940cc-090e-57c4-8020-e78b1d32b96c
:END:
#+title: Domain Gate Rule Subscriptions
#+filetags: :passepartout:revenue:gate-rules:compliance:subscription:
Pre-verified [[file:gate-rule-encoding.org][gate rule]] packages for specific compliance domains. Translated from published regulations by the LLM, verified by ACL2, reviewed by a human for the 5% ambiguous edge cases.
- HIPAA package: $50K/yr
- SOC2 package: $50K/yr
- GDPR package: $50K/yr
- FedRAMP package: $100K/yr
- Combined enterprise: $250K/yr
Switching costs are high — changing packages means re-verifying the fact store against new rules. The [[file:infrastructure-lock-in.org][infrastructure lock-in]] compounds: a hospital at $250K/yr in year one grows to $500K-$1M by year five as more packages are added and the fact store becomes more valuable than the software itself.
20 subscriptions in year one = $1M-$5M. These packages are verified using the [[file:verification-appliance.org][verification appliance]] and scored by the [[file:evaluation-harness.org][evaluation harness]].

17
ideas/evaluation-harness.org
View File

@@ -1,17 +0,0 @@
:PROPERTIES:
:ID: 45258a2d-1675-562c-9024-5d1eb2f1ea56
:END:
#+title: Evaluation Harness as Certification Service
#+filetags: :passepartout:revenue:certification:evaluation:regression:
The accumulated regression suite — thousands of edge cases from every deployed instance, every bug fix, every regulatory change — becomes the most comprehensive test of autonomous agent correctness.
**Service:** "Run our 10,000-task suite against your AI agent and get a Merkle-verified score."
**Target:** AI labs proving their agents' capabilities, enterprise procurement requiring independent verification.
**Price:** $50K-$200K per certification.
The regression suite grows with every deployment, making the certification increasingly valuable over time. The early player's suite is the largest because they started first. This is the [[file:collective-regression-suite.org][collective regression suite]] mechanism in action.
10 certifications in year one = $500K-$2M.
Long-term endpoint: this becomes the UL certification for AI — a third-party verification nobody can ignore. [[file:verification-monopoly.org][The verification monopoly]]. The certification relies on a [[file:verification-appliance.org][verification appliance]] to run the tests in a trusted environment, creating [[file:infrastructure-lock-in.org][infrastructure lock-in]] as certification history accumulates on the platform. These dynamics form powerful [[file:moats.org][moats]].

17
ideas/gate-rule-encoding.org
View File

@@ -1,17 +0,0 @@
:PROPERTIES:
:ID: 45ea493b-94ad-5885-aa65-0c846e5c3c1d
:END:
#+title: Gate Rule Encoding from Codified Domains
#+filetags: :passepartout:gates:rules:encoding:llm:translation:
Laws, regulations, standards, procedures, and technical specifications are already written down in structured text. The LLM does not need to *reason* about them — it needs to *translate* them into gate rules and ACL2 theorems.
Example: The US Federal Acquisition Regulation (FAR) is ~2,000 pages. A frontier LLM can ingest the FAR and produce a plist of gate rules:
- (if contract > $250K AND not small-business-set-aside → :deny)
- (if sole-source AND no justification-documented → :deny, produce-justification)
ACL2 verifies the rule set for internal consistency. Screamer checks against existing compliance facts. The human reviews the bootstrap output and approves or corrects individual rules.
The key distinction: the LLM is not *extracting knowledge from prose* — it is *translating a known rule system into a formal representation.* The result is not "the LLM's best guess" but "the rule set as stated in the source document, mechanically transcribed."
For codified domains, the encoding cost drops from weeks to hours. The only bottleneck is human review of the 5% ambiguous rules. This is what makes the [[file:sufficiency-flip.org][sufficiency flip]] economically viable — once gates are encoded, verification is near-free. The resulting rules are packaged into [[file:domain-gate-packages.org][domain gate packages]] that can be reused across deployments.

16
ideas/infrastructure-lock-in.org
View File

@@ -1,16 +0,0 @@
:PROPERTIES:
:ID: 2f783eb4-638e-5afa-9b59-6224d086a712
:END:
#+title: Infrastructure Lock-In and Switching Costs
#+filetags: :passepartout:economics:moats:lock-in:switching:
A hospital that runs Passepartout with HIPAA gate rules ($50K/yr) for five years has accumulated:
- A fact store with a decade of compliance decisions
- A proof forest of verified rules
- An empirical decision history tied to their specific deployment
- Customized gate rules encoding their specific workflows and approvals
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 [[file:domain-gate-packages.org][domain packages]] are added.
This is the strongest residual [[file:moats.org][moat]]. The [[file:evaluation-harness.org][evaluation harness]] (regression suite) is a close second — it grows with every deployment and cannot be ingested from public data. The [[file:verification-monopoly.org][verification monopoly]] and [[file:upgrade-lifecycle.org][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.

17
ideas/investment-thesis.org
View File

@@ -1,17 +0,0 @@
:PROPERTIES:
:ID: 5961e469-53a3-5f3c-ab72-3c83ef91963f
:END:
#+title: Investment Thesis
#+filetags: :passepartout:economics:investment:thesis:
The early player benefits from every other instance of the triad. Every deployed instance feeds edge cases into the [[file:evaluation-harness.org][regression suite]], grows the [[file:compute-marketplace.org][compute marketplace]], and validates the hardware designs. Network effects are positive sum.
Three revenue horizons:
- **Low-hanging fruit (year one, $2M-$12M):** [[file:verification-appliance.org][verification appliances]], [[file:domain-gate-packages.org][domain gate rule subscriptions]], [[file:evaluation-harness.org][evaluation harness certification]], migration services
- **Medium-term (1-3 years, $10M-$50M):** [[file:compute-marketplace.org][compute marketplace]], Relay Network, Lisp Machine hardware; [[file:agora-usernames.org][premium usernames]] ($10M/yr), [[file:pds-as-a-service.org][PDS hosting]] ($18M/yr)
- **Big money (3-10 years, $100M-$1B+):** [[file:verification-monopoly.org][verification monopoly]] (UL certification for AI), [[file:infrastructure-lock-in.org][infrastructure lock-in]], planetary compute marketplace
The switching costs compound. The [[file:moats.org][network effects]] are positive sum. The market is nearly a trillion dollars.
The defensible entity is "the organization that best understands how to adapt Passepartout to your domain" — not "the organization that owns Passepartout."

86
ideas/knowledge-tree-middle.org Normal file
View File

@@ -0,0 +1,86 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 9c0d1e2f-3a4b-5c6d-7e8f-9a0b1c2d3e4f
:END:
#+title: The Middle of the Knowledge Tree — From Logic to Nanotechnology
#+filetags: :ideas:knowledge:passepartout:
In the tree of knowledge model, mathematical foundations and formal logic sit at the root. Schafmeister's molecular nanotechnology sits at a high branch — programmable molecules that bind proteins and catalyze reactions. The distance between them is bridged by a chain of formal and empirical domains. This note maps that chain.
**The full stack, root to branch.**
| Layer | What it formalizes | Formal status | Verification model |
|---|---|---|---|
| 0. Logic / Foundations | Proof theory, set theory, type theory, ACL2 axioms | Deductive | Complete — provable from axioms |
| 1. Algebra | Groups, rings, fields, vector spaces, modules | Deductive | Complete |
| 2. Analysis | Real numbers, limits, continuity, calculus, measure theory | Deductive | Complete (in principle; deep results are hard) |
| 3. Geometry / Topology | Manifolds, differential forms, curvature, homotopy | Deductive | Complete |
| 4. Classical Mechanics | Lagrangian/Hamiltonian mechanics, Newtonian dynamics | Deductive | Complete — follows from variational principles |
| 5. Quantum Mechanics | Hilbert spaces, operators, Schrödinger equation, symmetries | Deductive | Complete (the theory is fully formalizable) |
| 6. Statistical Mechanics | Ensembles, partition functions, Boltzmann distribution, entropy | Deductive | Complete (follows from QM + probability) |
| 7. Electrodynamics | Maxwell's equations, potentials, radiation | Deductive | Complete |
| 8. Quantum Chemistry | Born-Oppenheimer, Hartree-Fock, DFT, coupled cluster | Partially deductive | The equations are formal. The necessary approximations (Börn-Oppenheimer, exchange-correlation functional) are not. |
| 9. Molecular Mechanics | Force fields (AMBER, CHARMM, OPLS), potential functions, non-bonded interactions | Empirical parameterization | The simulation is deterministic. The parameters are fitted to experiment. |
| 10. Molecular Dynamics | Integration schemes, thermostats, barostats, periodic boundaries | Deductive mechanics + empirical inputs | The integrator is provable. The force field parameters are not. |
| 11. Chemical Thermodynamics | Binding constants, free energy surfaces, reaction equilibria, solvation | Mixed deductive/empirical | Statistical mechanics is deductive. Solvation models are not. |
| 12. Structural Biochemistry | Protein folding, protein-ligand binding, docking, enzyme kinetics | Largely empirical | Binding affinity prediction is not deductively solvable from first principles. |
| 13. Organic Chemistry | Reaction mechanisms, stereochemistry, functional group transformations | Empirical with formal structure | Reaction mechanisms are modeled, not derived. They are falsifiable hypotheses, not theorems. |
| 14. Molecular Design | Spiroligomer design, shape-programmable molecules, therapeutic targeting | Empirical design space | Design rules are heuristics validated by experiment, not derived from QM. |
**What changes at layer 8.**
The important transition happens between layers 7 and 8. Everything from logic through quantum mechanics and statistical mechanics is fully formalizable — you can write down the equations, derive the consequences, and verify the derivations. This is the domain where ACL2 can prove correctness against first principles.
Layer 8 (quantum chemistry) is where the first irreducible approximation appears. The Born-Oppenheimer approximation is not a theorem — it is an assumption that nuclei and electrons can be treated separately because nuclei are much heavier. This assumption is empirically excellent but not deductively guaranteed. The exchange-correlation functional in DFT is not derivable — it is a functional whose exact form is unknown and must be approximated.
From layer 9 onward, the models are empirical through and through. Force field parameters are fitted to experimental data. Solvation models are calibrated against known solubilities. Binding affinity predictions are validated by binding assays, not derived from Schrödinger's equation. The models are mathematically rigorous (the simulation correctly integrates Newton's equations), but the inputs to those models are not.
**What this means for Passepartout.**
Passepartout can verify the *computation* at every layer. It can prove that:
- The Schrödinger equation is correctly solved for a given Hamiltonian (layer 5/8).
- The molecular dynamics integrator preserves phase space volume (layer 10).
- The docking algorithm correctly explores the defined conformational space (layer 12).
But it cannot verify that the *model* matches reality. The Born-Oppenheimer approximation, the DFT functional, the force field parameters, the solvation model, the scoring function — these are commitments to empirical reality that no verification system can discharge. They are validated by experiment, not by proof.
This is the same structure as Stage 7 in Passepartout's own roadmap: after all computational threats are eliminated, oracular limits and physical reality remain. The verification subsystem can certify that a simulation is internally consistent. It cannot certify that the simulation's assumptions hold in the real world.
**What Passepartout would need in the middle.**
For each layer 1-7 (deductive), Passepartout already has or can generate the formal mathematics. These are theorems and algorithms that ACL2 can verify against axioms.
For each layer 8-14 (empirically parameterized), Passepartout needs:
1. **A formal model** of the equations (the DFT equations, the force field functional form, the MD integrator) — verified against the mathematical theory.
2. **A parameter database** with provenance (force field parameters, basis sets, solvation parameters, scoring function weights) — not proven but curated, versioned, and traceable to experimental sources.
3. **An empirical validation pipeline** that compares computed predictions against experimental measurements and updates the parameter confidence.
The parameter database with provenance is the crucial addition. For Schafmeister's work, this means:
| Empirical parameter set | Source | Passepartout role |
|---|---|---|
| DFT functional parameters | Fitted to known systems | Trace which functional was used for each calculation |
| Force field parameters (AMBER, CHARMM) | Fitted to QM + experiment | Trace parameter provenance; flag known failure regimes |
| Solvation free energies | Calibrated to measured solubilities | Track calibration data and confidence intervals |
| Binding affinity benchmarks | PDBbind, DUD-E, experimental IC50 | Track benchmark provenance; report uncertainty |
| Spiroligomer design rules | Schafmeister's own experimental data | Formalize as knowledge graph with experimental backing |
**The nature of the bridge.**
The middle of the knowledge tree is not a chain of theorems. It is a lattice of formal models scaffolded by empirical commitments. Each layer relies on the formal correctness of the layer below (the QM solver is correct), but also on approximations and parameters that are not deductively justified.
This is not a weakness of the architecture. It is a correct description of the relationship between mathematics and experiment. The bridge from logic to nanotechnology is built from:
- **Formal mathematics** for what can be proven (the core theories, the algorithms, the simulation correctness)
- **Models with provenance** for what cannot be proven but works (the approximations, the force fields, the scoring functions)
- **Empirical validation** for the claim that the models match reality (experimental data, benchmarks, error bars)
Passepartout's contribution is not to eliminate the empirical layers — that is impossible. Its contribution is to make explicit which parts are deductively verified, which are empirically fitted, and what the provenance trail is for every numerical value that enters a computation. The system cannot make chemistry deductive. It can make every computational output traceable to its assumptions.
---
- [[id:f4e5d6c7-b8a9-0c1d-2e3f-4a5b6c7d8e9f][Schafmeister and Clasp]] — the nanotechnology branch
- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Passepartout Architecture]] — where verification lives
- [[id:9c0d1e2f-3a4b-5c6d-7e8f-9a0b1c2d3e4f][Stage 7 — What Remains]] — oracular, physical, and empirical limits

19
ideas/licensing.org
View File

@@ -1,19 +0,0 @@
:PROPERTIES:
:ID: 67faf52f-9126-50a7-b87e-2bedc610dac7
:END:
#+title: Licensing — AGPLv3 + Commercial
#+filetags: :passepartout:ip:licensing:agpl:commercial:
**AGPLv3 for the public repository.** AGPL closes the ASP loophole: anyone who modifies the software and offers it over a network must release their modified source. Combined with a [[file:patent-strategy.org][patent strategy]], this creates [[file:moats.org][moats]] against proprietary forks.
Crucially: AGPL is a *product requirement*, not a concession. The system's value proposition is provable correctness — every decision has Merkle provenance. This claim is structurally incredible with closed source. An enterprise buyer needs to inspect the gate stack, verify the Merkle implementation, and confirm ACL2 integration. AGPL makes this possible without signing an NDA. This transparency also enables a [[file:pds-as-a-service.org][PDS as a service]] model where enterprises can run their own infrastructure.
**AGPL only covers modifications to code, not:**
- Gate rules specific to a domain (these are data, not code)
- The fact store (empirical data generated from usage)
- Ontology categories (design decisions stored as configuration)
- Proprietary skills loaded at runtime (AGPL boundary on plugin systems is legally unsettled)
**Dual license model:**
- AGPLv3 for open source — builds ecosystem, trust, community
- Commercial license for enterprises that cannot accept AGPL — MySQL/SugarCRM/GraphQL model

16
ideas/lisp-economics.org
View File

@@ -1,16 +0,0 @@
:PROPERTIES:
:ID: 9af13fff-9725-542b-93b1-a555bc74ad72
:END:
#+title: Why Lisp Is Economically Viable Now
#+filetags: :passepartout:economics:lisp:history:C:viability:
The 1980s trade-off was: C is cheap enough for the market. Correctness is a luxury the market cannot afford. The 2020s trade-off is: C is expensive for the market. Incorrectness has become the dominant cost of software. Lisp's verification infrastructure is now the cheaper option.
Four transformations flipped the economics:
1. **Memory is free.** 40MB runtime is noise on a $20 Raspberry Pi with 8GB RAM. In 1980, DRAM was ~$5,000/MB.
2. **Transistors are free.** Modern ARM Cortex-A72 has billions of transistors. GC and type dispatch cost nothing because the transistors are there whether used or not.
3. **Complexity saturates human verification.** Systems are tens of millions of lines. Testing is necessary but insufficient — zero-day vulnerabilities prove bugs survive all testing. Formal verification is the only known path.
4. **Cost of failure exceeds cost of verification.** A single breach costs millions. Regulation mandates provable compliance. Proving correctness is cheaper than not proving it.
The [[file:verification-appliance.org][verification appliance]] (AGPL symbolic engine + RISC-V Lisp μcode on FPGA) costs $5,000/year and replaces $500,000/year in compliance audits, breach litigation, and regulatory fines. This [[file:cost-structure.org][cost structure]] — zero marginal cost per additional user — is what makes Lisp economically viable at scale. The [[file:self-driving-lisp-machine.org][self-driving Lisp Machine]] is the hardware endpoint of this economic logic. For the biological analogy that explains why Lisp architecture is a natural outcome of complexity pressure, see [[file:biology-parallels.org][biology parallels]]. For the historical precedent, see the [[file:comparison-with-symbolics.org][comparison with Symbolics Genera]]. The [[file:ai-industry-impact.org][impact on the AI industry]] is the market-side consequence.

17
ideas/moats.org
View File

@@ -1,17 +0,0 @@
:PROPERTIES:
:ID: aa6d062e-a520-5d14-8773-00687ed9c689
:END:
#+title: Competitive Moats
#+filetags: :passepartout:economics:moats:competition:
Re-evaluated: time is not the primary moat. A Phase 4+ Passepartout fed on Wikipedia + Wikidata can build a general ontology in two weeks. The organic growth advantage collapses for general knowledge.
**Actual moats (weaker than initially assumed):**
1. **Domain-specific gate rules** — thin. A few hundred lines of Lisp data. Write once, trivial to copy. Not a real moat.
2. **Empirical decision history** — every HITL decision is a Merkle fact. A fresh instance has none. Makes *your* instance more valuable but doesn't prevent competition — it's a switching cost, not a barrier to entry.
3. **[[file:evaluation-harness.org][Evaluation harness (regression suite)]]** — thousands of test cases accumulated from every bug fix. Cannot be ingested from public data. Strongest residual moat.
4. **[[file:infrastructure-lock-in.org][Infrastructure integration]]** — specific Docker compose layouts, Traefik patterns, Authentik configs encoded as gate rules. A competitor's infrastructure is different.
**Strongest competitor strategy:** Not copying your gate rules — offering the same architecture as a service with their own pre-seeded general knowledge and a consulting engagement to customize gate rules. The AGPL prevents closing the architecture but does not prevent offering it as a service with a customization layer.
**The defensible business is services, not product.** The defensible entity is "the organization that best understands how to adapt Passepartout to your domain" — not "the organization that owns Passepartout." A [[file:verification-monopoly.org][verification monopoly]] on agent safety would change this calculus — competitors would need independent certification. [[file:patent-strategy.org][Patent strategy]] and [[file:licensing.org][Licensing]] protect key innovations and create revenue from the open-source ecosystem.

128
ideas/neurological-software-empirical-middle.org Normal file
View File

@@ -0,0 +1,128 @@
:PROPERTIES:
:CREATED: [2026-05-25 Mon]
:ID: 4b5c6d7e-8f9a-0b1c-2d3e-4f5a6b7c8d9e
:END:
#+title: Neurological Software in the Empirical Middle
#+filetags: :ideas:passepartout:architecture:world-models:
The empirical middle of the knowledge tree (layers 8-14) is increasingly dominated by neural networks trained on data — not symbolic equations with fitted parameters. ANI, MACE, SchNet for molecular energies and forces. AlphaFold for protein structure prediction. Neural docking scores, learned solvation models, QSAR neural nets, RL-based molecular design agents. These are not traditional empirical models with interpretable parameters. They are learned function approximators with millions of inscrutable weights.
The three-pronged architecture must accommodate them. This note analyzes how.
**What changes when the model is a neural network.**
A traditional empirical model (force field, solvation equation, docking scoring function) has:
- A **symbolic expression** for the relationship between inputs and outputs (E = k_b(r - r_0)² + ...)
- **Interpretable parameters** that correspond to physical quantities (spring constant = 600 kcal/mol/Ų)
- **Known failure modes** from the equation's form (harmonic approximation fails at extreme bond lengths)
A neural network model has:
- A **learned function** with no simple symbolic expression
- **Inscrutable parameters** (weights) that do not correspond to physical quantities
- **Unknown failure modes** — neural networks interpolate well in-distribution and fail unpredictably out-of-distribution
From the architecture's perspective, the critical difference is not that neural networks are harder to verify (they are, but that is a secondary concern). The critical difference is that the provenance information shifts: instead of tracking where a parameter value came from and what it means, you track what the network was trained on, what it was validated against, and whether the current input resembles its training distribution.
**The provenance store handles the shift by tracking three things instead of one.**
A traditional empirical model's provenance entry:
```
Model: AMBER ff14SB
Equation: Harmonic bond + harmonic angle + Fourier torsion + LJ + Coulomb
Parameters:
- k_b(C-C): 600 kcal/mol/Ų, source: Cornell et al. (1995), validated: 50+ small molecules
- r_0(C-C): 1.525 Å, source: Cornell et al. (1995), validated: 50+ small molecules
- ...
Validity envelope:
- Temperature: 273-373K
- Solvents: water, methanol, ethanol
- Molecule classes: proteins, nucleic acids
```
A neural network model's provenance entry:
```
Model: ANI-2x
Architecture: Ensemble of 8 evidential ANI networks
Parameters: ~8 million weights — not interpretable individually
Training data:
- Level of theory: ωB97M-D3(BJ)/def2-TZVPPD (DFT)
- Molecules: ~8 million conformations from 63,000 organic molecules
- Elements: H, C, N, O, S, F, Cl, Br
- Conformational coverage: ANI-2x conformational space (RDKit + stochastic sampling)
Validation benchmarks:
- COMP6 benchmark (drug-like molecules): MAE 1.2 kcal/mol
- Dihedral profiles: MAE 0.8 kcal/mol
- Isomerization energies: MAE 0.9 kcal/mol
Validity envelope (domain check):
- Elements: H, C, N, O, S, F, Cl, Br only
- Atomic charge range: not validated for charged species outside training distribution
- Conformational novelty flag: activated if RMSD to nearest training point > threshold
```
The structure is the same: model → training/validation data → domain of applicability. The content differs: traditional models have interpretable parameters with experimental sources; neural networks have training dataset provenance and aggregated validation benchmarks.
**The gate checks the same things regardless of model type.**
The gate predicates for model validity are:
1. **Does the model support the elements/atoms/molecule types in the current input?** — This is the same check for a force field (does the force field have parameters for this atom type?) and a neural network (was this element in the training data?).
2. **Are the conditions within the model's validated range?** — Temperature, pressure, solvent, etc. Same predicate, same structure. The neural network's validated range may be narrower or less well-defined, but the check is the same.
3. **Is the input within the model's training/validation distribution?** — For traditional models, this is a direct validity envelope check. For neural networks, this is a **distribution match** — a statistical check that the current molecular conformation resembles the training set. If the input is far from the training distribution in latent space, the gate flags it regardless of whether the model predicts confidently.
The distribution match check is the new machinery that neural network models require. It is a standard technique in reliable ML (distance to training data, density estimation in latent space, conformal prediction). It integrates into the gate as a predicate: "input is within training distribution: PASS" or "input is outside training distribution: FLAG with confidence reduction."
**The symbolic engine does not need to understand the network.**
This is the key simplification. The symbolic engine — ACL2, the gate predicates, the formal reasoning — does not need to parse the neural network's weights or architecture. It needs to:
- Query the provenance store for the model's training data description
- Compute a distribution match score for the current input against the training data
- Compare the result to a threshold from the validity envelope
- Output: pass, flag, or block
None of these operations require understanding what the network does. They are metadata operations on the provenance store and geometric operations on the input space. The network itself is a black box — the symbolic engine treats it as a function with a known domain of applicability, the same way it treats a force field as a function with a known validity envelope.
**The oracle handles model selection.**
Which model to use for a given problem — traditional force field or learned neural network? The LLM oracle handles this, informed by the provenance store. The store tells the LLM what models are available, what they are validated for, and how they perform on relevant benchmarks. The LLM recommends. The gate checks the recommendation against the validity envelope before execution.
This is where the architecture connects to the real world of model selection that computational scientists face daily. There is no single best force field or neural network architecture for all problems. The choice depends on the molecule class, the property of interest, the required accuracy, and the computational budget. The LLM, with its broad knowledge of the literature, is well-suited to making this recommendation — not by reasoning about the models from first principles, but by knowing which models are preferred for which use cases from training data.
**The full picture: three kinds of empirical model.**
The provenance store now handles three data types:
| Model type | Example | Parameters | Validation method | Gate check |
|---|---|---|---|---|
| Symbolic equation + fitted parameters | AMBER force field | Interpretable (spring constants, partial charges) | Per-parameter: source experiment, confidence interval | Validity envelope: temperature, solvent, molecule class |
| Trained neural network | ANI-2x | Inscrutable (8M weights) | Per-dataset: benchmark MAE, held-out test set | Distribution match: is input like training data? |
| Hybrid (learned correction to symbolic model) | Δ-ML corrections to DFT | Partially interpretable corrections + network weights | Per-benchmark + per-component | Both envelope + distribution match |
All three are handled by the same provenance store, the same gate predicates, and the same LLM oracle. The only new infrastructure required is the **distribution match check** for neural network models — a piece of statistical machinery that computes how similar the current input is to the model's training distribution.
**Where this fits in the stage plan.**
- **Stage 0-1**: The provenance store does not exist. Neural network models are loaded as black boxes with no systematic validity checking. This is current practice in computational science — the user is responsible for knowing whether a model applies to their problem.
- **Stage 2**: The provenance store begins operation. Initially it handles traditional symbolic-fitted models because they have clear provenance chains and validity envelopes. Neural network models require the distribution match infrastructure, which is a separate development track.
- **Stage 3**: The distribution match infrastructure is operational. The gate can check whether an input is within a neural network's training distribution. The provenance store holds training dataset descriptions, validation benchmarks, and distribution summary statistics for each supported neural network model.
- **Stage 4+**: Neural network models are loaded into the same address space as the symbolic engine and the provenance store. The distribution match check runs at the level of the evaluation loop itself. The gate's validity check becomes a fast native predicate — no querying a separate data store, just reading a hash table and computing a distance in the same process.
**The summary.**
Neural network models trained on empirical data are not a problem for the three-pronged architecture. They fit into the existing framework:
- **The provenance store** tracks training data sources, validation benchmarks, and distribution statistics — instead of parameter sources and confidence intervals.
- **The gate** checks domain match and training distribution coverage — instead of validity envelopes and parameter regimes.
- **The symbolic engine** does not need to understand the network — it treats it as a black box with a known domain, the same way it treats a force field.
- **The LLM oracle** handles model selection — recommending which neural network or traditional model fits the user's problem, informed by the provenance store's benchmark records.
The new infrastructure required is not large — a distribution match function and a training dataset descriptor in the provenance store. Everything else is existing mechanism applied to a new data type.

74
ideas/open-source-wolfram-lisp.org Normal file
View File

@@ -0,0 +1,74 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
:END:
#+title: Viability of an Open-Source Wolfram Language / Mathematica in Common Lisp
#+filetags: :ideas:lisp:mathematics:open-source:
An assessment of what it would take to build a viable open-source equivalent of Wolfram Language and Mathematica in Common Lisp, based on the existing ecosystem and the fundamental architectural alignment between Lisp and symbolic computation.
**The alignment is natural, not forced.**
Wolfram Language is, at its core, a term-rewriting system with pattern matching, rule-based transformation, and a uniform symbolic representation for everything (expressions are trees of the form head[arg1, arg2, ...] — the Wolfram equivalent of cons cells). This is very close to what Lisp is natively. A Lisp implementation of the core evaluator — pattern matching, rule application, substitution, term rewriting — is not a foreign port. It is an exercise in expressing Wolfram's semantics in a language whose semantics were designed for the same problem domain.
Maxima proves this historically. It is a direct descendant of Macsyma, the MIT computer algebra system that inspired Mathematica. Macsyma was written in Lisp. Mathematica's core evaluation model inherits heavily from Macsyma. An open-source Common Lisp computer algebra system already exists, has existed for decades, and works. The question is not whether it can be done, but how much of the modern Mathematica ecosystem can be replicated and at what cost.
**What already exists.**
| Layer | Existing CL work | Status |
|---|---|---|
| Symbolic engine / term rewriting | Lisp readers, pattern matching libs (trivia, optima, fare-matcher), rule systems | Foundational primitives exist, no unified Wolfram-equivalent evaluator |
| Computer algebra system | Maxima, FriCAS (Axiom), reduce-algebra | Mature CASes — Maxima alone has differentiation, integration, ODEs, linear algebra, tensors, series, limits, Laplace transforms |
| Numerical computing | magicl, lla (Lisp Linear Algebra), CL-NUM, GSLL (GNU Scientific Library bindings) | Solid — covers BLAS, LAPACK, random numbers, special functions, optimization |
| Visualization | cl-cairo2, Vecto, CLG, CommonQt, cl-zxing | Exists but scattered — no unified plotting framework like Mathematica's |
| Notebook interface | cl-jupyter, common-lisp-jupyter, Lem | Jupyter kernel works. Lem is a native editor approaching notebook capability. No Mathematica-level notebook yet. |
| Rule-based programming | fare-matcher, optima, prolog implementations | Pattern matching is good. Full term-rewriting system needs assembly. |
| Knowledge graph | gbrain, various triplestore libs | Possible but would need Wolfram Alpha-level investment |
| Deployment | ASDF, Quicklisp, SBCL standalone executables | Better than Mathematica's deployment story — Lisp produces real executables |
**The hard parts.**
1. **The standard library is the product, not the engine.** Mathematica ships thousands of built-in functions — every mathematical special function, every statistical distribution, every graph algorithm, every image processing filter, every string operation, every data format parser. This is not a technical challenge; it is a sheer volume problem. The open-source answer is to wrap existing C/C++ libraries (GSL for special functions, OpenCV for image processing, igraph for graph algorithms, etc.) and expose them through a unified symbolic interface. This is the Clasp approach: interop with mature C++ libraries rather than rebuilding everything from scratch in Lisp. The Wolfram equivalent would be a CLOS-based symbolic dispatch layer that wraps these libraries and makes them accessible through a consistent term-rewriting evaluator.
2. **The notebook interface is a product in itself.** Mathematica's notebook is not a terminal with nice formatting. It is a computational notebook with inline typeset math, dynamic graphics, collapsible sections, live evaluation, and a rich document model. The Jupyter ecosystem solves half of this. A Lisp-native notebook would need a rendering engine for mathematical notation (LaTeX or MathJax integration), inline interactive graphics, and a document model compatible with literate computation. Lem is the most promising starting point — it already has Emacs-like extensibility, a GTK frontend, and a Lisp-native codebase. Extending Lem to support computational notebooks with inline graphics and typeset output is the shortest path.
3. **Performance for specialized domains.** Mathematica's kernel is highly optimized for symbolic operations — pattern matching over large expressions, automatic algorithm selection, memoization, and incremental compilation. A naive Lisp implementation would match Mathematica for small-to-medium expressions but would need significant optimization work for the heavy cases (symbolic integration of large expressions, graph operations on million-node graphs, image processing pipelines). The advantage is that Lisp's compiler infrastructure (SBCL's type inference, VOPs, inlining) gives a much better baseline than most languages. SBCL can generate code that approaches C speed for numerical kernels.
4. **The knowledge graph (Wolfram Alpha).** Mathematica's integration with Wolfram Alpha — querying computable data about chemistry, geography, finance, linguistics, etc. — is a separate product with a massive engineering investment in data curation. An open-source equivalent would not replicate this. It would either provide a local, user-curatable knowledge base (gbrain fits here) or integrate with existing open knowledge graphs (Wikidata, DBpedia). The gbrain connection is interesting: if Passepartout's knowledge store can answer factual queries with provenance, that becomes the Wolfram Alpha equivalent for the Lisp Mathematica.
5. **Package ecosystem and community.** Mathematica's advantage is not just its engine but its ecosystem — thousands of paclets, the Wolfram Function Repository, the community that shares notebooks. An open-source equivalent needs a package manager (Quicklisp solves this for Lisp libraries), a repository for symbolic packages (a Wolfram Function Repository equivalent), and a critical mass of users who both use and contribute. Maxima has users but not contributors. The gap is community formation, not technical capability.
**The viability assessment.**
| Domain | Viability | Timeline estimate | Risk |
|---|---|---|---|
| Core symbolic evaluator | High — Lisp was designed for this | 6-12 months for working prototype | Low — well-understood problem |
| Computer algebra | High — Maxima already exists | Integrate now; polish 1-2 years | Low — needs UI/UX investment |
| Numerical computing | High — wrappers exist | 3-6 months for unified interface | Low — wrapping problem |
| Visualization | Medium — scattered pieces | 1-2 years for unified framework | Medium — needs new work |
| Notebook interface | Medium — Lem as foundation | 1-2 years to Mathematica parity | Medium — significant UX engineering |
| Standard library breadth | Low — volume problem | 3-5 years with community | High — needs sustained contribution |
| Knowledge graph | Low — curation cost | 2-3 years for basic integration | High — different product category |
| Deployment | High — Lisp executables | Works now | None |
**The strategic question.**
The real question is not "can we replicate Mathematica in Lisp" but "should we?" — and if so, for whom.
Mathematica serves two distinct use cases:
- **Interactive exploration** — a researcher types an integral, gets a result, visualizes it, iterates. Lisp + Maxima + a good notebook interface already does this, and the experience is competitive for anyone comfortable with Lisp syntax.
- **Deployed computation** — a company builds a production pipeline around Mathematica kernels, deploying computation as a service. Lisp executables are dramatically better here — they are real compiled binaries, not managed by a proprietary kernel, deployable without license fees, embeddable anywhere.
For the second use case, the open-source Lisp alternative is already superior. The gap is the first use case: the interactive exploration experience, the breadth of built-in functions, and the cultural acceptance of Lisp syntax in communities that currently write Wolfram Language.
The most viable path is not to clone Mathematica but to integrate Maxima + numerical Lisp libraries under a unified symbolic interface, expose all of it through a Lem-based notebook, and make the Jupyter bridge the primary entry point for users who prefer Python notebooks. This gives you 80% of Mathematica's capability with a fraction of the development cost, and it connects to the existing scientific Python ecosystem rather than competing with it.
**The deeper point.**
Mathematica's architecture is Lisp-like because it was inspired by a Lisp system (Macsyma). An open-source Mathematica in Lisp is not a port. It is a return to the original architectural vision, implemented in the language that vision was originally expressed in. The question is whether the community investment materializes — and that depends on whether there is a use case that justifies it. Passepartout's verification infrastructure may be that use case: a verified symbolic computation engine that reasons about its own results is a Mathematica-like system by necessity, and building it in Lisp is the natural path.
---
- [[id:f4e5d6c7-b8a9-0c1d-2e3f-4a5b6c7d8e9f][Schafmeister and Clasp]] — Lisp in computational nanotechnology, existence proof for Lisp viability in scientific computing
- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Passepartout Architecture]] — why Lisp and where the symbolic engine fits

30
ideas/orders-of-magnitude-time.org Normal file
View File

@@ -0,0 +1,30 @@
#+title: Orders of Magnitude — Time
#+filetags: :passepartout:framework:time:scale:hierarchy:
:PROPERTIES:
:ID: 2cdca4b0-6b41-44b4-acb0-af21d0e27b00
:ID: orders-of-magnitude-time
:CREATED: [2026-05-23 Sat]
:END:
Time at human scales is best thought of in orders of magnitude, not linear progression. Each jump in scale is qualitatively different — the constraints, the tools, the feedback loops, and the failure modes change entirely.
The hierarchy:
| Scale | What fits | Feedback | Failure mode |
|-------|-----------|----------|--------------|
| Minutes | Firefighting, ops, real-time decisions | Instant | Burnout, whiplash |
| Hours | Work session, meeting, focused task | Same day | Interruption cascade |
| Days | Shippable thing, momentum building | Next day | Drift, distraction |
| Weeks | Sprint, feature, market pulse | One cycle | Wrong direction |
| Months | Product cycle, hiring, traction | One data point | Bleeding out slow |
| Years | Company, [[id:aa6d062e-a520-5d14-8773-00687ed9c689][moats]], technology shifts | Scarce | Irrelevance |
| Generations | Culture, regulation, infrastructure | Post-founding | Irreversibility |
Practical use:
When planning anything, identify which order of magnitude you're operating in — then use the tools and cadence appropriate to that scale, not the one below or above it. A minutes problem solved with a weeks solution is overengineering; a years problem approached with days thinking is naive.
Common mistake: treating a months/years problem as if it can be solved in days/weeks (startup hype, premature optimization) or a minutes problem as if it deserves weeks of deliberation (analysis paralysis, bikeshedding).
The [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Time estimates]] page applies this framework to [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]]'s development timeline.

92
ideas/passepartout-bootstrap-mathematica.org Normal file
View File

@@ -0,0 +1,92 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 8b9c0d1e-2f3a-4b5c-6d7e-8f9a0b1c2d3e
:END:
#+title: Could Passepartout Bootstrap Mathematica or mathlib by Itself?
#+filetags: :ideas:lisp:passepartout:mathematics:
This extends the previous viability analysis with a specific scenario: assuming Passepartout exists at Stage 3+ (full Lisp machine with neurosymbolic engine, verification gate, and self-modification capability), how hard would it be for it to recreate Mathematica or mathlib in pure Common Lisp on its own?
**The bootstrap is architectural, not aspirational.**
The neurosymbolic engine is not just a faster way to write code. It is a closed loop: the LLM proposes implementations, the symbolic engine and ACL2 prover verify correctness, and the self-modification system hot-reloads the result into the running image. This loop runs autonomously, without human intervention. The system writes code, tests it formally, improves it, and keeps the result — permanently expanding its own capability.
This is fundamentally different from a human writing Mathematica. A human writes code, compiles, tests, debugs. Passepartout writes code, has it verified against a formal specification, and loads it into its own runtime. The iteration speed is not hours or days — it is seconds per function, limited only by the LLM's generation latency and the prover's checking time.
**What Passepartout already has.**
At Stage 3, the system ships with:
- A symbolic term-rewriting engine (the evaluator itself is one)
- Pattern matching and rule-based transformation (native to the gate architecture)
- ACL2 as a verification backend (can prove properties of generated code)
- An LLM oracle for proposing implementations (the probabilistic brain)
- A self-modification system (hot-reloads verified code into the running image)
- A knowledge store with persistent facts (gbrain-derived)
These are not general-purpose tools that happen to be useful for symbolic mathematics. They are the same tools that a computer algebra system needs, expressed in the same architecture. The evaluator that rewrites a gate policy is the same mechanism that rewrites a symbolic expression.
**What it needs to generate.**
| Component | Can Passepartout generate it? | How |
|---|---|---|
| Core symbolic evaluator | Yes, trivially — this is what Lisp *is* | The existing evaluator already does term rewriting. The neurosymbolic engine would create a higher-level pattern-matching layer over it. |
| Computer algebra (differentiation, integration, simplification) | Yes — known algorithms, formally specifiable | LLM proposes implementation of Risch algorithm, polynomial GCD, Gröbner bases. ACL2 verifies the specification. |
| Numerical libraries (BLAS, special functions, optimization) | Partial — better to wrap | ACL2 cannot verify floating-point numerics to the same standard. Passepartout would wrap existing C/C++ libraries via Clasp-style interop and verify the interface, not the numerics. |
| Visualization framework | Yes — UI code, not math | The environment subsystem (Nyxt/Lish) already has rendering primitives. The neurosymbolic engine generates plotting and graphics code against them. |
| The 5,000+ function standard library | Yes — volume, not novelty | This is the dominant cost. Each function is individually trivial (differentiate x^3 → 3x^2) but there are thousands. Passepartout generates them at LLM speed — roughly one function every 10-30 seconds including verification. |
| Formal proofs of mathematical theorems (mathlib) | Qualified yes — different logic | mathlib is in Lean's dependent type theory. Passepartout's ACL2 is first-order logic. The theorems can be re-proven in ACL2, but the proofs are not portable. The LLM proposes proof strategies, ACL2 checks them. |
**The rate limit is generation, not computation.**
If Passepartout generates one verified function every 20 seconds (conservative — LLM proposal time + ACL2 verification), that is 180 functions per hour, ~4,300 per day. Mathematica's standard library contains roughly 6,000 documented functions. At this rate, the standard library would take ~1.5 days of continuous generation — assuming the LLM has the domain knowledge to produce correct implementations and ACL2 can verify them.
This is the critical assumption. The LLM (at, say, GPT-4 or DeepSeek level) already knows what every Mathematica function does. It has seen them in training data. The question is whether it can generate a correct Lisp implementation with a formal specification that ACL2 can verify. For most elementary functions (differentiate, integrate polynomial, singular value decomposition, string split, image histogram), the answer is yes — these are well-understood algorithms with clear specifications.
For specialized domains (elliptic curve cryptography, tensor network contractions, symbolic regression of differential equations), the LLM may generate approximately correct implementations that need refinement. The neurosymbolic loop handles this: ACL2 catches the mismatch, feeds the error back, and the LLM regenerates.
**mathlib is a different problem.**
mathlib is not a library of algorithms but a library of formal proofs — mathematical theorems expressed in Lean's dependent type theory, structured as a hierarchy of definitions, lemmas, and tactics. It represents hundreds of person-years of community effort, formalizing undergraduate mathematics and beyond.
Passepartout's verification layer is ACL2, which operates in a different logical framework (first-order logic with induction for total functions, not dependent types). There is no porting mathlib — it would have to be re-proven in ACL2's logic.
The advantage is that the theorems are already known. mathlib tells you exactly what to prove. The LLM reads the Lean statement, translates it to an ACL2 theorem, proposes a proof strategy, and ACL2 attempts the proof. This is a well-structured task for the neurosymbolic loop: the LLM generates proof plans, ACL2 verifies them, and failed attempts feed back to refine the next plan.
The bootstrapping advantage: early proofs (basic arithmetic, set theory) strengthen the ACL2 reasoning library, which makes later proofs (real analysis, topology) faster. The system accelerates as it goes. mathlib's proof dependency graph is the natural generation order.
Estimated timeline for mathlib-equivalent in ACL2, with Passepartout generating autonomously:
| Milestone | Time estimate | Note |
|---|---|---|
| Basic arithmetic, algebra, number theory | Days — standard library material | Well-known proofs, simple structure |
| Real analysis, measure theory | Weeks — proof complexity increases | Non-trivial but well-studied |
| Abstract algebra (groups, rings, fields) | Weeks — structural, builds on itself | The neurosymbolic loop excels here |
| Topology, algebraic topology | Months — conceptual depth | Proofs are longer, more strategic |
| Category theory, homological algebra | Months — abstraction barrier | High-level abstraction, fewer verification primitives |
| Number theory deep results (FLT, modular forms) | Unknown — research frontier | Passepartout is not proving open problems. It formalizes known results. |
**The bootstrapping compound effect.**
The most interesting property is not that Passepartout can generate Mathematica's library. It is that each generated function becomes part of Passepartout's own capability. After generating the differentiation function, Passepartout uses it to generate the integration function. After generating linear algebra, it uses that to generate optimization algorithms. After generating formal proofs of real analysis, it uses those theorems to verify more complex deductions.
This is not a production pipeline. It is an autodidactic loop: the system generates math, then uses that math to generate more math. The acceleration is exponential in the early phases and linear in the later phases, limited by the rate at which the LLM can produce new correct specifications.
**The real barrier is not technical but oracular.**
At every step, Passepartout depends on the LLM's knowledge of existing mathematics. The LLM has seen most of human mathematical knowledge in its training data. It can propose correct implementations and proof strategies because it has seen them. But for genuinely new mathematics — theorems not present in the training data, algorithms that have not been discovered — the LLM has no signal. Passepartout would be limited by its oracle.
Stage 7 acknowledges this: oracular limits are fundamental. The verification subsystem can check correctness against a specification, but it cannot generate the specification itself. The LLM provides the what; ACL2 verifies the that. Neither provides the why that extends beyond existing knowledge.
**Conclusion.**
Recreating Mathematica's standard library: **days to weeks** of autonomous generation. The volume problem is solvable because the LLM already knows the answer space and ACL2 can verify each function. No human intervention required.
Recreating mathlib's formal proof corpus: **months** of continuous formalization. The neurosymbolic loop maps naturally onto the task of converting known theorems from one logical framework to another. The dependency graph of mathlib provides the optimal generation order.
Neither requires new research. Both are engineering throughput problems that Passepartout's architecture is designed to solve: generate, verify, reload, repeat. The only hard limit is the oracle — the system cannot generate mathematics that the LLM does not already know exists.
---
- [[id:7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d][Viability of open-source Wolfram/Mathematica in Lisp]] — the human-driven assessment
- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Passepartout Architecture]] — the verification and self-modification systems

1667
ideas/passepartout-economics.org
View File

File diff suppressed because it is too large Load Diff

22
ideas/patent-strategy.org
View File

@@ -1,22 +0,0 @@
:PROPERTIES:
:ID: caaeee11-ba6f-5566-aecd-f171b4c459c0
:END:
#+title: Patent Strategy
#+filetags: :passepartout:ip:patents:legal:
**Likely patentable:**
- Probabilistic-deterministic split with deterministic gates between LLM proposal and execution (vs every competitor using prompt-based guardrails)
- Foveal-peripheral context model with Org-tree structured retrieval (targets 2,000-4,000 tokens)
- Merkle-tree memory with copy-on-write snapshots and operation-level undo/redo
- Gate-to-fact bootstrap with sufficiency criterion (mechanically extracting facts from gate stack data structures)
- Macro-layer-as-skill bootstrapping architecture (theorem-proving as hot-reloadable skills)
**Likely not patentable (known techniques):**
- ACL2 itself (decades old)
- Screamer for consistency checking (obvious application)
- Hot-reloadable skills (40 years old)
- Org-mode as a data format
**Strongest single claim:** The specific combination of probabilistic model + deterministic zero-token safety gates + Merkle memory + symbolic engine with sufficiency criterion. Each element is known; the combination is novel and non-obvious.
**Counterargument:** A patent examiner will argue these are standard OS microkernel architecture, locality of reference, content-addressed storage, and capability-based security applied to an AI agent. The defense: they have never been *combined* in an AI agent, producing emergent effects no single principle produces. These patents would feed into a [[file:licensing.org][licensing]] strategy and create [[file:moats.org][moats]] against competitors.

88
ideas/practical-powers-three-pronged.org Normal file
View File

@@ -0,0 +1,88 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 2f3a4b5c-6d7e-8f9a-0b1c-2d3e4f5a6b7c
:END:
#+title: Practical Powers of the Three-Pronged System
#+filetags: :ideas:passepartout:architecture:
What can Passepartout do with its three layers — deductive proofs, provenance-tracked empirical models, and probabilistic oracle — that a conventional system cannot? This note catalogs the practical powers that fall out of the architecture, not as abstract potential but as concrete capabilities.
**1. It can tell you how wrong every result might be.**
This is the single most important power. Computational science today produces precise-looking numbers with no error bars. A molecular dynamics simulation outputs "binding free energy: −9.2 kcal/mol" and the number looks definitive. It is not. It depends on a chain of models (force field, solvation, sampling, scoring) each with its own uncertainty.
Passepartout traces the chain automatically. It reports: "binding free energy: −9.2 kcal/mol ± 1.4 kcal/mol. Breakdown: force field uncertainty ±0.8 kcal/mol, solvation model ±0.5 kcal/mol, conformational sampling ±0.3 kcal/mol, scoring function ±0.6 kcal/mol. Model validity regime: proteins in water at 298K ± 25K. Your conditions fall within this regime."
No computational chemistry package does this today. Every one outputs a precise number and leaves the uncertainty to the scientist's judgment.
**2. It can prevent you from using a model outside its valid range.**
A force field parameterized for soluble proteins at room temperature gives plausible-looking numbers for a membrane protein at body temperature, but those numbers are not physically meaningful. The simulation runs, produces output, and a human who does not know the force field's history may trust the result.
Passepartout's gate catches this at the check level: "This force field was validated for aqueous solutions of soluble proteins at 273-373K. Your simulation involves a lipid bilayer environment at 310K. Three of the lipid-specific parameters are outside their validated range. Recommendation: use a membrane-specific force field (CHARMM36m) instead. Confidence reduction: 40% if you proceed with current selection."
This is a fundamentally new kind of safety. Not "is this action malicious?" but "is this computation sound?"
**3. It can detect when a model is getting worse.**
Empirical models degrade over time. A force field fitted to 1990s experimental data may be worse than a later version fitted to more data, but there is no automatic mechanism to detect this. A scientist who has been using the same force field for a decade may not realize it has been superseded.
Passepartout tracks every model version. When it processes a new publication with updated parameters, it can compare: "The AMBER ff99 parameters you are using were superseded by ff14SB in 2014 and ff19SB in 2019. The newer parameter sets improve backbone dihedral prediction by 30% for the protein class you are simulating. Migrate to ff19SB?" It does this because every parameter has a timestamp, a source, and a validation record.
**4. It can compare predictions to experiments automatically.**
Every time Passepartout makes a computational prediction and receives (or the user provides) an experimental measurement for the same system, it records the comparison. Over hundreds of comparisons, it builds a systematic bias profile for each model: "This force field consistently underestimates binding affinity for charged ligands by 0.5-1.0 kcal/mol. This solvation model overestimates solubility for aromatic compounds."
These bias profiles are not research papers. They are accumulated operational knowledge that makes future predictions more interpretable. No existing system does this because no existing system treats models as entities with provenance rather than as files on disk.
**5. It can red-team its own reasoning.**
The probabilistic oracle (LLM) proposes a conclusion. The deductive layer (ACL2) checks the formal steps. The provenance layer (empirical knowledge base) checks whether the models used are valid for the context. If all three agree, the conclusion is as reliable as the system can make it. If they disagree, the conflict itself is informative: "The formal mathematics checks out, but the models supporting it are outside their validated range. Your conclusion may be mathematically correct but physically unsupported."
This is a kind of epistemic hygiene that no single-layer system can achieve. A purely probabilistic system (LLM alone) can be confidently wrong. A purely deductive system (prover alone) can only reason within its formal domain. A purely empirical system (database alone) cannot synthesize across domains. The three layers cross-check each other.
**6. It can build a community knowledge graph of what works.**
When multiple Passepartout instances use the same model in different conditions and compare to experimental data, the combined record extends the model's validity envelope. One instance validates a force field for ethanol. Another validates it for DMSO. A third validates it for mixed solvents. The model's validity envelope grows across the network without any single instance having to run all the experiments.
The social protocol becomes the mechanism for this sharing: instances publish validation results as signed, provenance-tracked claims. The network aggregates them. A model that starts with a narrow validity envelope (water, 298K) gradually accumulates enough validation data to cover a wide range of conditions.
No existing scientific software network does this. Journals publish individual validation studies; nobody aggregates them into a living validity map for each model.
**7. It can generate a defensible record for regulatory submission.**
If a pharmaceutical company uses Passepartout in a drug discovery pipeline, every simulation result carries a full provenance chain: force field version and source, solvation model parameters and validation benchmark, conformational sampling algorithm and integrator settings, gate checks that passed, uncertainty budget per component.
This record is essentially a compliance document. It answers the question "how do I know this result is reliable?" with a traceable chain of evidence, not a scientist's assertion. For industries regulated by the FDA, EMA, or similar bodies, this is the difference between a simulation being used for guidance and a simulation being accepted as evidence.
**8. It can be wrong honestly.**
This sounds trivial but it is the hardest thing for software to do. Every scientific software package presents its outputs with equal authority. A result from a high-quality QM calculation and a rough empirical estimate look the same in the output file — just numbers.
Passepartout would output: "This result is deductively proven (ACL2-verified, level 0-7)." or "This result is computationally rigorous within an empirical model (provenance-tracked, level 8-14, validity envelope intact)." or "This result is an extrapolation outside the model's validated range. Confidence is low. Here is what would need to be measured to increase confidence."
Honesty about uncertainty is a power because it changes what you can do with the result. A deductively proven result can be used as a building block for further proofs. An empirical result within its validity envelope can be used for design decisions with known risk. An extrapolation should only be used for hypothesis generation. Passepartout would know which is which and tell you.
**9. It can refuse an unsound instruction.**
Today, if you ask a computational chemistry package to run a simulation, it runs the simulation. It does not check whether the settings are physically meaningful. The error is not caught until a human reviews the output — if they ever do.
Passepartout's gate can say: "I will not run this simulation. The requested temperature (500K) exceeds the force field's validated range (273-373K). The solvent (hexane) has no validated parameters in this force field version. The simulation will produce numerically precise but physically meaningless results. If you want to proceed, I will flag all output as extrapolation with a confidence score of 0.3 out of 1.0."
The power is not that Passepartout prevents the simulation. It is that Passepartout makes the choice explicit: the human can override, but the override is recorded, and the result is tagged with its true reliability rather than appearing to be definitive.
**10. It can connect mathematics to reality without faking it.**
This is the deepest power. A conventional system either stays in the pure formal domain (proof assistants, CAS) or stays in the empirical domain (simulation software, ML). Passepartout bridges them by making the boundary explicit.
A mathematician can prove a theorem (layers 0-3). An engineer can build a bridge using empirical models (layers 8-12). Passepartout can connect the two: "The finite element equations for this bridge are verified against classical mechanics (layer 4). The material parameters come from ASTM standard tests on this specific steel alloy (layer 8-9, validity envelope: −20°C to 60°C, validated by 200+ measurements). The load calculations carry ±3% uncertainty based on material parameter variance." The bridge is not proven safe — no software can prove a physical structure is safe — but the chain from mathematical foundation to empirical measurement is fully transparent.
**Summary: three kinds of power.**
| Layer | What it verifies | What it enables |
|---|---|---|
| Deductive proofs | Correctness against axioms | Autonomous generation of verified algorithms |
| Provenance-tracked models | Implementation fidelity + data source | Scientific integrity, uncertainty budgets, audit trails |
| Probabilistic oracle | N/A (generates hypotheses) | Synthesis, model selection, natural language interface |
Alone, each layer is a tool. Together, they form a system that can reason formally, model empirically, communicate naturally — and tell you which mode is in effect for every result it produces.

48
ideas/schafmeister-clasp-nanotechnology.org Normal file
View File

@@ -0,0 +1,48 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: f4e5d6c7-b8a9-0c1d-2e3f-4a5b6c7d8e9f
:END:
#+title: Christian Schafmeister — Common Lisp in Computational Nanotechnology
#+filetags: :ideas:lisp:nanotechnology:
Christian Schafmeister is a chemistry professor at Temple University in Philadelphia. He created [[https://github.com/clasp-developers/clasp][Clasp]], a Common Lisp implementation that interoperates with C++ libraries using LLVM compilation, specifically to solve a problem most Lisp implementers never face: designing molecules at the nanoscale.
**The problem.**
Schafmeister's research focuses on spiroligomers — large, shape-programmable molecules built from synthetic monomers. These are programmable at the level of both shape and functional groups, meaning they can be designed to bind specific proteins as therapeutics or accelerate chemical reactions the way enzymes do. The goal is to create molecules that can do everything proteins do in nature, but that are designable and evolvable by human beings.
This is a computational problem of enormous complexity. Designing these molecules requires simulating their behavior, computing binding affinities, searching conformational space, and iterating designs rapidly based on experimental feedback. The compute pipelines involved typically live in the C++ ecosystem (a vast array of scientific computing libraries), but the workflow itself — rapid prototyping, interactive exploration, incremental development — demands the kind of environment that C++ alone cannot provide.
**Why Lisp won.**
Schafmeister's argument for Common Lisp in computational nanotechnology mirrors the same reasoning that drives Passepartout's architecture:
- **Interactivity.** Molecular design requires exploration. A researcher needs to load data, inspect it, try a transformation, undo it, try another — all within a live environment. Lisp's REPL-driven development provides this in a way that compile-link-run cycles cannot match.
- **Incremental development.** The design space for spiroligomers is too large to simulate exhaustively. You need to build up models piece by piece, testing each step. Lisp's incremental compilation and hot-reloading make this natural.
- **Unified representation.** In Lisp, the code that describes a molecule and the code that simulates it share the same structure. There is no translation barrier between the design language and the simulation language.
But the scientific computing ecosystem lives in C++. Schafmeister could not afford to rebuild every computational chemistry library from scratch. So he built Clasp: a Common Lisp implementation that compiles to native code via LLVM and interoperates seamlessly with C++. Clasp can call any C++ library natively, and C++ can call back into Lisp. The result is that the entire scientific computing ecosystem becomes available from within a Lisp environment — programmable, interactive, introspectable.
**The architecture.**
Clasp is not a wrapper or a bridge. It is a full Common Lisp implementation where the C++ interoperation is part of the language runtime itself. The clbind library provides declarative bindings — you describe how C++ classes and functions map to Lisp, and Clasp generates the glue code automatically. This is fundamentally different from CFFI-style foreign function interfaces, which require manual marshaling and are inherently fragile.
From the Lisp perspective, a C++ class appears as a CLOS class. You can subclass it, specialize methods on it, inspect its instances. The boundary between Lisp and C++ is transparent to the programmer.
**Funding and validation.**
Clasp has been funded by the Defense Threat Reduction Agency (DTRA), the National Institutes of Health (NIGMS), and the National Science Foundation. These are agencies that fund computational chemistry and materials design, not programming language research. They funded Clasp because it solved a real problem in molecular design that no other approach addressed: making C++-scale scientific computing work within an interactive Lisp environment.
**Relevance to Passepartout.**
Schafmeister's work is existence proof for two of Passepartout's core claims:
1. Lisp is not a niche language for academic AI research or Emacs configuration. It is being used today to design therapeutic molecules that bind proteins, in environments funded by the NIH and NSF. The interactivity and homoiconicity that Passepartout relies on are the same properties that make this work possible.
2. The single-address-space model is not a limitation but an enabling constraint. Clasp proves that you can run C++ libraries inside a Lisp image, not alongside it. The "Lisp machine" is not a retro fantasy — it is a practical architecture being used today for computationally demanding scientific work.
The main difference is direction: Schafmeister brought C++ into Lisp to access the scientific computing ecosystem. Passepartout replaces the C++ scientific computing ecosystem with verified Lisp-native alternatives. The architectural principle — one representation, one address space, no translation boundaries — is the same in both cases.
---
- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Passepartout Architecture]] — why Lisp is the choice for verified infrastructure

16
ideas/stoa.org
View File

@@ -1,16 +0,0 @@
:PROPERTIES:
:ID: c3b3dc41-945f-54e9-84eb-ca014114f1be
:END:
#+title: Stoa — The Porch (Environment)
#+filetags: :passepartout:stoa:editor:browser:hardware:
Stoa is the user environment — a single Lisp image where editor, browser, shell, and agent coexist.
**Roadmap:**
- v2.0.0: Lish editor + Nyxt browser (Stage 1, Qt/WebKit) + Lish shell
- v3.0.0+: Cannibalization — replace Qt with Lisp-native layout, reduce WebKit to pixel-painting, eventually pure-Lisp browser and window management
- v4.0.0: Native inference — llama.cpp FFI in-process, DSL-compiled model architectures, live surgery on cognition
- v5.0.0: Hardware — tagged RISC-V architecture via TinyTapeout, FPGA prototype, hardware GC via dedicated bus master
- v6.0.0: True agency — world models, temporal reasoning, goal persistence across restarts
The architectural principle: Stoa is not a collection of clients connecting to a daemon. The Dispatcher gate stack [[file:verification-appliance.org][verifies every action]] regardless of who initiated it. The distinction between "tool" and "self" dissolves. The ultimate goal is a [[file:self-driving-lisp-machine.org][self-driving Lisp Machine]] running on custom hardware.

17
ideas/time-estimates.org
View File

@@ -1,17 +0,0 @@
:PROPERTIES:
:ID: dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70
:END:
#+title: Development Velocity and Timeline Estimates
#+filetags: :passepartout:economics:development:timeline:velocity:
At the observed velocity (initial TUI through to production readiness in a single session), the agent writes code and the symbolic engine verifies it at a cycle measured in minutes. The bottleneck is not coding speed — it is LLM API latency, ACL2 verification time, and human review of the 5% of edge cases Screamer flags.
**To neurosymbolic maturity (~4,500 lines):** ~80 cycles, 3-5 weeks, ~2-3 hours of human review.
**To [[file:self-driving-lisp-machine.org][self-driving Lisp Machine]] (Logos + Stoa hardware, +~6,000 lines):** ~60 cycles, 2-4 weeks. The microcode must be loaded onto physical hardware and benchmarked, adding seconds per cycle.
**Full Stoa (editor, browser, shell, Qt integration, ~3,500 lines):** ~30 cycles, 2-3 weeks.
**Total from today to full Logos + Stoa + Agora triad:** 3-6 months. Most of that time is spent on design decisions and protocol specification, not on code.
The system writes the code. The human makes architectural decisions and reviews the 5% ambiguous rules. This timeline assumes a rapid [[file:sufficiency-flip.org][sufficiency flip]] for each domain. See [[file:investment-thesis.org][Investment thesis]] for the business case that justifies this approach.

42
ideas/triad-index.org
View File

@@ -1,42 +0,0 @@
:PROPERTIES:
:ID: 1c3ec48b-446c-50d2-b53e-126a81f5143f
:END:
#+title: Passepartout Triad — Knowledge Base
#+filetags: :passepartout:triad:economics:index:
The triad replaces every layer of the modern computing stack with Lisp-native, user-owned, ACL2-verified alternatives. Three components:
- [[file:triad-overview.org][Logos (Passepartout) — the cognitive agent]]
- [[file:stoa.org][Stoa (The Porch) — the environment]]
- [[file:agora.org][Agora (The Society) — the network]]
Total addressable market: ~$960B/year across cloud, AI, OS, social media, payments, productivity, and compliance.
The business model is the AWS of provable computing: AGPL infrastructure is free, revenue comes from verification appliances, gate rules, certification, namespace registry, hosted PDS, and a compute marketplace. Network effects are positive sum — every instance feeds the regression suite and grows the marketplace.
[[file:lisp-machine-security.org][Lisp Machine security — unified memory threat model]]
[[file:common-logic-iso-24707.org][Common Logic (ISO 24707) — relevance to the triad]]
[[file:collective-regression-suite.org][Collective regression suite — how it compounds]]
Key analytical frames:
- [[file:investment-thesis.org][Investment thesis — the unified view]]
- [[file:lisp-economics.org][Why Lisp is economically viable now]]
- [[file:sufficiency-flip.org][The per-domain sufficiency flip]]
- [[file:time-estimates.org][Development velocity and timeline estimates]]
- [[file:cost-structure.org][Cost structure and zero marginal cost]]
- [[file:moats.org][Competitive moats analysis]]
Revenue paths (short to long term):
- [[file:verification-appliance.org][Verification appliance]][[file:domain-gate-packages.org][ Domain gate packages]][[file:evaluation-harness.org][ Evaluation harness]]
- [[file:agora-usernames.org][Agora premium usernames]][[file:pds-as-a-service.org][ PDS as a service]][[file:compute-marketplace.org][ Compute marketplace]]
- [[file:verification-monopoly.org][Verification monopoly — the big money]][[file:infrastructure-lock-in.org][ Infrastructure lock-in]]
Strategy and IP:
- [[file:patent-strategy.org][Patent strategy]][[file:licensing.org][ Licensing (AGPL + commercial)]]
- [[file:ai-industry-impact.org][Impact on the AI/GPU industry]]
- [[file:upgrade-lifecycle.org][Upgrade and distribution lifecycle]]
- [[file:gate-rule-encoding.org][Gate rule encoding from codified domains]]
- [[file:biology-parallels.org][Biology as proof of the Lisp model]]
- [[file:comparison-with-symbolics.org][Comparison with Symbolics Genera]]
*The lines that run the modern internet (tens of millions across Google, Meta, Amazon, Apple, Microsoft) are replaced by a single coherent architecture where one gate stack verifies everything and one prover proves everything consistent.*

15
ideas/triad-overview.org
View File

@@ -1,15 +0,0 @@
:PROPERTIES:
:ID: a1fac32a-47de-5fbd-b67d-29152c851747
:END:
#+title: Triad Overview — Logos, Stoa, Agora
#+filetags: :passepartout:triad:architecture:
The full triad is a self-bootstrapping replacement for the entire computing stack, not a single product.
**Logos (Passepartout)** — The mind. Cognitive agent combining a probabilistic LLM (10% of work) with a deterministic symbolic engine (80%) at near-zero marginal cost. Gate stack, fact store, ACL2 prover, Screamer constraint solver.
**Stoa (The Porch)** — The body. Editor (Lish), browser (Nyxt), shell (Lish), Org-mode filesystem, Qt/EQL5 UI. A single Lisp image where everything coexists. Roadmap: v2.0.0 (Qt/WebKit) → v6.0.0 (pure Lisp, hardware).
**Agora (The Society)** — The network. Self-sovereign DID identity, DIDComm encrypted messaging, [[file:pds-as-a-service.org][Personal Data Store]], Relay Network, [[file:compute-marketplace.org][compute marketplace]], liquid democracy.
All three speak plists. All three operate in Lisp address space. All three are verified by the same ACL2 prover. The gate stack that verifies a shell command also verifies a DIDComm message. See [[file:investment-thesis.org][The investment thesis]] for the economic rationale and [[file:verification-appliance.org][Verification appliance]] for the hardware that enables this unified architecture.

14
ideas/verification-appliance.org
View File

@@ -1,14 +0,0 @@
:PROPERTIES:
:ID: 84a537b4-4256-50c8-91f5-dd5b4538418f
:END:
#+title: Verification Appliance (Hardware)
#+filetags: :passepartout:revenue:hardware:fpga:tenstorrent:
An FPGA or Tenstorrent card pre-loaded with a mature Passepartout image, [[file:domain-gate-packages.org][domain-specific gate rules]], and a hardware root of trust. No cloud dependency.
**Target:** regulated industries needing [[file:evaluation-harness.org][provable compliance]] that cannot accept cloud-based AI.
**Price:** $5K-$50K/unit. **Volume:** hundreds to low thousands in year one.
The [[file:self-driving-lisp-machine.org][Lisp Machine]] on Tenstorrent P150 (~72 RISC-V Tensix cores on a PCIe card) is the realistic first target: the microcode is RISC-V assembly (software), not FPGA bitstream (hardware). The system can propose, load, test, and roll back a new dispatch routine in seconds. An FPGA path would add synthesis time (minutes to hours per iteration). This hardware-first approach embodies [[file:lisp-economics.org][Lisp economics]] — verification hardware has near-zero marginal cost. The [[file:upgrade-lifecycle.org][Upgrade lifecycle]] for the appliance is managed via signed firmware updates with Merkle snapshots.
Revenue estimate: 50 sales in year one = $250K-$2.5M.

15
ideas/verification-monopoly.org
View File

@@ -1,15 +0,0 @@
:PROPERTIES:
:ID: 827bc546-e887-5b7c-9b65-6392beaf0920
:END:
#+title: The Verification Monopoly (UL for AI)
#+filetags: :passepartout:economics:monopoly:certification:big-money:
The accumulated regression suite — thousands of edge cases from every deployed instance, every bug fix, every regulatory change — becomes the most comprehensive test of autonomous agent correctness ever assembled.
Any organization claiming a "safe AI agent" needs Passepartout certification to prove it. This is Underwriters Laboratory for AI — a certification nobody can ignore.
**Revenue:** licensing the certification mark to every AI vendor that ships an agent. **Margins:** near-100% once the suite exists.
This is the venture-scale outcome. It depends on the [[file:evaluation-harness.org][evaluation harness]] reaching critical mass, which depends on enough instances deploying the software to accumulate edge cases in the regression suite. The [[file:investment-thesis.org][investment thesis]] is built on the recognition that every deployed instance makes this more valuable.
The unique structural advantage: every free instance of the triad feeds the regression suite. The more people use the free software, the more valuable the certification monopoly becomes. Positive sum. This creates deep [[file:infrastructure-lock-in.org][infrastructure lock-in]] and powerful [[file:moats.org][moats]] — a competitor cannot replicate the certification without the accumulated history. The ultimate impact is a transformation of the entire [[file:ai-industry-impact.org][AI industry]], where safety certification becomes a prerequisite for market access.

82
ideas/wider-implications-three-pronged.org Normal file
View File

@@ -0,0 +1,82 @@
:PROPERTIES:
:CREATED: [2026-05-25 Mon]
:ID: 5c6d7e8f-9a0b-1c2d-3e4f-5a6b7c8d9e0f
:END:
#+title: Wider Practical Implications of the Three-Pronged System
#+filetags: :ideas:passepartout:implications:
Beyond Passepartout itself, the three-pronged model — deductive proofs, provenance-tracked empirical models, and probabilistic oracle, all under one gate — has implications for how computation is trusted, regulated, and used across every domain that relies on simulation or AI.
**1. The end of the trust-the-tool default.**
Today, if you run a molecular dynamics simulation in AMBER or a finite element analysis in ANSYS, you trust the result because the tool is widely used. "Everyone uses this software" is the epistemic warrant. The three-pronged system replaces this with an explicit chain: this equation was verified against classical mechanics, these parameters come from a specific experimental paper, this validity envelope covers the conditions you specified. The trust moves from "the tool is popular" to "the chain is traceable."
The implication: a less popular tool with good provenance becomes more trustworthy than an industry-standard tool with none. This changes the competitive dynamics of scientific software — the lock-in shifts from ecosystem size to provenance quality.
**2. AI safety as an architectural constraint, not a training target.**
Current AI safety is probabilistic. We train models not to lie, not to harm, not to be biased. The training is never perfect, the guardrails can be jailbroken, and every new model generation requires retraining the safety layer.
The three-pronged system offers a structural alternative: the LLM can propose anything, but the gate enforces what is actually executed. The LLM cannot write a file, send a message, or run a command — it can only propose. The gate decides. The safety is in the gate's predicates, not in the LLM's training.
The implication: safety becomes provable. You can verify that a gate predicate is correct (it blocks rm -rf / for all inputs). You cannot verify that a trained model is honest. This is the difference between "we hope the AI behaves well" and "the AI physically cannot execute a disallowed action."
**3. Regulatory science with defensible evidence chains.**
Pharmaceutical, aerospace, and medical device companies spend billions on computational simulations that regulators review. Currently, the review relies on the submitting company's assertion that the simulation was run correctly. The provenance chain is in lab notebooks and internal documents, not in the output itself.
A three-pronged system produces outputs with built-in defensibility: every parameter has a source, every approximation is tagged, every gate check is recorded, every uncertainty is budgeted. A regulator can read the output and see: "the force field was parameterized against these 50 experimental measurements, the DFT calculation used this functional and basis set, the validity envelope covers the conditions of interest, the total uncertainty is ±X."
The implication: regulatory review shifts from auditing the company's process to auditing the computation's chain. This is faster, more transparent, and less dependent on the reviewer's expertise in every specific tool.
**4. The reproducibility crisis has a technical solution.**
A major cause of the reproducibility crisis in computational science is incomplete specification of methods. "We used the AMBER force field" is not enough — which version? which parameter set? which cutoff scheme? which solvation model? Which experimental validation was it based on?
The three-pronged system's provenance chain is a complete specification by construction. Every computation is fully described by its model, its parameters, its validity envelope, and its gate checks. Reproducing the computation is a matter of loading the same provenance chain and running it.
The implication: computational reproducibility shifts from a social norm ("please share your code and parameters") to an automated property of the output. If the output does not carry a full provenance chain, it is not fully specified.
**5. Engineering safety margins become explicit.**
Every engineered structure — bridge, aircraft, medical implant — is designed using simulation. The safety margins are specified in standards (factor of 2, factor of 5, etc.) but the actual uncertainty in the simulation is rarely quantified. A civil engineer running a finite element analysis of a bridge does not know the combined uncertainty of the material model, the mesh resolution, the boundary conditions, and the load assumptions.
The three-pronged system would propagate uncertainty through the entire design chain. The output would include: "the failure probability under maximum load is 0.03%, with the following breakdown: material parameter uncertainty contributes 0.02%, mesh discretization contributes 0.005%, load modeling contributes 0.005%."
The implication: safety margins in standards can be replaced or supplemented by model-specific uncertainty budgets. A design with low uncertainty can use a smaller safety factor; a design with high uncertainty must use a larger one. This saves material and weight where the simulation is reliable, and forces conservatism where it is not — the opposite of today's one-size-fits-all approach.
**6. Education in how knowledge works.**
Current STEM education teaches equations and methods. Students learn to compute binding affinities, solve differential equations, run simulations. What they do not systematically learn is the difference between a proven result, a validated model prediction, and a reasonable guess.
A three-pronged system, used in education, would make this distinction visible for every computation. A student simulating a chemical reaction would see: "this reaction barrier was computed at the CCSD(T) level of theory with a complete basis set extrapolation — this is the gold standard in quantum chemistry and is well within the formal domain. The solvation correction uses an implicit solvent model validated against 200 experimental free energies of solvation for neutral organic molecules — this is an empirical model with known accuracy of ±0.5 kcal/mol. The conformational search used a genetic algorithm that may not have found the global minimum — this is a heuristic with no guaranteed completeness."
The implication: students develop epistemic hygiene as a side effect of using the system, not as a graduate-level skill acquired through years of trial and error.
**7. The economics of computational trust.**
Not all computations are equally valuable. A result that is deductively proven can be used as a building block for further proofs — its truth is inherited by any derivation that uses it. A result that is empirically validated is useful for decisions with known risk, but cannot be used as a deductive foundation. A result that is an LLM extrapolation is useful only for hypothesis generation.
The three-pronged system makes this distinction explicit, which has economic implications. A pharmaceutical company might pay more for a binding affinity prediction that carries a full provenance chain and uncertainty budget than for one that is just a number. A patent application based on a proven result is stronger than one based on a simulated one.
The implication: computational results become differentiated products, not interchangeable commodities. The provenance quality is the differentiator.
**8. The social protocol as a scientific knowledge commons.**
When multiple Passepartout instances share validated model parameters through the social protocol, the network accumulates a collective knowledge base that no single instance could build alone. A force field validated by one group for water, another for ethanol, another for DMSO — all shared with full provenance — becomes a model whose validity envelope has been extended across many conditions by distributed effort.
The implication: the social protocol is not just a communication mechanism. It is an infrastructure for distributed scientific knowledge curation. The network effect is not just more users; it is more validated knowledge.
**9. The gate as a universal integrity layer.**
The gate currently checks security and scientific validity. There is no reason it could not check other dimensions of integrity: ethical constraints (do not simulate chemical warfare agents), legal constraints (do not export restricted technology), economic constraints (do not run a compute job that exceeds the user's budget), or institutional constraints (only use models approved by the lab's review board).
The implication: the gate becomes a **configurable integrity layer** that enforces any policy that can be expressed as a predicate over the computation's inputs, models, and parameters. Different users, institutions, or jurisdictions can configure different gate policies without changing anything else in the system. Compliance becomes configuration.
**10. The shift from "what does the software do?" to "how does the system know what it knows?"**
This is the deepest implication. Most software today answers "what does this program output?" The three-pronged system answers "how does the system know that this output is reliable?" — by checking which domain it was produced in, tracing the provenance chain, and reporting the uncertainty budget.
This changes the fundamental question users ask of software. Instead of "is this tool well-regarded?" they ask "is this result proven, validated, or generated?" — and get a different answer for every specific result, not a blanket trust judgment about the tool.
The implication: computation becomes epistemically transparent. The system does not ask the user to trust it. It shows the user what it knows and how it knows it, and lets the user decide what to do with that information.

116
ideas/world-models-middle-domain.org Normal file
View File

@@ -0,0 +1,116 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 0d1e2f3a-4b5c-6d7e-8f9a-0b1c2d3e4f5a
:END:
#+title: The Middle Domain as World Models
#+filetags: :ideas:passepartout:world-models:
The middle of the knowledge tree — layers 8 through 14, from quantum chemistry approximations to molecular design heuristics — corresponds almost exactly to what the AI and robotics communities call world models. Recognizing this connection reveals a structural requirement for Passepartout that the current architecture does not explicitly address.
**What a world model is.**
In the AI sense, a world model is a predictive representation that an agent uses to anticipate the consequences of actions. It answers the question: if I do X, what happens next? The classic formulation decomposes this into:
1. A sensory encoder that compresses observations into a latent state
2. A dynamics predictor that predicts the next latent state given an action
3. A reward or value predictor that evaluates states
Every layer of the knowledge tree from 8 upward fits this description — it predicts how some aspect of reality evolves given initial conditions, parameters, and boundary conditions.
**The deductive world models (layers 0-7).**
Logic, algebra, analysis, classical mechanics, quantum mechanics, statistical mechanics, electrodynamics — these are world models where the dynamics are deductively complete. Given the state (a wavefunction, a phase space point, a metric tensor) and the equations of motion (Schrödinger equation, Hamilton's equations, Maxwell's equations), the time evolution is determined. No parameters to fit. No learning required. The model is provably correct against its axioms.
These are the world models that ACL2 can verify. The prover can confirm that the Schrödinger solver correctly implements the Schrödinger equation for any input. The correctness is total — not statistical, not empirical.
**The empirical world models (layers 8-14).**
Quantum chemistry approximations, molecular mechanics, molecular dynamics, solvation models, docking scoring functions, reaction mechanism models, molecular design heuristics — these are world models where the dynamics are known in form but empirically parameterized. The functional form of the force field (bond stretching + angle bending + torsions + non-bonded) is a modeling choice. The parameters (force constants, equilibrium lengths, partial charges) are fitted to data. The solvation model has a mathematical structure, but its parameters are calibrated against measured solubilities.
These world models cannot be verified against axioms. They can only be validated against experiment. The validation is always provisional — valid for the molecules and conditions tested, uncertain outside that domain.
**The composition is layered world models, not a single one.**
The critical structural insight: the world models are not independent. They form a dependency hierarchy.
A docking prediction (layer 12) depends on:
- A solvation model (layer 11) with its own parameters and validity domain
- A molecular dynamics simulation (layer 10) that samples conformational space
- A force field (layer 9) that predicts energies and forces
- Quantum chemistry calculations (layer 8) that parameterize the force field
- Statistical mechanics (layer 6) that relates ensemble averages to binding free energies
- Classical mechanics (layer 4) that governs the MD integration
Each layer's uncertainty propagates upward. The docking prediction's error is not the scoring function's error in isolation — it is the compound uncertainty of the force field, the solvation model, the conformational sampling, the MD integrator, and the scoring function, all composed.
**The Passepartout world model formula.**
A world model in Passepartout's architecture is a triple:
**World Model = Verified Equations ⊗ Provenance-Tracked Parameters ⊗ Validity Envelope**
- **Verified Equations** — the formal skeleton: the differential equations, the integration scheme, the force field functional form. Verified by the ACL2 prover against the deductive layer below. This is what the gate can definitively check.
- **Provenance-Tracked Parameters** — the numbers that make the model match reality: force constants, partial charges, solvation parameters, scoring weights. Each carries a source (experimental paper, QM calculation, benchmark dataset), a confidence interval, a validity regime (temperature range, molecular class, solvent type), and a last-validation date.
- **Validity Envelope** — the region of input space where the model has been experimentally validated. A force field parameterized for soluble proteins at 298K in water is valid there; applying it to a membrane protein at 350K in ethanol may produce plausible numbers with no physical meaning. The validity envelope is a learned or specified boundary that the gate checks.
**The neurosymbolic engine's role in world models.**
The neurosymbolic split maps onto world model construction and use as follows:
- The **ACL2 prover** verifies the equations — the form of the model, the correctness of the implementation, the composition of multiple world models into a pipeline. This is deductive assurance.
- The **LLM oracle** handles synthesis — selecting which world model to apply to a given problem, interpreting the model's output in natural language, generating hypotheses about why a prediction failed, proposing new parameterizations or model forms when the existing ones are insufficient.
- A **new provenance layer** (described below) handles the third component — tracking parameters, maintaining validity envelopes, propagating uncertainty, and validating predictions against experiment.
**What this changes in the architecture.**
The architecture describes verification (the gate) and knowledge (the memex). World models require a third subsystem: the **empirical knowledge base** — a structured store of fitted parameters, experimental benchmarks, and validity regimes, with full provenance.
The empirical knowledge base would:
1. Store every parameter used by every world model (force field parameters, DFT functional constants, solvation model coefficients, docking scoring weights).
2. Attach provenance to each parameter: the paper, dataset, or calculation it came from, the confidence interval, the validity domain.
3. Track validation history: which experimental measurements have been compared to this model's predictions, with what outcome, and whether the parameters were updated as a result.
4. Enforce validity regimes at the gate level: if a computation applies a model outside its validity envelope, the gate either blocks it (safe default) or flags it with a reduced confidence score.
This is not the same as the symbolic index (which stores formal facts) or the neural index (which stores embedding vectors). It is a third index over empirical knowledge — parameteric, uncertain, and provisional, but no less essential for its lack of deductive certainty.
**The connection to self-improvement.**
The neurosymbolic engine's self-modification capability applies differently to each part of the world model triple:
- **Verifying new equations** (updating the deductive core): the system generates a new algorithm, ACL2 proves it correct against the specification, it is hot-reloaded. This is the Mathematica-bootstrapping scenario — the system improves its own deductive world models autonomously.
- **Updating parameters** (improving the empirical core): the system compares predictions to experimental measurements, detects systematic bias in a force field, and proposes updated parameters. The update is validated by checking whether the new parameters improve predictions on a held-out benchmark. No proof, just statistical improvement. The provenance trail records the change.
- **Expanding the validity envelope** (learning where models work): the system accumulates computational predictions and experimental results, and learns the boundaries where each model is reliable. This is a continuous process, not a one-time formalization.
The self-improvement loop for empirical world models is slower and more uncertain than for deductive ones — it requires experimental feedback, not just formal verification. But it is equally essential for any system that needs to operate in the real physical world rather than inside a closed formal system.
**The test case.**
Schafmeister's spiroligomer pipeline is the test case for all three components:
- The **equations** — QM calculations (layer 8), force field predictions (layer 9), MD integration (layer 10), thermodynamic integration (layer 11), docking (layer 12), design rules (layer 14) — all need verified implementations.
- The **parameters** — force field parameters for novel monomer types, solvation parameters for non-standard solvents, scoring function weights for spiroligomer-protein binding — need provenance and validity envelopes.
- The **validation** — experimental binding assays, catalytic rate measurements, structural characterization (NMR, crystallography) provide the feedback that updates parameter confidence and expands validity regimes.
If Passepartout can handle this pipeline correctly — distinguishing what is verified from what is empirically parameterized, tracking provenance through the composition of multiple world models, and propagating uncertainty from the bottom of the hierarchy to the top — then the architecture is complete. If it cannot, then the architecture only works for pure mathematics.
**Summary.**
| Layer | Type of world model | Verification mode | Key data |
|---|---|---|---|
| 0-7 | Deductive | ACL2 proof against axioms | Theorems, equations, algorithms |
| 8-14 | Empirical | Validation against experiment | Parameters, benchmarks, validity envelopes |
| All | Composed | Provenance + correctness | Traceability through pipeline |
The middle domain is world models. The architecture needs to be built to reflect that.
---
- [[id:9c0d1e2f-3a4b-5c6d-7e8f-9a0b1c2d3e4f][The Middle of the Knowledge Tree]] — the layers from logic to nanotechnology
- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Passepartout Architecture]] — current architecture

88
ideas/world-models-plain-language.org Normal file
View File

@@ -0,0 +1,88 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 1e2f3a4b-5c6d-7e8f-9a0b-1c2d3e4f5a6b
:END:
#+title: What the World Model Idea Means — Plain Language
#+filetags: :ideas:explanation:
An explanation of the world model idea and its implications, written for someone who does not want to parse architectural jargon.
**The basic idea in one sentence.**
Some things you can prove are true (like 2+2=4), and some things you can only model approximately because you have to fit the numbers to real-world measurements (like how strongly a particular molecule bends or twists). Most practically useful knowledge is the second kind.
**The deductive vs. empirical split.**
There is a floor in the building of human knowledge. Below the floor, everything is provable from first principles. This includes:
- Logic (if A implies B and A is true, then B is true)
- Mathematics (calculus, linear algebra, number theory)
- Fundamental physics (Newton's laws, the Schrödinger equation, Maxwell's equations)
In theory, a computer with enough power can prove things at this level. Given the right axioms and enough time, it can derive any true statement. This is what ACL2 does — it proves that a piece of code is correct for all possible inputs.
Above the floor, things change. The equations have a known form (bonds stretch like springs, molecules attract each other at long range and repel at short range), but the precise numbers in those equations have to be fitted to experimental measurements. There is no way to derive a spring constant from first principles — you have to measure it.
This includes:
- Chemistry (how strongly does this bond bend? how fast does this reaction happen?)
- Biology (how tightly does this drug bind to this protein? how fast does this enzyme work?)
- Engineering (how much weight can this beam hold before it cracks?)
- Medicine (does this drug work? what dose is safe?)
- Materials science (how strong is this alloy at high temperature?)
- Climate science, geology, pharmacology, and almost every other applied science
**The critical observation.**
Most of what humans actually care about lives above the floor. Pure mathematics is beautiful and foundational, but nobody builds a bridge, cures a disease, or designs a drug using only proofs from first principles. Every practical domain works with approximate models that are useful but not deductively certain.
Passepartout's verification engine can handle the stuff below the floor. It can prove that a numerical integration routine is correct, that a sorting algorithm works, that an algebraic simplification is valid. But above the floor, "verification" means something different — not "proven correct from axioms" but "the implementation correctly executes the model, and the model's parameters are traceable to experimental data."
**The three parts of a useful computation.**
In the deductive zone (below the floor), every computation has two parts:
1. The algorithm (how you compute it)
2. The verification (the proof that the algorithm is correct)
In the empirical zone (above the floor), every useful computation has three parts:
1. The equations (the known mathematical form of the model)
2. The parameters (the numbers fitted to experimental data)
3. The validity envelope (the range of conditions where the model is reliable)
The equations can be verified — ACL2 can prove that your force field code correctly implements Hooke's law. The parameters cannot be verified; they can only be validated against experimental data. The validity envelope cannot be proven either — it is a learned or declared boundary that says "we checked this model works for these kinds of molecules at these temperatures; outside that range, we don't know."
**What this means for Passepartout.**
**First, the architecture needs three subsystems, not two.**
The neurosymbolic split (probabilistic brain + deterministic prover) only covers the deductive zone. The empirical zone needs a third subsystem — a provenance tracker that stores where every parameter came from, what its confidence interval is, and what range of conditions it has been validated for.
This subsystem does not prove anything. It curates. It ensures that when Passepartout simulates a molecule, every force constant, every partial charge, every solvation parameter has a source that can be checked. If the same parameter was determined by two different experiments with different results, the system can report both and flag the uncertainty.
**Second, the gate gets a new job.**
The gate currently asks "is this action safe?" — should this shell command run, should this file be written, should this network message be sent. With the world model insight, the gate also asks "is this model valid for the context?" — this force field was parameterized for soluble proteins; you are applying it to a membrane protein. The answer may be "block" or "allow with reduced confidence" or "flag for human review."
This is not a security check. It is a scientific integrity check. But it uses the same mechanism — a policy evaluated before the computation proceeds.
**Third, self-improvement splits into two speeds.**
- **Fast loop** (below the floor): Passepartout generates a new algorithm, verifies it with ACL2, and hot-reloads it. This is what the Mathematica-bootstrapping scenario describes — days to generate thousands of provably correct functions. This loop runs autonomously.
- **Slow loop** (above the floor): Passepartout makes a prediction using an empirical model, gets experimental data back (either by performing an experiment or reading a paper), and updates the model's parameters or validity envelope. This loop requires real-world feedback. It cannot run autonomously — it needs data from the physical world.
Both loops matter. The fast loop makes Passepartout mathematically powerful. The slow loop makes it useful for real-world science and engineering.
**What this does not mean.**
This does not mean Passepartout cannot handle empirical science. It means Passepartout handles it differently — with explicit uncertainty, provenance tracking, and validity boundaries, instead of pretending the model is deductively certain.
This is actually a design advantage. Most scientific software treats its parameters as if they were provably correct. Force field databases ship as flat files with no provenance. Passepartout would be the first system that can say: "I am running the AMBER force field. The bond-stretching parameters come from a 1995 paper by Cornell et al., validated against 50 small molecules. The partial charges come from the RESP fitting procedure, applied to HF/6-31G* calculations. The validity envelope covers proteins and nucleic acids in aqueous solution at 273-373K. Your simulation involves a lipid membrane at 350K, which is outside the validated range. The results may be qualitatively correct but the quantitative predictions should be treated with caution."
No existing chemistry software does this. A system that can is more useful than one that cannot, even if the underlying simulation is the same.
**The broader implication.**
The deductive/empirical floor is not a weakness in Passepartout's design. It is a correct description of how knowledge actually works in the physical world. Most systems pretend everything is deductively certain and hide their assumptions. Passepartout would make the assumptions explicit, trace every number to its source, and report uncertainty alongside every result.
This is what it means to build a system that does not lie to you.

8
projects/_index.org Normal file
View File

@@ -0,0 +1,8 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: a0b1c2d3-e4f5-6a7b-8c9d-0e1f2a3b4c5d
:END:
#+title: Projects
#+filetags: :index:
All projects documented in this brain. Each project has its own architecture, strategy, and reference material.

8
projects/flags/_index.org Normal file
View File

@@ -0,0 +1,8 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 1e5f6a7b-8c9d-0e1f-2a3b-4c5d6e7f8a9b
:END:
#+title: Flags — Legal Structures
#+filetags: :index:
Legal structure analysis for the Passepartout project — entity types, jurisdictional considerations, asset protection, practical setup guides.

139
projects/flags/asset-protection-structures.org Normal file
View File

@@ -0,0 +1,139 @@
:PROPERTIES:
:ID: 0a4e0b8f-25e0-4b78-9633-fc37d03cefe9
:ID: asset-protection-structures
:CREATED: [2026-05-23 Sat]
:END:
#+title: Asset Protection & Corporate Structure — Research
#+filetags: :passepartout:legal:corporate:asset-protection:research:
Research on corporate structures for a US-incorporated tech company with offshore holdings. This is preliminary research, not legal advice. Every structure needs a qualified lawyer and accountant to execute.
* The Assets to Protect
Passepartout has three distinct asset classes, each with different protection needs:
1. /IP (verification subsystem):/ [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] codebase, gate rules, ACL2 proof libraries, the [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]]. This is the core defensible IP. Needs to be owned separately from the operating company so that if the operating company is sued, the IP is not reachable.
2. /Platform ([[id:1d074690-a279-59cb-b91d-e9a22ae104ad][the social protocol]]):/ The network itself — user base, reputation graph, contract history, protocol specification.
3. /[[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][Revenue streams]]:/ Enterprise compliance contracts, transaction fees, PDS hosting subscriptions. These flow through the operating company. A judgment against the operating company attaches to the revenue in that entity.
* Common Structures
** Structure A: Standard Delaware C-Corp (no offshore)
- Delaware C-Corp owns everything: IP, platform, operations
- Founders hold common stock
- Investors hold preferred stock
Pros: Simplest, most familiar to investors, standard for venture fundraising
Cons: All assets in one basket. A judgment against the operating company attaches to everything, including the IP. No asset protection beyond the corporate veil (which is thin for a single-member/controlled startup).
Assessment: Fine for Phase 0. Upgrade when revenue exceeds liability risk tolerance.
** Structure B: Delaware C-Corp + Offshore IP Holding Company
- Delaware C-Corp is the operating company (sells verification, runs the social protocol PDS infrastructure)
- A separate IP holding company in BVI, Cayman, or Nevis owns the Passepartout code, gate rules, ACL2 libraries, and the social protocol spec
- The operating company licenses the IP from the holding company at arm's-length royalty rates
- The holding company accumulates IP [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][licensing]] revenue in the offshore jurisdiction
Pros: Strong IP protection — a judgment against the operating company cannot reach the IP (the operating company doesn't own it). Profits from licensing are outside US tax jurisdiction until repatriated.
Cons: US tax reform (TCJA 2017) introduced GILTI (Global Intangible Low-Taxed Income) — this structure is less tax-effective than pre-2017. Transfer pricing documentation required. Increases administrative complexity.
** Structure C: Offshore IP Co + US OpCo + Offshore Trust
- Same as B, but the IP holding company is owned by an irrevocable offshore trust (Cook Islands, Nevis) rather than by the founders directly
- The trust has a corporate trustee and the founders are discretionary beneficiaries
- The trust also owns the founder's equity in the US operating company
Pros: Maximum asset protection. The trust is beyond the reach of US courts (Cook Islands trusts have the strongest asset protection laws — they do not recognize US judgments and require creditors to litigate in Cook Islands under Cook Islands law).
Cons: Complex, expensive to set up and maintain. Many investors are uncomfortable with trust-held equity (loss of control). Triggers PFIC (Passive Foreign Investment Company) tax issues.
** Structure D: Delaware C-Corp + Delaware LLC Series + Offshore
- Delaware C-Corp as parent
- Each business line (verification, social protocol network, [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]], PDS hosting) is a separate Delaware series LLC
- IP held in an offshore company, licensed to each series LLC
- Series LLCs protect assets within each series from liabilities arising in other series
Pros: Good liability separation between business lines. If the social network (the social protocol) generates liability, the verification business assets are in a separate series.
Cons: Series LLC is legally untested in many jurisdictions. Some states don't recognize them. Tax complexity.
* Key Considerations for This Specific Venture
** The IP is the crown jewel
[[id:827bc546-e887-5b7c-9b65-6392beaf0920][The verification monopoly]] /is/ the moat. The ACL2 proof libraries, gate rule library, and regression suite are accumulated over years and cannot be recreated quickly. These must be owned by a separate entity from the operating company. If the operating company is sued, the IP survives.
** The social protocol network is harder to protect**
The social protocol's value is partly in its decentralized architecture (no central entity controls the network) and partly in the code that runs the PDS infrastructure and protocol. The AGPL license means anyone can run the code — the network value is in the user base, not the software. This is a structural asset protection advantage: even if the operating company fails, the network continues.
** Revenue splits suggest separate entities**
Enterprise compliance revenue ($2-12M/year) is high-margin, low-volume, and comes from a small number of customers. Social protocol transaction fees (0.5-2%) are low-margin, high-volume, and come from millions of users.
** Jurisdiction for the IP company**
| Jurisdiction | Asset protection | Tax treatment | Cost | Reputation |
|--------------+-----------------+---------------+------+------------|
| BVI | Strong | No corporate tax, but GILTI limits benefit | Moderate | Standard, well-understood |
| Cayman | Strong | Same as BVI | High | Well-understood by investors |
| Nevis | Very strong | Same as BVI | Moderate | Less common, stronger AP laws |
| Cook Islands | Strongest (no US judgment recognition) | Same as BVI | High | Niche, but gold standard for AP |
For a venture-funded tech company: BVI or Cayman is the standard choice. Cook Islands is overkill unless there is a specific high-risk profile. Nevis is a middle ground.
* Recommended Path
** Phase 0: Delaware C-Corp (simplest, standard)
Single Delaware C-Corp. IP is owned by the corporation. Founders hold common stock. This is what every seed-stage investor expects. The IP protection is minimal (all eggs in one basket), but the liability risk in Phase 0 is also minimal — you have zero revenue, zero users, zero contracts.
Action items for Phase 0:
1. Incorporate in Delaware (legalzoom, clerky, or a startup lawyer)
2. Assign all IP to the corporation via a standard IP assignment agreement from founders
3. Set up standard corporate records (board minutes, cap table)
** Phase 1: Separate IP + OpCo (before significant revenue)
Before enterprise compliance revenue exceeds $5M cumulative or social protocol users exceed 10K, establish the IP holding company structure.
Structure: Delaware C-Corp (OpCo) + BVI IP Co
- OpCo licenses verification IP from BVI Co
- OpCo licenses social protocol IP from BVI Co
- Founders own both entities (same cap table or mirror ownership)
Timing: The IP transfer is a taxable event if the IP has appreciated. Transfer early, when the IP has minimal appraised value (before the verification monopoly exists), to avoid a tax hit.
** Phase 2: Series Separation (when the social protocol has significant users or revenue)
If the social protocol has 100K+ users and payment volume, separate the business lines into different entities under the same parent:
- Verification LLC (verification, enterprise compliance)
- Social Protocol LLC (social network, transactions, PDS hosting)
- Compute LLC (marketplace operations)
- BVI IP Co (owns all IP, licenses to all three)
** Phase 3: Trust Structure (if wealth preservation becomes primary concern)
When the cumulative value justifies the cost and complexity: move the BVI IP Co ownership into an irrevocable offshore trust with the founders as beneficiaries.
* What This Means for the [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][Growth Strategy]]
The institution-first path (enterprise compliance) and the social-first path (social protocol communities) have /different liability profiles/ that push toward different structures:
Enterprise compliance: Higher liability per contract. A single compliance engagement gone wrong could be a $1M+ claim. The IP separation in Phase 1 is /more urgent/ for the verification revenue stream.
Social protocol network: Lower liability per user but higher aggregate surface. Payment processing regulations, content liability, data protection.
The combined strategy (both engines) makes the Phase 1 structure (Delaware OpCo + BVI IP Co) more important rather than less — the diversification of revenue streams also diversifies liability sources, and the IP needs to be protected from /both/.
* References
This is preliminary research. Specific recommendations require a US corporate lawyer (incorporation), an international tax lawyer (offshore structure), and an asset protection specialist (trust/AP structure). The right order: incorporate in Delaware when ready, then hire a lawyer to plan the offshore structure before significant revenue or users accumulate.
- [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][Combined growth strategy]]
- [[id:1bc22b89-d3eb-4f6d-bcfc-2b0c19c8ed8f][Social protocol competitive landscape]]
- [[id:8c7b9812-f8d6-4347-8915-ce8e520b7914][Entry strategy — organized communities]]
- [[id:98364e9d-a8a9-42b7-a9dc-b643fd2ccc4b][Outbound sales compliance framework]]

163
projects/flags/legal-structure-alternatives.org Normal file
View File

@@ -0,0 +1,163 @@
:PROPERTIES:
:ID: 5ac2f037-fc3c-45ac-a6e8-acc20e005cb0
:ID: legal-structure-alternatives
:CREATED: [2026-05-23 Sat]
:END:
#+title: Legal Structure — Alternatives & Refinements
#+filetags: :passepartout:legal:corporate:research:alternatives:
This page explores alternatives and additions to the base structure (Delaware C-Corp + BVI IP Co): Texas vs Delaware, Wyoming DAO LLC, Panama LLC, and trust layering. Each has tradeoffs — some strengthen asset protection, some reduce cost, some add complexity. The right choice depends on the specific business model, risk profile, and timeline.
* Texas vs Delaware for the OpCo
** The Trend
Several prominent companies have redomesticated from Delaware to Texas: Tesla (2024), Oracle, Hewlett Packard Enterprise, Charles Schwab, CBRE. The reasons are cost-driven: Texas franchise tax is based on margin (revenue minus costs, capped), while Delaware's franchise tax is based on authorized shares and can be significantly higher for companies with large authorized share pools.
** Comparison
| Dimension | Delaware | Texas |
|-----------+----------+-------|
| Filing fee | $89 (standard) | $300 |
| Annual franchise tax | $175-225,000 (depends on authorized shares — can be very high for VC-funded corps) | $0 if no Texas revenue. If taxable: 0.375-0.75% of margin (with $1M revenue exemption) |
| Corporate law sophistication | Gold standard. Chancery Court, 100+ years of precedent, specialized corporate judges | Also good. Texas Business Organizations Code (TBOC) is well-developed. Less precedent than Delaware for contested M&A |
| Registered agent | $50-300/year | $50-300/year |
| Investor familiarity | Universal. Every VC/Bank knows Delaware | Less common for venture-backed startups. Some investors require Delaware |
| Court system | Court of Chancery (corporate law specialists, no juries) | Regular state courts with business courts in major counties |
| Flexibility | Extremely flexible charter provisions | Good, but less tested at the edges |
** Analysis for This Venture
Delaware wins /if/ you plan to raise VC. Investors prefer Delaware and some require it. The Chancery Court's expertise in corporate governance disputes and M&A is unmatched.
Texas wins /if/ the plan is to stay bootstrapped with limited equity structure. The annual franchise tax savings can be significant: Delaware charges minimum $175 but can charge $10K+/year for corps with large authorized share pools. Texas charges nothing if your revenue is under $1M or your margin is zero.
For this venture /without VC/: Texas is competitive. The lack of corporate income tax and the franchise tax exemption under $1M revenue mean year 1-2 costs are near zero. Delaware's legal sophistication only matters if you expect governance disputes or M&A, which are unlikely in the early years.
Recommendation: If no VC and staying under $1M revenue in year 1, Texas is a viable alternative to Delaware for the OpCo. The BVI IP Co structure works identically regardless of which state the OpCo is in. Redomestication from Delaware to Texas later is possible but costs a few thousand.
* Wyoming DAO LLC
** What It Is
Wyoming passed HB 185 in 2025 creating the "Decentralized Autonomous Organization Limited Liability Company" (DAO LLC). It's an LLC variant that recognizes decentralized governance — the members vote on-chain (or via cryptographic consensus) rather than through traditional board resolutions. The DAO LLC is a separate legal entity that can hold assets, sign contracts, and sue/be sued — the DAO governance is the decision-making mechanism.
** Relevance to This Venture
The [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][social protocol]]'s governance modules (liquid democracy, Collective Personas, GEM) map /directly/ onto the DAO LLC concept. If a community on the social protocol wants to be a legal entity — own a shared website domain, hold a pooled treasury, sign a contract with a vendor — they could incorporate as a Wyoming DAO LLC. The social protocol's existing governance infrastructure (voting, constitutions, role management) becomes the DAO LLC's management mechanism.
** This Is Not the OpCo or IP Co Structure
The Wyoming DAO LLC is not a replacement for the Delaware/Texas OpCo or the BVI IP Co. It is an offering /for social protocol communities/. The communities themselves become legal entities, not just digital spaces. This creates a product feature:
- Community in the social protocol hits 25 members who pool $5K in dues
- Community clicks "Incorporate as Wyoming DAO LLC"
- The social protocol generates the filing (name, registered agent, governance document mapping)
- The community's voting modules become the LLC's management structure
- The community now holds assets, signs contracts, and has liability protection
** Practical Considerations
Wyoming DAO LLCs are new (2025). Case law is essentially nonexistent. Banks may not open accounts for them. Tax treatment is unclear. But for social protocol communities that need legal entity status, it's the least friction option.
* Panama LLC (Sociedad de Responsabilidad Limitada / SRL)
** What It Is
A Panama LLC — bearer shares, no corporate tax on foreign-source income, no reporting of beneficial owners to the government (private registry), no requirement to file financial statements publicly. Popular for asset protection because Panama has no tax treaty with the US that allows US tax authorities to automatically obtain information (though this changed somewhat under FATCA/CRS).
** As a Replacement for the BVI IP Co
| Dimension | BVI IP Co | Panama LLC |
|-----------+-----------+------------|
| Setup cost | $2,500-8,000 | $2,000-5,000 |
| Annual cost | $1,300-3,100 | $500-1,500 |
| Tax on IP royalties (US perspective) | Same — US taxes the OpCo on a net basis; BVI/Panama tax the IP Co at 0% (foreign-source income) | Same |
| US tax information exchange | Yes — BVI has signed CRS/MCAA. Automatic exchange with US under FATCA Intergovernmental Agreement | Yes — Panama signed CRS and has FATCA IGA. But historically less compliant |
| Banking | BVI banks generally easier to open accounts | Panama banks are under scrutiny after Mossack Fonseca |
| Reputation | Clean — BVI removed from EU greylist 2024 | Stigma from Panama Papers (2016). Some counterparties will ask questions |
| Bearer shares | BVI eliminated bearer shares in 2020 | Panama still allows bearer shares (strong anonymity, but banks reject them) |
** Analysis
Panama is not clearly better than BVI for this structure. The cost is slightly lower but the stigma from the Panama Papers means some US banks and counterparties will scrutinize transactions from Panama more heavily. BVI is the standard choice for a reason — it's well-understood, clean reputation post-greylist removal, and adequate for the IP holding function.
Panama makes sense /only/ if anonymity is the primary goal. For this venture — which may eventually seek regulatory compliance, sell to enterprise CISOs, or onboard institutional investors — anonymity is a liability, not an asset. The BVI route is cleaner.
* Trusts: Jurisdictions and Downsides
** The Trust Types
For asset protection, two types matter:
/Revocable trust:/ The settlor (you) can change or dissolve it. Assets in it are still reachable by creditors. Not useful for asset protection — it's primarily for estate planning.
/Irrevocable trust:/ The settlor gives up control permanently. A trustee manages the assets. The settlor cannot dissolve it. Creditors cannot reach the assets (if set up before the liability arose). This is the asset protection tool.
** Trust Jurisdictions
| Jurisdiction | Strength | Cost | Key Feature | Key Downside |
|-------------+----------+------+-------------+--------------|
| Cook Islands | Strongest | $15-30K setup, $5-10K/yr | /Does not recognize US court judgments/. Creditor must litigate in Cook Islands under Cook Islands law. 1-year statute of limitations. Debtor-friendly fraud rules (proving fraudulent conveyance is very hard). | Distant, expensive, small professional services ecosystem. Trust company availability limited |
| Nevis | Very strong | $10-20K setup, $3-7K/yr | Similar to Cook Islands: no US judgment recognition. Same legal tradition (English common law). Close to US (EST time zone). | Smaller, less established trust industry |
| Belize | Strong | $5-10K setup, $2-4K/yr | Lower cost. Strong confidentiality laws. No mandatory reporting. | Less tested in court. Smaller trust company ecosystem |
| Niue | Strongest on paper | $8-15K setup, $3-5K/yr | Extremely debtor-friendly laws. Shortest statute of limitations (6 months in some cases). | Very small jurisdiction. Tiny trust industry. Reputational risk (some association with dubious schemes) |
| South Dakota (US) | Moderate | $3-8K setup, $2-5K/yr | Strongest US domestic trust law. No state income tax. Dynasty trusts (no rule against perpetuities). Asset protection trust statute. | /US jurisdiction/ — US courts have jurisdiction. Not as strong as Cook Islands for protecting against US creditors |
| Nevada (US) | Moderate | $2-5K setup, $1-3K/yr | Strong US domestic trust law. No state income tax. Shorter statute of limitations for fraudulent conveyance challenges. | Same limitation as South Dakota — US jurisdiction |
** The Key Question: Foreign Trust vs Domestic Trust
The core distinction:
A /foreign/ trust (Cook Islands, Nevis) is offshore from US courts. A US creditor who obtains a judgment against you cannot simply reach the trust assets. They must litigate /again/ in the foreign jurisdiction, under that jurisdiction's debtor-friendly laws. This is a massive practical barrier — few creditors will pay for two lawsuits in two countries.
A /domestic/ trust (South Dakota, Nevada) is under US court jurisdiction. A US creditor can get a court order directly against the trust. The domestic AP trust statutes provide some protection (shorter fraudulent conveyance lookback, higher burden of proof for creditors), but a sufficiently determined creditor can eventually reach the assets.
** The Downsides of an Extremely Strong Structure
/1. Loss of Control./ An irrevocable trust means the assets are gone. You cannot change your mind. You cannot dissolve the trust. You cannot redirect the assets. This is the /price/ of asset protection. If the trust owns the BVI IP Co (which owns the [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] IP), you are a discretionary beneficiary of the trust, not the owner of the IP. The trustee makes decisions about the IP — not you.
/2. Banking and Financing Difficulty./ Banks scrutinize trust-owned structures. The BVI IP Co owned by a Cook Islands trust will require extensive KYC across four layers: you → trust → BVI Co → OpCo. Some US banks will refuse to open accounts. International banking is possible but time-consuming (3-6 months).
/3. Transaction Complexity./ Selling the company becomes harder. A buyer is not acquiring shares from you — they are negotiating with a foreign trustee. Every M&A lawyer will charge extra for this complexity.
/4. Fraudulent Conveyance Risk./ If the trust is set up after a liability has already arisen (or even after a threat of litigation), a court can void the entire structure as a fraudulent conveyance. The structure only protects against /future/ liabilities. Setting it up early (before any revenue, before any contracts, before any users) is essential — but even then, a court could look back if the timing is suspicious.
/5. Cost./ Annual costs of $10-20K for the trust alone, plus the BVI Co and OpCo costs. This is significant before you have revenue.
/6. Perceived Illegitimacy./ Counterparties — especially enterprise CISOs buying verification services — may ask questions about why the company is structured this way. A company that sells trust and verification services should look trustworthy. An extremely aggressive AP structure may undermine that perception.
* The Combined Structure Map
Option A (recommended baseline):
Founders → Delaware OpCo + BVI IP Co (same ownership)
IP owned by BVI Co. OpCo licenses it. Simple, clean, effective for business liability protection.
Option B (founders' personal AP, trust layer):
Founders → Irrevocable Cook Islands Trust → owns BVI IP Co → licenses to Delaware OpCo
Also: Trust is named beneficiary of OpCo equity (this is complex — often structured as a separate trust holding the OpCo shares)
This protects the IP from both /business/ liability (via the OpCo/IP separation) and /personal/ liability (via the trust owning the IP Co). A personal judgment against you cannot reach the trust assets.
Option C (full stack, extreme protection):
Founders → Irrevocable Cook Islands Trust → owns BVI IP Co + owns beneficial interest in Panama LLC
Panama LLC → holds OpCo shares
OpCo uses IP under license from BVI Co
This is the maximum: three layers between any creditor and the IP. But the cost, complexity, and counterparty friction make it appropriate only for very high net worth individuals facing specific litigation risk.
* The Honest Assessment
For the first phase of this venture (pre-revenue, pre-product, zero users), even a plain Delaware C-Corp is overengineering. The BVI IP Co is a modest step that costs a few thousand and protects the most valuable asset (the IP) from potential business liability. It should be set up early.
The trust layer is genuinely unnecessary until one of these triggers:
- You have personal net worth above $2-5M that you want to protect
- The BVI IP Co's IP is appraised at $5M+
- You are in a profession with high personal liability (you're not — you're building software)
- A specific liability event is imminent (lawsuit filed, regulatory action)
Adding the trust earlier /does/ improve protection (the fraudulent conveyance lookback clock starts earlier) but the cost, complexity, and operational friction of running the business through a foreign trust outweigh the benefit at this stage.
* References
- [[id:433236a2-e5ad-41d4-a27e-4682f8bbc207][Practical setup guide — Delaware C-Corp + BVI IP Co]]
- [[id:0a4e0b8f-25e0-4b78-9633-fc37d03cefe9][Asset protection structures overview]]
- [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][Combined growth strategy]]

205
projects/flags/legal-structure-practical-setup.org Normal file
View File

@@ -0,0 +1,205 @@
:PROPERTIES:
:ID: 433236a2-e5ad-41d4-a27e-4682f8bbc207
:ID: legal-structure-practical-setup
:CREATED: [2026-05-23 Sat]
:END:
#+title: Legal Structure — Practical Setup Guide
#+filetags: :passepartout:legal:corporate:setup:action:
Recommended structure: Delaware C-Corp (US OpCo) + BVI Business Company (IP Co). Trust layer deferred until significant personal wealth accumulates. This is a research document — exact costs and forms should be confirmed with a lawyer.
* The Structure
[Founders] → own equity in → [Delaware C-Corp (OpCo)]
│
license to use IP
│
▼
[BVI Business Company (IP Co)]
│
owns the IP assets
([[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] code, gate rules,
ACL2 libraries, [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][social protocol]] protocol
spec, trademarks, domain names)
The OpCo pays the IP Co an arm's-length royalty for the right to use the IP in its business (compliance sales, PDS hosting, marketplace operations). The IP Co accumulates royalty income in a tax-neutral jurisdiction (BVI has 0% corporate tax). The founders own both entities under the same cap table.
* Layer 1: Delaware C-Corp (OpCo)
** What It Is
A Delaware stock corporation — standard C-Corp for tax purposes. The entity that signs contracts, employs people (eventually), earns revenue, and holds liability.
** Paperwork
- /Certificate of Incorporation:/ Filed with Delaware Division of Corporations. Specifies the corporation's name, registered agent, authorized shares, and incorporator.
- /Bylaws:/ Internal governance rules (board structure, meeting procedures, officer roles). Not filed with the state but must exist.
- /Stock issuance:/ Founders purchase common stock via a stock purchase agreement. An 83(b) election must be filed within 30 days if shares are subject to vesting.
- /Initial board resolution:/ Documents the first board meeting (elect officers, authorize stock issuance, approve bank account opening).
** Forms
| Form | Purpose | Where | Cost |
|------+---------+-------+------|
| Certificate of Incorporation | Creates the corporation | Filed with DE Division of Corps | $89 (standard, up to 5K shares). $189 for expedited 24hr processing |
| Franchise Tax Report | Annual filing | DE Division of Corps | $225 minimum/year (based on authorized shares). Can be $175+ for small corps |
| Registered Agent | Accepts legal service in DE | Private service (CSC, Registered Agents Inc, legalzoom) | $50-300/year |
| 83(b) election | Tax treatment of restricted stock | Filed with IRS within 30 days of purchase | $0 (paper filing) |
| IRS SS-4 | Employer ID Number (EIN) | IRS | Free |
| BOI Report | Beneficial Ownership Information | FinCEN | Free (new requirement, 2024) |
** Steps
1. Choose a corporate name (must be unique in Delaware, include "Inc." or "Corp.")
2. Reserve the name (optional, $75, holds for 120 days)
3. Select a registered agent
4. File the Certificate of Incorporation online or by mail
5. Draft bylaws (template from your incorporation service)
6. Issue founder shares and file 83(b) election
7. Apply for EIN (SS-4)
8. Open a US bank account (requires EIN + Certificate of Incorporation)
9. File the BOI report with FinCEN within 90 days of formation
** Timeline
| Step | Time | Note |
|------+------+------|
| Order incorporation | 1-2 hours online | Via legalzoom, clerky, or direct with DE |
| State processing | 24 hours (expedited) to 2 weeks (standard) | |
| EIN from IRS | Same day (phone) to 2 weeks (mail) | Call IRS and get it same-day |
| Bank account | 1-2 weeks | Requires physical presence or remote onboarding |
| Total | 1-3 weeks | Can be done entirely remotely |
** Costs
| Item | One-time | Annual |
|------+----------+--------|
| Certificate of Incorporation (standard) | $89 | — |
| Name reservation (optional) | $75 | — |
| Registered agent | — | $50-300 |
| Franchise tax | — | $175-225 |
| Bylaws (template) | $0-100 | — |
| Total year 1 | $164-264 | $225-525 |
| Total year 2+ | $0 | $225-525 |
Using a formation service like clerky or legalzoom adds $100-300 but includes document templates, registered agent for the first year, and step-by-step guidance.
* Layer 2: BVI IP Co
** What It Is
A BVI Business Company (IBC) incorporated under the BVI Business Companies Act (2004). The entity that owns the IP assets and licenses them to the OpCo. BVI has no corporate tax, no capital gains tax, no withholding tax on dividends or royalties. The BVI is not on the EU blacklist or greylist as of 2026 (it was greylisted 2022-2024 and was removed after reforms).
** Paperwork
- /Memorandum and Articles of Association:/ The constitutional document. Filed with the BVI Registry of Corporate Affairs. Similar to a DE Certificate of Incorporation.
- /Register of Directors:/ Names and addresses of directors. Filed with the BVI Registry. /Not public/ — BVI maintains a private register.
- /Register of Members:/ Shareholder information. Kept at the registered office. Not public.
- /Licence Agreement:/ The agreement between the OpCo and the IP Co granting the OpCo a license to use the IP in exchange for royalty payments. This is the critical document for transfer pricing compliance.
- /Corporate resolutions:/ Appointing directors, issuing shares, authorizing the license agreement.
** Forms and Steps
| Step | Where | Cost | Time |
|------+-------+------+------|
| Choose BVI registered agent | Private service (Harneys, Ogier, Maples, or low-cost providers) | $500-1,500/year | 1 day to choose |
| Due diligence (KYC) | Registered agent requires passport, proof of address, source of funds | $0 | 1-5 days |
| Name approval | BVI Registry | $0 | 1-2 days |
| File M&A + register | BVI Registry via registered agent | $350-750 (govt fee) | 1-3 days |
| Issue shares | Internal | $0 | 1 day |
| Appoint director/officer | Internal | $0 | 1 day |
| Draft IP license agreement | Lawyer | $1,500-5,000 | 1-2 weeks |
| BVI bank account | BVI or international bank | $0-500 (account fees) | 2-6 weeks |
| Total setup | | $2,500-8,000 | 2-5 weeks |
** Annual Costs
| Item | Cost |
|------+------|
| Registered agent fee | $500-1,500 |
| BVI government fee | $450-1,100 (depends on authorized share capital) |
| BVI financial statement filing | $350-500 (simple, no audit required — just a declaration) |
| Total annual | $1,300-3,100 |
** The IP License Agreement
This is the most important document. It must:
1. /Define the IP:/ List every asset being licensed — the Passepartout source code, gate rules, ACL2 proof libraries, social protocol specification, trademarks, domain names, trade secrets.
2. /Set the royalty rate:/ Must be at arm's-length. For software/tech IP, typical royalty rates are 2-10% of gross revenue, depending on how central the IP is to the business. Verification IP is 100% central to the business (the product /is/ the IP) — rates at the higher end are defensible.
3. /Transfer pricing documentation:/ Required under US tax law (IRC Section 482). A transfer pricing study documents that the royalty rate is consistent with what unrelated parties would agree to. Cost: $5,000-15,000 for a professional study. /Alternative:/ Use an industry benchmarking report from a database like RoyaltyStat or ktMINE. The documentation must exist in case of IRS audit.
4. /Territory:/ Global license, exclusive or non-exclusive.
5. /Sub-[[id:67faf52f-9126-50a7-b87e-2bedc610dac7][licensing]]:/ Whether the OpCo can sub-license. Typically no — the IP Co controls sub-licensing.
* Layer 3: Founders' Ownership
Both the OpCo and the IP Co must be owned by the same people to avoid attribution issues.
** Mirror Ownership
- OpCo founders own 100% of OpCo common stock
- Same individuals own 100% of IP Co shares (same percentages)
- Documented in both entities' records
The two entities are related parties. The IRS will scrutinize transactions between them. Mirror ownership is standard and expected — the key is the documentation of the license agreement and the arm's-length royalty.
** Individual Asset Protection
The founders' personal assets are protected by the corporate veil of both entities. This is /not/ the trust-level protection of Structure D — if both entities are owned by the founders directly, a judgment against the founders (personal liability) could reach the shares in both entities. But a judgment against the OpCo (business liability) cannot reach the IP in the IP Co — that's the point.
* Layer 4: Trust (Deferred)
Not set up now. The trust adds $15-30K setup + $5-10K/year and makes investor fundraising nearly impossible. Defer until:
- Personal wealth (across all assets) exceeds $2-5M, /or/
- The IP Co's accumulated value (IP appraisal) exceeds $5M, /or/
- A specific liability risk emerges (lawsuit filed, regulatory investigation)
When the threshold is reached, the structure becomes: Founders → Irrevocable Cook Islands Trust → owns BVI IP Co → licenses to Delaware OpCo.
* Complete Timeline and Cost Summary (Year 1)
| Item | Timeline | One-time | Annual |
|------+----------+----------+--------|
| Delaware C-Corp | Week 1-2 | $200-500 | $225-525 |
| BVI IP Co | Week 2-5 | $2,500-8,000 | $1,300-3,100 |
| IP License Agreement | Week 3-6 | $1,500-5,000 | — |
| Transfer pricing documentation | Week 4-8 | $0-15,000 | $2,000-5,000 (update) |
| US bank account (OpCo) | Week 2-4 | $0 | $0-200 |
| BVI bank account (IP Co) | Week 4-10 | $0-500 | $0-500 |
| Total year 1 | 4-10 weeks | $4,200-29,000 | $1,525-4,325 |
| Total year 2+ | — | $0 | $1,525-4,325 |
The wide range depends on whether you use a DIY formation service ($400 Delware + $2,500 BVI) or a full-service law firm ($5,000 Delaware + $8,000 BVI + $15,000 transfer pricing study).
* What Must Be Done by a Professional
Some things can be DIY'd, some cannot:
| Task | DIY possible? | Recommendation |
|------+---------------|---------------|
| DE Certificate of Incorporation | Yes (clerky, legalzoom, or direct filing) | DIY ($100-300) |
| DE Bylaws | Yes (template available) | DIY or included with service |
| 83(b) election | Yes (one-page IRS form) | DIY |
| BVI incorporation | Via registered agent | Agent handles government filing |
| IP License Agreement | /No/ | Must be a lawyer (transfer pricing + IP specialist) |
| Transfer pricing study | /No/ | Must be a tax professional |
| BVI bank account | Can apply remotely | Some agents offer bank introduction |
* The Bottom Line
Minimum viable setup (DIY Delaware, basic BVI, lawyer for license agreement): ~$5,000 one-time, ~$1,500/year ongoing. Timeline: 4-6 weeks from start to both entities operational.
Full professional setup (law firm for everything + transfer pricing study): ~$25,000 one-time, ~$4,000/year ongoing. Timeline: 6-10 weeks.
The IP transfer must happen /before/ the IP has significant value. Incorporating both entities now (before the first compliance sale) means the IP assigned to the BVI Co has negligible appraised value. Waiting until Phase 1 means the IP may have significant value and the transfer triggers a taxable gain.
* References
- [[id:0a4e0b8f-25e0-4b78-9633-fc37d03cefe9][Asset protection structures — options analysis]]
- [[id:98364e9d-a8a9-42b7-a9dc-b643fd2ccc4b][Outbound sales compliance — data protection law]]
- [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][Combined growth strategy — Passepartout]]

59
projects/passepartout/_index.org Normal file
View File

@@ -0,0 +1,59 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 7a1b2c3d-4e5f-6a7b-8c9d-0e1f2a3b4c5d
:END:
#+title: Passepartout
#+filetags: :index:
**What Passepartout is.**
Passepartout is a project that builds toward a personal computing environment where you own your computation, your data, and your agency — and the architecture proves it, not promises it.
It is a single system that is simultaneously:
- Your editor, browser, shell, and AI agent — not separate programs but a single environment where everything works together because everything shares the same structure.
- Your knowledge base — a living [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][memex]] of everything you read, write, and decide, stored in a format you can read and your machine can read, with no translation layer between them.
- Your gatekeeper — a system that checks every action against your rules before taking it, whether the action comes from you, from the AI, or from the network.
- Your identity and communication protocol — cryptographic identity, encrypted messaging, and provable exchanges between instances.
These are not separate products. They are one project, one architecture, one machine.
**Why it exists.**
The modern computing stack is built from independently built, independently untrusted layers: hardware, firmware, operating system, compilers, runtime, network protocols, applications. Each layer assumes the layers below it are either trusted or someone else's problem. The gaps between layers are where exploits live.
Security is reactive. We find bugs, we patch them, we run antivirus, we monitor logs. The model is probabilistic: "no known vulnerabilities" does not mean none exist, only that none have been found. The patching treadmill has been running for forty years and shows no sign of slowing.
Passepartout asks a different question: what if you eliminated the boundaries between layers instead of trying to secure them? What if the entire stack shared one structure, one verification, one proof — from the rules that authorize an action to the hardware that executes it?
This eliminates entire categories of threats by structural design, not by patching. Memory corruption exploits, compiler backdoors, malware with execution paths that bypass the rules — these are not mitigations you add on top of an unsafe system. They are classes of threat that cannot exist in a system built on this principle.
**What it replaces.**
| Current approach | Passepartout |
|---|---|
| Separate editor, browser, shell, agent — each a different program with different trust assumptions | One environment where all are functions in the same memory space |
| Knowledge stored in a database you cannot inspect | Knowledge stored in a file format you read and edit directly |
| Security through permissions, firewalls, antivirus, audits | Security through a rule system that checks every action before it executes |
| Separate identity systems for every service (Google login, GitHub, Slack) | One cryptographic identity you control |
| Vulnerabilities found and patched reactively | Categories of threat eliminated by architecture |
**How we get there.**
The full system is the destination, but every intermediate stage delivers value on its own. The project is designed as a staged migration from conventional hardware to the full architecture, with no rewrite required between stages. Stage 0 is running today.
**What it means.**
A system built this way shifts computing from an empirical trust model — "this has passed our tests" — to a deductive one: "this is structurally impossible for the following reasons." The downstream effects cascade beyond any single user:
- A company's compliance obligations become a set of rules the system enforces by construction, not a binder of documents an auditor reviews once a year.
- AI safety becomes a rule system between the AI and the actions it can take, not a set of probabilities and guardrails.
- Software certification becomes a shared suite of proofs from every deployed instance — a public attestation that a system behaves as specified.
Passepartout creates a new category: verified infrastructure. Not a safer operating system, not a better AI agent, not another social network — but the foundation beneath all three, built on a principle that the current approach cannot offer: that the system, by its structure, is trustworthy.
---
- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Architecture]] — the system in detail
- [[id:b9fa4b7b-bc61-4d7f-918d-ff687b80f2ba][Systemic Effects]] — what verification cascades into
- [[id:4a1f23b0-abc1-4def-9876-543210abcdef][Staged Roadmap]] — from today to Stage 7

51
projects/passepartout/architecture/_index.org Normal file
View File

@@ -0,0 +1,51 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 5e7f1d2a-3b4c-5d6e-7f8a-9b0c1d2e3f4a
:END:
#+title: Architecture
#+filetags: :passepartout:index:
Architecture overview — narrative introduction, staged build-out, systemic effects, and the analytical frames that justify the design.
[[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Architecture]] — the narrative introduction to the project.
**Staged roadmap:**
| Stage | Delivers | Key cost | Timeline |
|-------+----------+----------+----------|
| [[id:4a1f23b0-abc1-4def-9876-543210abcdef][0 — Now]] | Baseline: conventional computing | Patching treadmill, no deductive guarantees | Today |
| [[id:4a1f23b0-abc2-4def-9876-543210abcdef][1 — Social Protocol]] | Communication integrity, provable DAG | Crypto overhead, key management | Today |
| [[id:4a1f23b0-abc3-4def-9876-543210abcdef][2 — Verification]] | Verified gate, capability auth | Policy formalization burden | Today (limited) |
| [[id:4a1f23b0-abc4-4def-9876-543210abcdef][3 — Lisp Machine]] | Lisp image, Merkle memory, no kernel | Lisp tax, no backward compat, single address space | 2-5yr (soft) / 5-10yr (ASIC) |
| [[id:4a1f23b0-abc5-4def-9876-543210abcdef][4 — Inference]] | In-process LLM, token interception | ~10x compute/RAM/storage | Server now; consumer 3-5yr |
| [[id:4a1f23b0-abc6-4def-9876-543210abcdef][5 — Weights]] | Plist-native weights, weight-level provenance | ~100x GPU / ~2-5x ASIC | GPU hybrid now; ASIC 5-10yr |
| [[id:4a1f23b0-abc7-4def-9876-543210abcdef][6 — Training]] | Verified fine-tuning, neural world model | ~100x fine-tuning only | 3-5yr fine-tuning |
| [[id:4a1f23b0-abc8-4def-9876-543210abcdef][7 — Remaining]] | Physical threats, oracles, speculation, bootstrap axiom | Mitigations are non-computational | Forever |
**Systemic analysis:**
- [[id:b9fa4b7b-bc61-4d7f-918d-ff687b80f2ba][Systemic effects over time]] — how verification cascades across society, economics, and geopolitics
**Key analytical frames:**
- [[id:5961e469-53a3-5f3c-ab72-3c83ef91963f][Investment thesis — the unified view]]
- [[id:9af13fff-9725-542b-93b1-a555bc74ad72][Why Lisp is economically viable now — zero marginal cost]]
- [[id:efc76898-03f7-57ba-923d-35d65da88bb7][The per-domain sufficiency flip]]
- [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Development velocity and timeline estimates]]
- [[id:aa6d062e-a520-5d14-8773-00687ed9c689][Competitive barriers — moats and infrastructure lock-in]]
**Revenue streams:**
Total addressable market: ~$960B/year across cloud, AI, OS, social media, payments, productivity, and compliance. The business model is the AWS of provable computing: AGPL infrastructure is free, revenue comes from verification appliances, gate rules, certification, namespace registry, hosted PDS, and a [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]].
Short to long term:
- [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Verification appliance]] — certified Lisp Machine at scale
- [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][Domain gate packages]] — compliance encoded as gate rules
- [[id:827bc546-e887-5b7c-9b65-6392beaf0920][Evaluation harness / certification monopoly]] — UL for AI
- [[id:1a2b38df-20ba-58ca-ba55-a072be67bd0d][PDS as a service]] — hosted personal data stores
- [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][Compute marketplace]] — verified compute cycles
**Strategy and IP:**
- [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][IP strategy — licensing + patents]]
- [[id:5f55bbe6-d243-5766-8ccf-5c5cc88a6542][Impact on the AI/GPU industry]]
- [[id:29e4dbf3-cf19-589c-8b14-389e8a39d564][Upgrade and distribution lifecycle]]
- [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][Domain gate packages — encoding and products]]
- [[id:2afd9a3c-e96a-54c7-ac77-a05a28065b4b][Biology as proof of the Lisp model]]
- [[id:00ab3a4d-e3de-5605-a67d-12935bb36ab5][Comparison with Symbolics Genera]]

100
projects/passepartout/architecture/architecture.org Normal file
View File

@@ -0,0 +1,100 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 1c3ec48b-446c-50d2-b53e-126a81f5143f
:ID: a1fac32a-47de-5fbd-b67d-29152c851747
:ID: 42c86e6f-4f27-4993-8238-b7bc7d15fb7b
:END:
#+title: Architecture
#+filetags: :passepartout:architecture:
The project index introduces Passepartout as a personal computing environment. This page describes the architecture in detail: the four subsystems, how they compose, how the gate works, how the memex is structured, and why the stack compresses into a single address space.
**The four subsystems, one address space.**
Passepartout is one system built from four subsystems that share one evaluation semantics, one memory graph, and one proof chain:
- **Environment** — the personal computing environment
- **Knowledge** — the unified memex
- **Verification** — the gate
- **Social Protocol** — provable communication between instances
Each is described below.
**The environment: one address space.**
The environment eliminates the layered trust model of a conventional OS by eliminating the layers. Instead of an editor that sends keystrokes through a terminal emulator to a shell that forks processes that read files through a kernel VFS layer — each boundary a potential vulnerability — the environment runs everything in a single Lisp address space. (Lisp is a family of programming languages where code and data share the same representation. This property means the machine can verify what code does and modify itself without restarting. It is the foundation that makes the entire architecture possible.)
The editor is a Lisp function that manipulates text buffers in the evaluated memory graph. The shell is a Lisp read-eval-print loop that compiles to the same evaluator. The browser renders HTML through a Lisp-based rendering engine, not a separate process. The agent runtime invokes Lisp functions, not subprocesses. (The specific implementations that realize this today use Lish for the shell and editor, Nyxt for the browser, and SBCL as the host Lisp — but the architectural principle is uniform semantics in one address space, not these particular packages.)
There is no MMU boundary between components because there are no separate processes. There is no IPC because there is nothing to communicate between. Everything shares the same memory graph. Your editor buffer, your shell history, your agent's state, and your social protocol messages all live in the same evaluated object graph, protected by the same gate, verified by the same prover.
**The knowledge subsystem: Org-mode as unified memex.**
The knowledge subsystem makes a bet that most systems consider too expensive: that humans and machines should share the same file format. That bet is Org-mode.
Most systems separate human-readable notes from machine-readable data. The user writes Markdown. The system stores it, indexes it, searches it. But the system maintains its own internal model — a database, a knowledge graph — disconnected from the Markdown. When the user leaves, the Markdown survives but the model must be reconstructed.
Passepartout refuses this separation. The Org file is not a representation of the data; the Org file IS the data. The same text the user reads and edits is what the system parses and operates on. There is no translation layer between human and machine — no schema, no import/export, no API boundary between what you write and what the system knows.
Sparse tree retrieval makes this efficient at scale. Org-mode's headline hierarchy is a semantic structure the system can query. When the agent needs information about a specific function, it retrieves exactly the subtree under that heading — not the entire file. Context stays lean (2,000 to 4,000 tokens) while the full knowledge base remains accessible through structural retrieval. This is fundamentally different from Markdown, where retrieval is either imprecise (grep) or entire-file (expensive).
The knowledge subsystem maintains two indices over the Org prose:
1. A neural index using vector embeddings for semantic search — the gateway to the full richness of natural language.
2. A symbolic index storing formal assertions about what the prose says — predicates, relations, constraints — each grounded to a specific heading or block.
The prose is always ground truth. Both indices are derived views that can be rebuilt from scratch. Nothing is lost in the indices that was not already in the Org files.
This is what sovereignty means in technical terms: the user owns the data in a format they can access, and the system operates on the data in the same format they own. The format is stable — Org-mode has been in active development since 2003. There is no schema migration, no database upgrade, no vendor lock-in. Your notes survive the system.
**The verification subsystem: the gate.**
The gate is a function that takes (action, context, policy) and returns (permit | deny). Every action passes through it — a shell command from the user, a proposal from the LLM, a message from the network, a file write by a scheduled job. There is no privileged path around the gate. Root is not a concept in the gate model — root is a convention enforced by an OS that the gate replaces.
The gate combines two decision layers:
1. ACL2-verified decision procedures for security-critical checks — access control, message authentication, capability resolution. (ACL2 is a theorem prover and programming language for formal verification. It proves that code behaves correctly for all possible inputs, not just the ones tested.)
2. An LLM for natural-language reasoning — parsing the user's intent, evaluating whether an action falls within policy boundaries that require human judgment.
The LLM layer is probabilistic. The ACL2 layer is deductive. The gate architecture ensures the deductive layer is authoritative where it applies and the probabilistic layer is bounded by it — the LLM cannot overrule a verified denial.
The gate does not depend on OS privilege boundaries because it is in the evaluation loop itself. This is the architectural reason for the Lisp machine: a conventional OS interposes between the gate and the hardware. A Lisp machine eliminates that interposition by making the gate part of the evaluator.
**The social protocol: provable communication.**
The social protocol extends the verified semantics beyond a single machine. It provides:
- Self-sovereign DID identity (every instance has a cryptographic identity it controls)
- DIDComm encrypted messaging (end-to-end encrypted, signed, DAG-tracked)
- Personal data stores (user-owned, gate-controlled)
- Relay network (asynchronous message delivery across trust boundaries)
- Compute marketplace (provision verified compute you rent)
- Liquid democracy (delegable voting over protocol governance)
Every message is signed by the sender's DID, tracked in a content-addressed DAG, and optionally notarized. Communication is provable when you choose it to be — you can prove what you sent, to whom, when, without revealing content.
The social protocol is not a blockchain. DAG-based ordering handles causality; delegable trust replaces proof of work.
**The staged progression.**
The full architecture — gate-verified Lisp machine on custom silicon — is the destination. The staged roadmap describes how each successive replacement eliminates a class of threat:
- Stage 0: Conventional Linux, Python agent (Hermes), SQLite knowledge store (gbrain). The starting point. Zero days exist; patches are manual.
- Stage 1: Message-level authentication via the social protocol. Communication becomes provable.
- Stage 2: The gate operates as a software layer over the host OS. Shell commands, LLM proposals, and network messages all pass through the same decision procedure. Root is eliminated as an attack path.
- Stage 3: The host OS is replaced by a bare-metal Lisp image. One address space, one evaluator, no MMU to attack.
- Stage 4: LLM inference moves into the Lisp process. No API calls across network boundaries. The LLM becomes a function in the same evaluated graph.
- Stage 5: Neural weights stored as plist-native data structures. The gap between symbolic and neural representations closes.
- Stage 6: Verified fine-tuning. Every weight update is gate-checked against policy.
- Stage 7: What remains. Physical theft, electronic warfare, holes in the specification itself, and the fallibility of the LLM oracle. Limits of computation, not of this design.
Each stage is independently useful. Stage 0 is running today. The migration is progressive component swap, not a cut-over.
**Downstream effects.**
When every action is gate-checked, every message is provable, and every computation runs on verified semantics, the security model shifts from empirical to deductive. The downstream effects cascade beyond personal computing:
- **Compliance** becomes executable gate rules instead of annual audits. A SOC 2 report is a gate configuration, not a PDF.
- **AI safety** becomes a verified gate between the LLM and the action stream instead of probabilistic guardrails or RLHF.
- **Software certification** becomes the accumulated regression suite of every deployed instance — the Underwriters Laboratory for AI.
- **Operating systems** become obsolete. The gate replaces the kernel, the address space replaces process isolation, and the verified evaluator replaces the privilege model.

15
ideas/lisp-machine-security.org → projects/passepartout/architecture/lisp-machine-security.org
View File

@@ -1,16 +1,17 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 1c95ce7d-a2db-506a-9608-df68f9ae211b
:END:
#+title: Lisp Machine Security — Unified Memory Threat Model
#+filetags: :passepartout:security:lisp-machine:pmp:isolation:
On a bare metal [[file:self-driving-lisp-machine.org][Lisp Machine]] with a unified Lisp image, the defense-in-depth provided by the OS kernel disappears. The gate stack and the code it protects share a single address space. An attacker who exploits a memory corruption in the browser renderer can modify the gate stack's permission tables, the policy engine's state, or the ACL2 prover's decision output. There is no kernel underneath to catch them.
On a bare metal [[id:13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70][Lisp Machine]] with a unified Lisp image, the defense-in-depth provided by the OS kernel disappears. The gate stack and the code it protects share a single address space. An attacker who exploits a memory corruption in the browser renderer can modify the gate stack's permission tables, the policy engine's state, or the ACL2 prover's decision output. There is no kernel underneath to catch them.
This note analyzes the threat model and proposes a hardware-enforced privilege separation within the single Lisp image.
**The problem**
In the conventional layered model (Linux + SBCL + Passepartout), there is defense in depth. Even if the gate stack has a bug, Linux provides seccomp, namespaces, file permissions, and process isolation as a safety net. If SBCL segfaults, the kernel catches it.
In the conventional layered model (Linux + SBCL + [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]]), there is defense in depth. Even if the gate stack has a bug, Linux provides seccomp, namespaces, file permissions, and process isolation as a safety net. If SBCL segfaults, the kernel catches it.
On a bare metal Lisp Machine, the model collapses:
@@ -21,7 +22,7 @@ Everything (agent, editor, browser, shell, gate stack, ACL2)
The only protection is that the gate stack is verified by ACL2 to be correct. But ACL2 verification is static — it proves properties about source code. At runtime, a memory corruption in the same image invalidates the entire proof. "All defense is symbolic" is exactly right.
**The solution: [[file:verification-appliance.org][hardware-enforced privilege zones]] within the Lisp image**
**The solution: [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware-enforced privilege zones]] within the Lisp image**
RISC-V provides three hardware privilege levels: M-mode (machine), S-mode (supervisor), and U-mode (user). Physical Memory Protection (PMP) enforces access control at the hardware bus level — it cannot be bypassed by software, even by code running in S-mode if configured in M-mode. The key: use these mechanisms to create zones within the shared Lisp address space.
@@ -82,7 +83,7 @@ ACL2 trust problem. ACL2 verifies the gate stack. But ACL2 itself is ~50,000 lin
The conventional Linux approach: TCB is ~28 million lines of C across kernel, drivers, and runtime. Defense in depth from many layers. But each layer adds attack surface.
The Lisp Machine approach: TCB is ~2,500 lines of verified Lisp (M-mode gate core + S-mode gate stack). Attack surface is ~500 lines of ECALL handler. The TCB is roughly 10,000x smaller. This security advantage creates [[file:moats.org][moats]] — a competitor would need to match both the hardware isolation and the verified codebase.
The Lisp Machine approach: TCB is ~2,500 lines of verified Lisp (M-mode gate core + S-mode gate stack). Attack surface is ~500 lines of ECALL handler. The TCB is roughly 10,000x smaller. This security advantage creates [[id:aa6d062e-a520-5d14-8773-00687ed9c689][moats]] — a competitor would need to match both the hardware isolation and the verified codebase.
The fundamental trade: fewer layers, less depth, but each layer is simpler, smaller, and verified. A bug in the ECALL handler is catastrophic. A bug in the Linux kernel might be contained by seccomp or namespaces. The question is which is more likely: a bug in 500 lines of verified Lisp, or a bug in 28 million lines of C that is not contained by the remaining depth?
@@ -92,7 +93,7 @@ But this is a single-point-of-failure architecture. If the ECALL handler holds,
**Gaps in the current design**
None of this is in the architecture documents. The following are not yet specified — these architectural innovations are potential candidates for [[file:patent-strategy.org][patent strategy]]:
None of this is in the architecture documents. The following are not yet specified — these architectural innovations are potential candidates for [[id:caaeee11-ba6f-5566-aecd-f171b4c459c0][patent strategy]]:
1. PMP region layout — exactly what is protected and by which region
2. ECALL handler specification — the exact interface, request types, validation logic, and error handling
@@ -102,4 +103,6 @@ None of this is in the architecture documents. The following are not yet specifi
6. Side-channel mitigation — speculation control, timing attacks
7. ACL2 trust documentation — the bootstrap chain and what it means for the gate stack's verification
8. The boot attestation protocol — how the gate core verifies the gate stack before loading it
9. Zone transition costs — how many cycles does an ECALL take, and does that affect the 10-80-10 ratio
9.
See the [[id:6fe67db6-25bd-4d11-bd1d-b44ec809e858][Social protocol identity specification]] for how user identity, key derivation, and DID management integrate with the gate stack's boot chain and privilege zones.
— how many cycles does an ECALL take, and does that affect the 10-80-10 ratio

10
ideas/native-org-knowledge-base.org → projects/passepartout/architecture/native-org-knowledge-base.org
View File

@@ -7,7 +7,7 @@
** What
Passepartout should be able to use Org-mode files directly as its
[[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] should be able to use Org-mode files directly as its
knowledge base — no pandoc conversion, no markdown intermediary.
Currently gbrain provides vector search + entity linking over markdown,
@@ -76,6 +76,8 @@ The short-term bridge (current) is gbrain with nightly org→md sync.
This is adequate while the gate stack and planner are the priority.
The native org module replaces gbrain entirely once built.
** See also
[[file:../../concepts/compliance-framework-mapping.org][Compliance framework mapping]]
[[file:../../ideas/passepartout-economics.org][Passepartout economics]]
The nightly pipeline uses gbrain to provide hybrid search across the existing
org files. The [[id:36e5b948-e07b-477f-9036-4dfe88254347][compliance framework mapping]] is the largest single
dataset this would serve, and the broader
[[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout economics]] knowledge base demonstrates the value of
native org querying at scale.

7
ideas/self-driving-lisp-machine.org → projects/passepartout/architecture/self-driving-lisp-machine.org
View File

@@ -1,4 +1,5 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70
:END:
#+title: The Self-Driving Lisp Machine
@@ -8,8 +9,8 @@ A Tenstorrent P150 (~72 RISC-V Tensix cores) running Passepartout: 72 RISC-V cor
The self-driving threshold: the system can synthesize and load its own FPGA microcode or Tensix dispatch programs from within the running Lisp image. The system profiles its own gate verification latency, proposes a new microcoded instruction for the hot path, compiles RISC-V assembly from ACL2-verified specifications, loads it via PCIe DMA from within SBCL, benchmarks it — and rolls back if slower.
Every subdomain involved is software — the most codifiable domain. RISC-V ISA, SBCL internals, ACL2 metafunctions, CIC type theory, compiler optimization — all can [[file:sufficiency-flip.org][flip to symbolic sufficiency]] within days to weeks of ingestion.
Every subdomain involved is software — the most codifiable domain. RISC-V ISA, SBCL internals, ACL2 metafunctions, CIC type theory, compiler optimization — all can [[id:efc76898-03f7-57ba-923d-35d65da88bb7][flip to symbolic sufficiency]] within days to weeks of ingestion.
**Timeline:** ~6,000 lines of new code (microcode, PCIe DMA, Tensix management, benchmark harness). ~60 cycles at current velocity. 2-4 weeks. Total from today: 6-10 weeks. See [[file:time-estimates.org][time estimates]] for the velocity model behind these numbers.
**Timeline:** ~6,000 lines of new code (microcode, PCIe DMA, Tensix management, benchmark harness). ~60 cycles at current velocity. 2-4 weeks. Total from today: 6-10 weeks. See [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][time estimates]] for the velocity model behind these numbers.
The Tenstorrent approach is dramatically simpler than FPGA because the microcode is RISC-V assembly (software), not FPGA bitstream (hardware with minutes-per-iteration synthesis). The [[file:lisp-machine-security.org][Lisp Machine security model]] — unified memory, tagged architecture, no MMU — applies directly because the Tensix cores share the same address space. [[file:verification-appliance.org][Verification appliance]] economics apply: a certified Lisp Machine at scale replaces compliance hardware. See [[file:lisp-economics.org][why Lisp is economically viable now]] and [[file:upgrade-lifecycle.org][upgrade lifecycle]] for the economic and deployment foundations.
The Tenstorrent approach is dramatically simpler than FPGA because the microcode is RISC-V assembly (software), not FPGA bitstream (hardware with minutes-per-iteration synthesis). The [[id:1c95ce7d-a2db-506a-9608-df68f9ae211b][Lisp Machine security model]] — unified memory, tagged architecture, no MMU — applies directly because the Tensix cores share the same address space. [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Verification appliance]] economics apply: a certified Lisp Machine at scale replaces compliance hardware. See [[id:9af13fff-9725-542b-93b1-a555bc74ad72][why Lisp is economically viable now]] and [[id:29e4dbf3-cf19-589c-8b14-389e8a39d564][upgrade lifecycle]] for the economic and deployment foundations.

84
projects/passepartout/architecture/stage-0-now.org Normal file
View File

@@ -0,0 +1,84 @@
---
title: Stage 0 — Now (Conventional Computing)
type: reference
tags: :passepartout:roadmap:
created: 2026-05-24
---
← [[id:329a30cd-55fb-496d-a60b-91388c211bba][Passepartout]] → [[id:4a1f23b0-abc2-4def-9876-543210abcdef][Stage 1 — Social Protocol]]
# Stage 0: Now
*Summary: The conventional stack as it exists today. Not a design — the starting point.*
This is the baseline we inherit. Linux on x86, C/Rust toolchain,
web-based applications, GPU compute for AI, TCP/IP networking. Every layer
is independently built and independently untrusted.
The conventional stack spans every layer:
| Layer | Threats |
|-------+---------|
| [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Hardware]] | silicon trojan, rowhammer, speculation side channels (spectre/meltdown), physical theft |
| Firmware | UEFI implants, SMM rootkits, ME backdoor — unaccountable opaque processors |
| OS kernel | privilege escalation, syscall bugs, driver exploits — CVEs weekly |
| Compiler | Ken Thompson's "Trusting Trust" — compiler backdoors invisible at source level |
| Runtime | heap corruption, use-after-free, buffer overflow — the dominant malware vector |
| Network | MITM, TLS state machine bugs, DNS poisoning, routing attacks |
| Application | XSS, SQLi, RCE, dependency chain attacks, supply chain |
| User | phishing, social engineering, credential theft |
| LLM (if present) | jailbreaks, prompt injection (unbounded space), data leakage in outputs, probabilistic unreliability |
**Key property:** Every layer is independent and untrusted. No layer can vouch
for any other. Security is *empirical* — "no bugs found in this release" — not
deductive.
## What is eliminated
Nothing. Every threat that has ever existed in computing exists at Stage 0.
## What does this cost?
- **Patching treadmill** — the industry spends uncountable hours applying CVEs.
Every OS update risks regressions. Security teams are measured by mean time
to detect, not mean time to prevent.
- **Incident response** — breaches are expected, not exceptional. The average
dwell time (attacker inside system before detection) is months.
- **Bug bounties** — a market failure tax: pay researchers to find the bugs
your toolchain inevitably produces.
- **Complexity tax** — every OS, driver, library, and daemon is a potential
entry point. The attack surface is unknowable because no layer can vouch
for any other.
- **No deductive guarantees** — security is empirical. "No bugs found in this
release" does not mean no bugs exist.
Even with all this spending, the system is not provably secure. You can't
audit your way to deductive guarantees on a conventional stack.
## What does this enable?
Everything we have. The entire software ecosystem, all hardware, every network.
The cost and the capability are the same thing — maximum flexibility, minimum
provable trust.
## When is this viable?
Today. This is where we are.
## In practice
We have normalized reactive security because the alternative — building a
provably secure stack — is considered too expensive. Every company of
meaningful size has a security team whose job is to detect when they've been
breached, not to prevent it. The average dwell time is measured in months.
This is treated as normal because the alternative — a provably secure stack —
is seen as prohibitively expensive. This roadmap is the argument that the
provable alternative is not only possible, but the inevitable destination.
The question is not whether to build it, but at what pace.
← [[id:329a30cd-55fb-496d-a60b-91388c211bba][Passepartout]] → [[id:4a1f23b0-abc2-4def-9876-543210abcdef][Stage 1 — Social Protocol]]
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 4a1f23b0-abc1-4def-9876-543210abcdef
:END:

85
projects/passepartout/architecture/stage-1-social-protocol.org Normal file
View File

@@ -0,0 +1,85 @@
---
title: Stage 1 - Social Protocol (In-Transit Integrity)
type: reference
tags: :passepartout:roadmap:social-protocol:
created: 2026-05-24
---
← [[id:4a1f23b0-abc1-4def-9876-543210abcdef][Stage 0 — Now]] → [[id:4a1f23b0-abc3-4def-9876-543210abcdef][Stage 2 — Verification]]
# Stage 1: [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Social Protocol]]
*Summary: Every message is signed, DAG-tracked, and content-addressed.
Communication becomes provable - when you choose it to be.*
## What is added
- DID-based identity per participant (Ed25519 key pairs)
- Message-level authentication via JWE/JWS envelopes
- DAG of content-addressed messages for auditable history
- Channels for directed and broadcast communication
- End-to-end encryption (Double Ratchet, MLS) with perfect forward secrecy
- Ephemeral Notes via `ephemeral_duration` (time-locked encryption, key shedding, mandatory infrastructure GC)
- Off-the-Record (OTR) mode bypassing PDS storage entirely (volatile client memory only, clients prohibited from recording)
- Pseudonymous Personas for deniable identity
- Relays as transient routers (pub/sub model, no long-term storage)
- Onion routing between PDSs for metadata masking
## What is eliminated
- **Message forgery** — every message is signed; you prove the sender
- **Message tampering in transit** — envelopes are authenticated; tampering changes the CID and breaks the chain
- **Impersonation / spoofing** — DID identity keys, not usernames
- **Replay attacks** — nonces and sequence numbers per message
- **MITM on social protocol-mediated channels** — end-to-end signatures; relays need no trust
- **Loss of message history** — DAG is append-only and content-addressed
## What does this cost?
- **Crypto overhead per message** — every message requires signing and verification.
For high-throughput channels, this adds latency and CPU cost
- **DAG storage grows unbounded** — the append-only log never shrinks unless GC
is explicitly designed
- **Key management burden** — DID resolution, key rotation, revocation. Lost keys
mean lost identity. No "reset password" for DIDs
- **No anonymous participation by default** — DIDs tie every message to a
cryptographic identity. Pseudonymity is a Persona choice, not the baseline
## What does this enable?
Provable communication infrastructure. You can prove who said what, when, and
to whom — or choose off-the-record privacy. Every subsequent stage builds on
this DAG: it is the source of truth for evidence, audit, and the accumulated
knowledge that later stages use for falsification.
## When is this viable?
Today. The social protocol is a protocol design that can be deployed on existing networks.
The infrastructure (PDS, Relay, Gateway) runs on conventional [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]].
## In practice
Communication becomes provable - but only when the user chooses. The social protocol's Note
primitive supports the full spectrum: persistent DAG-stored messages for audit
and compliance, ephemeral Notes that self-destruct, and full Off-the-Record
(OTR) mode that bypasses PDS storage entirely.
The user chooses per-channel or per-message: permanent and attributable for
contracts and governance, ephemeral and deniable for private conversation. The
infrastructure enforces each choice - PDS garbage-collects expired CIDs, Relays
drop them from routing tables, clients shed message keys after display. The social protocol
replaces trust with evidence where evidence is wanted; elsewhere it provides
privacy by design.
The social protocol does not secure the endpoint. The machines running social protocol clients can
still be compromised at the OS, compiler, or hardware level. The keys are on
those machines - malware that compromises an endpoint can sign messages using
the endpoint's keys. The messages are authentic; the sender wasn't. The social protocol
carries the authorization; it doesn't evaluate it.
← [[id:4a1f23b0-abc1-4def-9876-543210abcdef][Stage 0 — Now]] → [[id:4a1f23b0-abc3-4def-9876-543210abcdef][Stage 2 — Verification]]
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 4a1f23b0-abc2-4def-9876-543210abcdef
:END:

84
projects/passepartout/architecture/stage-2-verification.org Normal file
View File

@@ -0,0 +1,84 @@
---
title: Stage 2 — Verification Subsystem
type: reference
tags: :passepartout:roadmap:
created: 2026-05-24
---
← [[id:4a1f23b0-abc2-4def-9876-543210abcdef][Stage 1 — Social Protocol]] → [[id:4a1f23b0-abc4-4def-9876-543210abcdef][Stage 3 — Lisp Machine]]
# Stage 2: Verification Subsystem
*Summary: A verified gate evaluates every action against formal policy.
Capability-based authorization. "Root" as an attack target no longer exists.*
## What is added
- [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][ACL2-verified]] gate functions that evaluate every proposed action
- [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][Capability-based authorization]]: every action requires a token, not an identity
- [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][Gate]] checks every action — from user, agent, or external message — against:
- Is the action authorized by policy?
- Does the capability grant this operation?
- Does the action violate any system invariant?
- Decision procedure formalized in ACL2, machine-checked
- Gate runs as a decision layer on the conventional host (Stage 0 [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]])
## What is eliminated
- **Unauthorized actions** — even a fully compromised endpoint cannot perform an
action the gate blocks. The gate is the final arbiter, not the OS or client.
- **Privilege escalation** — no amount of subversion below the gate can grant
capabilities the policy doesn't allow. The gate checks capability tokens,
not caller identity.
- **"Root" as a meaningful attack target** — there is no root in Passepartout. There
are capabilities, and capabilities are checked.
## What does this cost?
- **Verification latency** — every action is checked against policy. Complex
policies add delay
- **Policy formalization burden** — everything must be written explicitly. Gaps
block legitimate actions (false positives) or allow undesirable ones (false
negatives). There is no [[id:4a1f23b0-abc8-4def-9876-543210abcdef][Common Sense]] fallback — the policy cannot rely on
unformalized human intuition. Everything must be written down
- **Capability management complexity** — distributing, revoking, auditing
capabilities is itself security-critical. A leaked capability is
indistinguishable from an authorized action
- **Policy drift** — as the system evolves, the policy must evolve with it.
Out-of-date policy blocks new legitimate uses
- **Proof maintenance** — the gate's decision procedure is verified, but the
policy is not. Each policy change needs new proof
- **The gate runs on untrusted hardware** — if the OS or hardware is
compromised, the gate's guarantees are meaningless. The attacker can skip
the gate or modify its output. Full gate guarantees arrive at Stage 3
## What does this enable?
The system can now say "no" to unauthorized actions even when the endpoint is
fully compromised. Security is no longer dependent on client integrity. This is
the first layer where deductive guarantees enter the picture — but they are
contingent on Stage 3's trust substrate.
## When is this viable?
Today as a software layer on conventional hardware, but with limited guarantees
(the gate itself can be compromised by the host OS). Full power arrives at
Stage 3 when the gate runs on the verified Lisp machine.
## In practice
The gate is the final arbiter, not the OS or the client. But it runs on a
machine it doesn't trust. Users must weigh the benefit (unauthorized actions
blocked) against the operational cost (everything must be explicitly authorized
in policy). For high-stakes environments, the trade-off is worth it. For casual
use, the friction may lead users to bypass the gate.
*Full gate guarantees arrive when Passepartout runs on its own Lisp machine
(Stage 3). Before that, it's a correctness proof running on an untrusted substrate.*
← [[id:4a1f23b0-abc2-4def-9876-543210abcdef][Stage 1 — Social Protocol]] → [[id:4a1f23b0-abc4-4def-9876-543210abcdef][Stage 3 — Lisp Machine]]
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 4a1f23b0-abc3-4def-9876-543210abcdef
:END:

134
projects/passepartout/architecture/stage-3-lisp-machine.org Normal file
View File

@@ -0,0 +1,134 @@
---
title: Stage 3 — Lisp Machine
type: reference
tags: :passepartout:roadmap:
created: 2026-05-24
---
← [[id:4a1f23b0-abc3-4def-9876-543210abcdef][Stage 2 — Verification]] → [[id:4a1f23b0-abc5-4def-9876-543210abcdef][Stage 4 — Inference]]
# Stage 3: Lisp Machine
*Summary: The [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][verified Lisp machine]]. One image, one [[id:1c95ce7d-a2db-506a-9608-df68f9ae211b][memory graph]], one [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][gate stack]].
No kernel, no process boundaries, no memory corruption. The verification subsystem, the environment subsystem, and the social protocol are no longer separate components — they are properties of the same machine.*
## What is added
Passepartout spans three engineering phases that converge on the same architecture:
### Phase A — Software emergence (2-3 years)
The Lisp machine emerges inside a host OS. A single SBCL image absorbs every
user interface into one address space:
- **Lish editor:** a multi-threaded Common Lisp editor via Qt/QML (EQL5).
The agent's system prompt lives in an Org buffer — visible, editable,
hot-reloadable. Org-babel for inline evaluation. The editor IS the daemon.
- **Nyxt browser:** Common Lisp web browser in three erosion stages:
Qt+WebKit → S-expression DOM → pure Lisp layout. Web content is natively
queryable and modifiable as Lisp data structures.
- **Lish shell:** text-stream replaced by plists. Pipe becomes function
composition. Scripts become Lisp functions on memory objects.
- **Emacs migration (three phases):** parasite bridge (v0.4.0) → ELisp
compatibility layer inside CL image → native CL implementations.
- **Minibuffer:** universal command surface — edit files, navigate web,
run Lisp expressions, invoke agent commands.
### Phase B — Cannibalization (3-5 years)
Gradual replacement of every external dependency with native Lisp:
- TCP bridge → internal function call (single SBCL image)
- QML layout → Lisp layout (Yoga FFI as intermediate)
- WebKit → Lisp DOM + Lisp-native layout engine
- Qt widgets → Lisp-native X11/Wayland bindings
- Font rendering → HarfBuzz FFI → Lisp replacement
- Qt event loop → SBCL native thread scheduler
- Linux bootloader → Stage0 Lisp bootstrap (500 bytes hex → self-hosting Lisp)
The system remains usable at every step. Each replacement is a component swap.
### Phase C — [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Hardware]] (5-10 years)
The dual-unit ASIC: one chip, two compute units, one Merkle-verified memory graph:
1. **Symbolic core** — tagged RISC-V (4-8 type tag bits per word, hardware
type checking, single-cycle LISP.CAR/LISP.CDR). Runs gate stack, cognitive
loop, general Lisp evaluation.
2. **Tensor unit** — cons-cell-native matrix compute. Walks the tensor DAG
directly for attention and matmul. No FFI boundary, no GPU mirror.
Prototyping: TinyTapeout (130nm, 8-bit tagged toy) → FPGA core (DE10-Nano,
VexRiscv) → FPGA tensor (Xilinx VU9P, cons-cell matmul) → shuttle (12nm,
tagged RISC-V at 100-300MHz) → ASIC (5nm, both units on die).
Phase migration: parasitic FPGA PCIe card → functional hijacking → driver
cannibalization → self-hosting (Stage0 on bare metal).
Hardware GC: dedicated Scavenger bus master runs GC in parallel with symbolic
and tensor computation. Persistent NVRAM: boot to exactly where you left off.
## What is eliminated
- **Memory corruption entirely** — verified Lisp evaluator, no undefined
behavior. No buffer overflow, use-after-free, type confusion.
- **OS kernel exploitation** — no kernel. Evaluator is the substrate. No
syscalls, no drivers, no MMU to confuse.
- **Compiler backdoors** — Lisp-to-Lisp compilation within the verified
evaluator. [[id:13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70][Ken Thompson's "Trusting Trust"]] is structurally impossible.
- **Malware / viruses / worms** — no "download and execute" path that bypasses
the gate. The evaluator only runs objects in the verified memory graph.
- **Supply chain at binary level** — every object has a Merkle chain to its
origin. A dependency is a pointer, not a file.
- **The subsystem composition problem** — one address space, one
semantics, one proof. The interface between verification, environment, and
protocol is an internal relationship.
## What does this cost?
- **Lisp tax on everything** — verified execution is 2-10x slower than
optimized C on equivalent hardware. Symbolic core is designed to minimize
this; tensor unit sidesteps it for neural compute
- **No backward compatibility** — existing software doesn't run on the Lisp
machine. No Linux binaries, no x86 drivers, no GPU compute stacks (without mirror path)
- **Single address space fragility** — no process isolation. A bug in the
editor can corrupt the browser. One crash radius, one machine
- **Massive engineering investment** — shortest plausible timeline to a usable
software Lisp machine is 2-3 years; ASIC 5-10 years
- **Ecosystem abandonment** — no open-source packages, no shared libraries.
Everything is in the Merkle memory graph or it doesn't exist
## What does this enable?
Deductive security replaces empirical security. Memory bugs — the dominant
attack vector for decades — are structurally eliminated. No more patching for
CVEs. No ASLR, no DEP, no CFI — the class of attacks they mitigate doesn't
exist. Every boot is a fresh verification that the evaluator, memory graph,
and gate stack are intact.
## When is this viable?
- **Software (Phase A+B):** 2-3 years on existing hardware. Single SBCL image,
gate stack, Lish/Nyxt/Lish — usable on a developer workstation today.
- **ASIC (Phase C):** 5-10 years. FPGA prototype within 1-2 years, shuttle
within 3-5, commercial foundry 5-10.
## In practice
Memory bugs — the dominant attack vector for decades — are structurally
eliminated. No more patching for CVEs. No antivirus, no firewall (at the
machine level — network boundaries remain). A Passepartout Lisp machine that
boots correctly will not crash from a memory corruption bug, ever.
But you've given up the entire existing software world. You cannot run Firefox,
Postgres, nginx, Python, or any Linux binary. The machine is a Lisp machine
and everything must be written in Lisp. The practical trade is: absolute
memory safety at the cost of adopting an entirely new computing paradigm.
This is not an upgrade path — it is a replacement.
← [[id:4a1f23b0-abc3-4def-9876-543210abcdef][Stage 2 — Verification]] → [[id:4a1f23b0-abc5-4def-9876-543210abcdef][Stage 4 — Inference]]
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 4a1f23b0-abc4-4def-9876-543210abcdef
:END:

95
projects/passepartout/architecture/stage-4-inference.org Normal file
View File

@@ -0,0 +1,95 @@
---
title: Stage 4 — Inference (In-Process LLM)
type: reference
tags: :passepartout:roadmap:
created: 2026-05-24
---
← [[id:4a1f23b0-abc4-4def-9876-543210abcdef][Stage 3 — Lisp Machine]] → [[id:4a1f23b0-abc6-4def-9876-543210abcdef][Stage 5 — Weights]]
# Stage 4: Inference
*Summary: The LLM runs in-process under the gate. Every token is inspected
during generation. No external API, no separate trust domain.*
## What is added
- CFFI binding to llama.cpp (or pure-Lisp inference engine) — LLM in the same
SBCL image as the agent, editor, and gate
- [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][Gate-level token interception]]: the Dispatcher inspects every partial token
sequence during generation. Trajectories that would produce unauthorized
actions are suppressed mid-stream, not filtered after the fact
- Weights loaded from the Lisp machine's Merkle-verified store as a macro-tag blob (one
tagged Lisp object pointing to flat binary)
- Deterministic inference: same input, same output, same hash — auditable
and replayable
*Two neural components on the same substrate:* Stage 4 hosts the LLM for
generative reasoning and action proposals. The LeCun-type world model (sensory
prediction) joins at Stage 6. Both run on the same tensor unit with the same
plist-native weight architecture and gate-level interception. The LLM proposes
actions to the gate (authorization — binary, deductive). The world model
proposes predictions to the gate (falsification — structural, empirical). The
gate handles both through different procedures.
## What is eliminated
- **LLM as a separate trust domain** — no external server, no API call, no
cloud provider to breach
- **Remote inference model attacks** — the model cannot be swapped without
changing the Merkle hash
- **Prompt injection as an action bypass** — the gate sees partial generation.
A jailbreak that would produce an unauthorized action is caught before the
tokens complete
- **Model integrity ambiguity** — you know exactly which model is running,
at which commit, with which hash
## What does this cost?
- **~10x compute, RAM, and storage** — the gate evaluates semantics at every
token, not just logits. A model running at 50 tok/s natively runs at ~5 tok/s
under gate-level interception
- **GPU/accelerator constraints** — CFFI to GPU libraries is the bottleneck.
Exotic [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]] may not be supported
- **Memory pressure** — the LLM shares the address space with the entire system.
A 70B param model at 4-bit takes ~35GB. At 10x multiplier, effective
conventional-equivalent cost is ~350GB
- **Determinism is double-edged** — auditable but cannot adapt or creatively drift
- **No model parallelism** — Passepartout runs on one machine. Frontier-scale models
may be too large for a single address space
## What does this enable?
Action proposals from the LLM are intercepted by the gate before they reach
the system. The gate authorizes or denies in real time based on policy, not
on trust in the LLM. This eliminates the entire class of "LLM escaped its
sandbox" attacks.
## When is this viable?
- **Server hardware (A100/H100 class, 512GB+ RAM):** today. 5 tok/s on 7B
models is usable for chat
- **Consumer hardware (RTX 5090 class):** 3-5 years
- **On ASIC tensor unit:** the 10x overhead drops closer to 2-5x because the
gate runs on the symbolic core in parallel with inference on the tensor unit
## In practice
The LLM is no longer a black box connected by API. The gate watches every
token as it's generated and can stop any generation trajectory that would
produce an unauthorized action. The model is powerful; the gate is in control.
Chat is noticeably slower — roughly 5 tok/s instead of 50 — but the security
guarantee is structural, not probabilistic. For bulk processing or real-time
applications, the 10x tax may be prohibitive without dedicated acceleration.
The weights are still a verified *blob* — you know the file's hash but can't
prove anything about individual weights. Training provenance is not tracked.
The inference is FFI-mediated, so trust in llama.cpp remains.
← [[id:4a1f23b0-abc4-4def-9876-543210abcdef][Stage 3 — Lisp Machine]] → [[id:4a1f23b0-abc6-4def-9876-543210abcdef][Stage 5 — Weights]]
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 4a1f23b0-abc5-4def-9876-543210abcdef
:END:

88
projects/passepartout/architecture/stage-5-weights.org Normal file
View File

@@ -0,0 +1,88 @@
---
title: Stage 5 — Weights (Plist-Native)
type: reference
tags: :passepartout:roadmap:
created: 2026-05-24
---
← [[id:4a1f23b0-abc5-4def-9876-543210abcdef][Stage 4 — Inference]] → [[id:4a1f23b0-abc7-4def-9876-543210abcdef][Stage 6 — Training]]
# Stage 5: Weights
*Summary: Every weight is a [[id:1c95ce7d-a2db-506a-9608-df68f9ae211b][Lisp object in the Merkle memory graph]]. You can
prove not just that the model file is unmodified, but that this specific
attention head has the weight vector it should have.*
## What is added
- Plist-native weight graph: weights are typed plists structured as a tree of
tensors DAG, not a flat blob
- Structural weight diffs: the response to "which weight changed?" is "layer 17,
head 3, weights 2048-4096 differ by vector V" — not "the blob hash changed"
- Weight provenance chain: the memory graph links each layer to its training
event. A structural property of the weights, not a log entry about them
- No FFI boundary for inference: the tensor unit (or GPU mirror) operates on
Lisp objects directly. The evaluator's verified semantics cover computation
## What is eliminated
- **Sub-tensor granularity tampering** — you can verify individual attention
heads, not just the blob
- **Weight provenance ambiguity** — every weight links to its origin event
- **The FFI inference gap** — inference runs on Lisp data directly. No C/GPU
code outside the evaluator's semantics
## What does this cost?
- **~100x compute, RAM, and storage on conventional [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]] (GPU path).**
A 7B model requiring 4GB as GGUF needs ~400GB as plist-native weights on a
GPU. GPUs are built for flat arrays and SIMT; cons-cell traversal is their
worst case
- **This 100x is GPU-relative, not fundamental.** An ASIC tensor unit with
tagged memory, Merkle hashing in the memory controller, and sparse DAG-
walking matmul closes the gap to 2-5x
- **Two implementation paths:**
1. *GPU path (near-term):* plist-native weights as gold standard for
provenance, GPU-native mirror for compute, Merkle-verifiable loading
protocol. Cost: 100x storage, ~2-3x load-time overhead
2. *ASIC path (destination):* tensor unit speaks cons-cell. No mirror
needed. Cost: 2-5x over GPU for dense matmul
- **GC pressure** — plist-native weights produce enormous GC load. The
Scavenger handles this on ASIC; on GPU path the mirror avoids it
- **Mixed-precision is complex** — 4-bit and 8-bit quantization destroy
pointer structure. Full float32/64 may be the only practical option
## What does this enable?
You can prove exactly what your model is and that it hasn't been modified.
The Merkle chain from training event to individual weight is structural, not
logged. Fine-tuning provenance becomes as verifiable as the code running on
the machine. This is the stage where hardware choice determines practical
viability.
## When is this viable?
- **GPU hybrid path:** today. Works on any Passepartout with a GPU
- **ASIC native path:** 5-10 years (tensor unit on the dual-unit chip)
## In practice
Every individual weight is Merkle-verified, structurally tracked, and computed
within the Lisp evaluator's verified semantics. The FFI trust gap is closed.
Stage 5 is where hardware choice determines practical viability. The GPU path
works today but carries the storage overhead of two representations (plist gold
standard + GPU mirror) and the load-time verification cost. The ASIC path is
the destination — one representation, one chip, no workaround. Most users will
use the GPU path for years before the ASIC becomes available.
Either path is viable. The GPU path can be built today with existing hardware.
The ASIC path is the destination — a single verified chip that doesn't need
the hybrid workaround.
← [[id:4a1f23b0-abc5-4def-9876-543210abcdef][Stage 4 — Inference]] → [[id:4a1f23b0-abc7-4def-9876-543210abcdef][Stage 6 — Training]]
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 4a1f23b0-abc6-4def-9876-543210abcdef
:END:

124
projects/passepartout/architecture/stage-6-training.org Normal file
View File

@@ -0,0 +1,124 @@
---
title: Stage 6 — Training (Verified Fine-Tuning + World Model)
type: reference
tags: :passepartout:roadmap:
created: 2026-05-24
---
← [[id:4a1f23b0-abc6-4def-9876-543210abcdef][Stage 5 — Weights]] → [[id:4a1f23b0-abc8-4def-9876-543210abcdef][Stage 7 — Remaining]]
# Stage 6: Training
*Summary: Verified fine-tuning under the gate. Every example checked for consent.
Every gradient application is a verified state transition. The neural world model
runs in parallel with the LLM for sensory-physical prediction.*
## What is added
### Verified fine-tuning
The training loop is not a script. It is a verified function in the evaluator:
1. Read a training example from the [[id:1c95ce7d-a2db-506a-9608-df68f9ae211b][memory graph]]
2. Check the example's authorization tag against [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][policy]]
3. Compute the gradient
4. Check gradient constraints (permitted weights, bounded LR, scope limits)
5. Apply the update
6. Record the state transition with a Merkle link to the input
### The neural world model (LeCun type)
A second neural network runs on the tensor unit alongside the LLM. It predicts
sensory and physical dynamics — object trajectories, scene evolution, low-level
sensor futures. It shares the same plist-native weight architecture and the
same verified training pipeline:
- **Domain:** physical world prediction (not social — that belongs to the
accumulated knowledge DAG)
- **Training:** imported from conventional [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]]. Pretrain elsewhere,
verify import, fine-tune under gate
- **Gate interaction:** the world model proposes predictions to the gate
("the ball will land at position X"). The gate falsifies predictions against
the accumulated observation DAG after the fact, tracking calibration over
time. This is verification through falsification, not authorization
### The interaction at Stage 6
1. World model predicts sensory outcome: "user will press button in 2 seconds"
2. LLM reasons about the predicted outcome: "if user presses button, C follows"
3. LLM proposes action to gate: "preempt C"
4. Gate checks policy + accumulated knowledge for similar past scenarios
5. Gate authorizes or denies
6. After outcome occurs, gate falsifies world model's prediction against actual
observation, updating calibration score
## What is eliminated
- **Data poisoning** — every training example is authorized before gradient
application. Only data tagged with consent is trainable
- **Unauthorized fine-tuning** — training policy specifies scope (layers, LR,
data tags) and the gate enforces all constraints at every step
- **Malicious checkpoint injection** — no checkpoints. Training is a verified
sequence of continuous state transitions
- **Training-time backdoors** — the optimizer function is verified by hash.
A Trojan optimizer fails the gate check because its identity doesn't match
## What does this cost?
- **~100x slower than conventional fine-tuning** — building on Stage 5's 100x
overhead (GPU path) plus verified gate checks per example. A LoRA fine-tuning
that takes 2 hours natively takes ~200 hours. Doable overnight, not for rapid
iteration
- **Storage per training step** — every Merkle-tracked state transition adds
to the memory graph. A fine-tuning run could produce hundreds of terabytes
of deltas
- **Only fine-tuning is practical** — full pretraining on the Lisp machine never makes
sense. The 100x overhead is structural. Practical workflow: pretrain on
conventional GPU cluster → import as verified blob → convert to plist-native
under gate → fine-tune on the Lisp machine
- **Data gate latency** — every training example passes through the
authorization gate. For datasets with millions of examples, this pre-
processing step can take days
- **Wrong-spec for training policy** — the training policy is the most
security-critical spec. A compromised admin writing a policy that authorizes
all layers and all data defeats the system through its own verification
## What does this enable?
You can train on private data with proof of consent per example. The fine-tuning
history is structural, not logged — every gradient step is Merkle-linked to its
input. The world model gives the system sensorimotor common sense: object
persistence, trajectory prediction, basic physics — grounded in this specific
environment's observations.
## When is this viable?
- **Fine-tuning (GPU path):** 3-5 years on server hardware
- **World model:** same timeline — shares the pipeline and tensor unit
- **ASIC native:** when tensor unit silicon arrives (5-10 years)
## In practice
Training integrity is guaranteed at every step. Data consent is verified per
example. The optimizer cannot be swapped. Checkpoints cannot be backdoored.
But this system is not for training frontier models — it is for auditing
training runs that happen elsewhere.
The practical workflow is: pretrain on a conventional GPU cluster, import the
weights into the Lisp machine as a verified blob (Stage 4), then fine-tune on the Lisp machine
under the verified training loop. The pretraining phase remains unverified,
but the fine-tuning phase — where the model gains knowledge of private data
and user preferences — is verified. This is the pragmatic sweet spot.
The world model learns your environment's physics — how your voice sounds,
how your face moves when confused, how quickly you respond to different
message types. The gate falsifies its predictions, so the world model
converges toward accurate beliefs about your world, not the statistical
average of the internet.
← [[id:4a1f23b0-abc6-4def-9876-543210abcdef][Stage 5 — Weights]] → [[id:4a1f23b0-abc8-4def-9876-543210abcdef][Stage 7 — Remaining]]
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 4a1f23b0-abc7-4def-9876-543210abcdef
:END:

171
projects/passepartout/architecture/stage-7-remaining.org Normal file
View File

@@ -0,0 +1,171 @@
---
title: Stage 7 — What Remains
type: reference
tags: :passepartout:roadmap:
created: 2026-05-24
---
← [[id:4a1f23b0-abc7-4def-9876-543210abcdef][Stage 6 — Training]]
# Stage 7: What Remains
*Summary: At full maturity — dual-unit ASIC, plist-native weights, verified
fine-tuning, neural world model — the following irreducible threats survive.
None can be eliminated by computation alone.*
## 1. Physical threats
| Threat | Mitigation | Cost |
|--------|-----------|------|
| Theft | Tamper-resistant packaging (mesh sensors, zeroization on opening) | 10-100x packaging cost |
| EMP | Write-once checkpoint recovery | Mid-transaction data at risk |
| [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Hardware]] trojan in fabrication | Independent fab runs + trace comparison | 2x fab cost minimum |
| Power/EM side channels | Constant-power design, shielding | Power overhead |
Physical hardening is expensive in direct proportion to the threat level.
If someone steals your Lisp machine, they have your data. Hardware hashing
and encryption slow them down, but the security boundary is now physical.
## 2. Side channels in the verified model
The system is functionally correct but may leak information through timing
channels (unless the spec explicitly models timing as an output), access-
pattern channels (verified gates enforce authorization but not non-interference),
and the crypto-verification tension (proving constant-time is a different proof
from proving functional correctness).
Closing side channels requires 2-4x the verification effort for crypto routines
and oblivious RAM overhead for memory access. Feasible for security-critical
code, impractical for the entire system. For LLM inference, this means an
attacker on the same machine could determine which tokens were generated by
measuring computation time — an open research problem.
## 3. Oracle poisoning
The system reasons perfectly about a world that may not exist:
- **Time** — a clock that can be wrong (NTP drift or attack). The machine
cannot verify which time source is correct
- **DNS / network routing** — BGP hijack reroutes traffic. Cryptographic
envelopes survive, but traffic goes to the wrong destination
- **Sensors / physical input** — the machine processes correctly; the sensor
may be compromised
- **User input** — the single most dangerous oracle. A user who authorizes a
malicious action bypasses every security guarantee. The system is secure;
the user was wrong
Oracle diversity reduces surface area but introduces Byzantine agreement
problems. The question at Stage 7 shifts from "can the attacker break the
crypto?" to "can the attacker convince the user to press the button?"
## 4. The bootstrap axiom
- **Hardware** — silicon correctness cannot be proved from within the system
- **[[id:84a537b4-4256-50c8-91f5-dd5b4538418f][ACL2 kernel]]** — ~500 lines of Lisp accepted, not proved
- **Stage-0 bootstrap** — 500-byte hex sequence, readable by a human in an
afternoon, not mechanically verified
This is the Godelian boundary of the system. Any attack that modifies the
bootstrap is undetectable from within. Detection requires physical inspection
by a trusted external party. For any real-world threat model, this is not the
weakest link — the user's Wi-Fi password is far more likely to be compromised.
## 5. The gap between specification and intent
- **Wrong spec** — the system is provably correct with respect to its formal
spec. If the spec is wrong, the system is correct and wrong
- **Incomplete invariants** — every invariant must be explicitly formalized.
There is no Common Sense fallback (see Appendix A). The most dangerous gaps are unknown ones
- **Emergent failures** — two individually correct operations can produce a
catastrophic result in combination
The verified system is perfectly correct about the wrong thing. This is the
same class of failure as "the software compiled without warnings and crashed
in production" — but instead of debugging a crash, you are debugging a formal
specification that may take weeks to analyze.
## 6. The world outside the system
- **Lying peers** — a peer with a valid DID can give dishonest answers
- **Legal compliance** — a provably correct drug transaction is still illegal
- **Coercion / duress** — the user can be compelled to authorize actions. The
gate faithfully records the authorization
These externalities cannot be addressed within the system. Any attempt (duress
mode, silent alert) expands the threat model.
## Appendix A: Common Sense
**Common sense is the set of generalized expectations about how the world works
that are not derived from specific observations within a particular system.**
That a chair is for sitting. That promises create expectations. That people
contacted at 3am are likely to be annoyed.
These are distinct from the accumulated knowledge in the [[id:1c95ce7d-a2db-506a-9608-df68f9ae211b][Merkle DAG]], which records
specific observations. Common sense is the *generalization engine*.
**Three channels in the Passepartout architecture:**
| Channel | Origin | Verification | Granularity |
|---------|--------|-------------|-------------|
| LLM pretraining | Internet-scale corpus | None (probabilistic, distributed) | Vast but opaque |
| World model (LeCun) | Sensory observations + training | Falsified against accumulated DAG | Physical dynamics |
| Causal inference on accumulated knowledge | This system's DAG | Merkle-linked to evidence | Precise but bounded |
**The falsification loop brings common sense under gate control:**
1. LLM proposes a common-sense belief: "users don't like being contacted at 3am"
2. The world model formalizes it into a causal edge with a confidence weight
3. The gate queries the accumulated DAG: "how many 3am messages were
well-received in this user's history?"
4. If the evidence confirms, it enters the structural knowledge store
5. If contradictory, the gate rejects it and the LLM must revise
Over time, common sense that matches this specific user's world becomes
structural knowledge. The system converges toward beliefs aligned with the
user's actual environment, not the statistical average of the internet.
Common sense is never fully formalized and never fully trusted. It always
remains probabilistic, the LLM's domain, subject to falsification. The gate
does not "have" common sense. It gates access to the structural knowledge
store for beliefs that survive falsification.
## Appendix B: Summary table of eliminated threats
| Threat | Eliminated at stage |
|--------|---------------------|
| Memory corruption | 3 — Lisp Machine |
| OS exploitation | 3 — Lisp Machine |
| Malware / viruses / worms | 3 — Lisp Machine |
| Compiler backdoors | 3 — Lisp Machine |
| Message forgery / tampering | 1 — [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Social Protocol]] |
| MITM on communication | 1 — Social Protocol |
| Unauthorized actions | 2 — Gate stack (fully at 3) |
| Prompt injection bypassing gate | 4 — In-process inference |
| Weight tampering (blob level) | 4 — Verified blob hash |
| Weight tampering (fine-grained) | 5 — Plist-native weights |
| Data poisoning / unauthorized training | 6 — Verified training + world model |
| Physical theft / EMP | Survives to 7 |
| Side channels | Survives to 7 (specification gap) |
| Oracle poisoning | Survives to 7 (ground truth gap) |
| Wrong spec / human error | Survives to 7 (intent gap) |
| Bootstrap axiom | Survives to 7 (Gödelian boundary) |
| External coercion / law | Survives to 7 (not solvable by computation) |
The system ends up deductively secure inside a physically and oracularly
bounded envelope. That envelope — the chip, the world, the user — is the
only remaining attack surface worth worrying about.
Every security guarantee in this document has a price. The question is not
"is this secure?" but "is the price worth it for the threat model it
eliminates?" For a personal AI that holds private conversations and manages
keys, Stages 1-4 may be enough. For a financial system that settles billions,
Stages 5-6 justify the overhead. The progressive threat model is also a
progressive cost-benefit analysis — know the price, then decide.
← [[id:4a1f23b0-abc7-4def-9876-543210abcdef][Stage 6 — Training]]
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 4a1f23b0-abc8-4def-9876-543210abcdef
:END:

117
projects/passepartout/architecture/systemic-effects.org Normal file
View File

@@ -0,0 +1,117 @@
:PROPERTIES:
:ID: b9fa4b7b-bc61-4d7f-918d-ff687b80f2ba
:CREATED: [2026-05-23 Sat]
:END:
#+title: Passepartout — Systemic Effects Over Time
#+filetags: :passepartout:strategy:effects:geopolitics:society:
Passepartout is not a product in an existing category. Verified infrastructure is a new category, and every existing category — cloud, AI, OS, social, payments, compliance, governance — eventually migrates into it because the alternative becomes indefensible.
Using the [[id:2cdca4b0-6b41-44b4-acb0-af21d0e27b00][orders-of-magnitude framework]], the effects cascade across time scales. Each scale is qualitatively different, not just more of the same.
* Weeks to months — Phase Zero effects
** Scientific: verification becomes the publishing standard
Passepartout's gate rules turn every computational result into a machine-checkable proof. Papers carry proof logs, not just dataset citations. The replication crisis in compute-heavy fields (ML, climate science, genomics) meets its match — if the code doesn't verify, the result doesn't publish.
The effect compounds: proof repositories accumulate lemma libraries across fields, so each paper stands on verified shoulders, not on trust.
** Economic: the compliance industry's margins erode
The first enterprise that replaces a [[id:ed65031c-cbd2-4ad2-bd53-a67791e183cd][SOC2]] audit with a gate rule saves $500K and two weeks. The Big Four consulting revenue in GRC (governance, risk, compliance) starts eroding — first at the margins (automated control testing), then structurally (the entire audit function).
[[id:c34940cc-090e-57c4-8020-e78b1d32b96c][Gate rule packages]] sell to the same CISO who buys audit prep today. The difference: audit prep is a cost center; gate rules are an investment that compounds.
** Political: regulation becomes executable
The first regulation encoded as a gate rule sets a precedent. Regulators realize they can specify compliance in executable form rather than prose. This changes the regulator-regulated relationship from adversarial interpretation to formal specification.
A regulation that says "access logs must be tamper-proof" is a negotiation. A gate rule that enforces Merkle-chain logging is a fact. Compliance shifts from "did you follow the intent" to "does the proof pass."
* Months to years — Phase Zero scaling, early End State
** Technological: AI safety becomes engineering, not policy
The verified API gateway ([[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][revenue hub]]) proves that AI safety is a software engineering problem, not a policy problem. Companies don't need AI regulation — they need Passepartout gate rules between the LLM and production.
This shifts the entire AI safety discourse. The question stops being "what should we ban?" and becomes "what gates should we verify?" Prompt injection, jailbreaks, data leakage, hallucination in critical paths — all become gate rule specifications, not white papers.
** Social: institutional trust gives way to computational trust
"I verified it" replaces "I trust the auditor." DIDs make platform-owned identity look like a historical anomaly. The [[id:1a2b38df-20ba-58ca-ba55-a072be67bd0d][PDS model]] makes surveillance advertising technically impossible without the user's active consent gate.
The social contract around data shifts: companies don't own user data because the architecture literally prevents them from accessing it without a permission gate. The [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] model (notice + consent) was a regulation trying to fix bad architecture. The PDS model is architecture that makes bad behaviour impossible.
** Cultural: verification earns cachet
The Lisp renaissance is not retro — it is the first time a language of proof carries cultural cachet outside academia. A new generation of developers grows up with verification as a default, not an afterthought.
The "move fast and break things" ethos ages overnight. In the C-suite, saying "we don't verify our deployments" becomes as embarrassing as saying "we don't test our code" was in the 2000s. The cultural shift precedes and enables the economic shift.
* Years — End State consolidates
** Economic: [[id:827bc546-e887-5b7c-9b65-6392beaf0920][the verification monopoly]]
If every transaction on the social protocol, every plugin in the environment, every gate rule passes through Passepartout's verification, then the early player collects a tax on the entire verified economy. This is the [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]].
The $960B TAM ([[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][architecture index]]) is not aspirational — it is the cost of admission to the verified stack. Every dollar spent on cloud, AI, OS, social media, payments, and compliance eventually flows through the verification layer. The early player does not capture 100% of that, but the spread on even 5-10% is venture-scale money.
The switching cost to unverified infrastructure becomes infinite. No enterprise can justify "why would we go back to unverified code" once verification is in place. This is the [[id:2f783eb4-638e-5afa-9b59-6224d086a712][infrastructure lock-in]].
** Geopolitical: compute becomes a strategic asset
The [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]] becomes a geopolitical asset on the order of SWIFT or the dollar. Whoever provisions the largest verified compute capacity becomes the default infrastructure provider for any nation that wants verified digital sovereignty.
Passepartout is inherently anti-surveillance-capitalist architecture. The PDS model does not do bulk surveillance. This makes it threatening to both:
- /Authoritarian states/ — they lose dragnet access to citizen data
- /Surveillance capitalists/ — they lose the data moat their business model depends on
The nations that adopt verified infrastructure are in one economic sphere. The nations that block it are in another. This is a new axis of the digital cold war.
** Political: liquid democracy infrastructure at scale
Verifiable proxy voting, delegation chains, quadratic funding for [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][public goods (Social protocol contracts)]] — these are not experiments. They become infrastructure that nation-states adopt because the alternative (unverifiable voting, opaque governance) becomes indefensible.
The effect is not that democracy becomes digital. The effect is that trust in institutions becomes a measurable property rather than a polling number. Did the government follow its own rules? The proof log says yes or no. This is the political equivalent of the scientific reproducibility shift: institutions that can produce proof logs are trusted; institutions that cannot are not.
* Generations — End State mature
** Geopolitical: the digital order is redefined
The verification network defines the digital order in the same way the internet defined the 1990s. Nations on verified infrastructure are in one economic sphere; nations that are not are in another.
Lisp Machine hardware becomes a strategic export control — like advanced semiconductors today. Passepartout is not a product category; it is infrastructure sovereignty.
** Cultural: the break-everything era becomes a historical curiosity
The "move fast and break things" era is remembered like bloodletting or lead paint. A developer who does not verify is like a civil engineer who does not do structural calculations. The entire profession shifts from "write code" to "write verified code" as the default.
The cultural residue of the unverified era (daily security patches, ransomware as an industry, "works on my machine") becomes a teaching example of how things used to be done.
** Scientific: proof libraries as shared inheritance
ACL2 proof libraries are the arxiv of verified knowledge. The accumulation of proof strategies across millions of domains — every edge case ever encountered, every lemma ever proven — becomes a shared inheritance that no single human could assemble. The system bootstraps itself into regions of proof space that no unassisted human could reach.
The frontier shifts. The question is no longer "can we verify this" but "what new things become possible when verification is free." The corollary: what new kinds of error become possible when the proof is wrong? The proof is machine-checkable; the specification is human. Specification errors become the dominant failure mode — and that is a more tractable problem than runtime bugs, because specifications can be verified against other specifications.
** Economic: the old economy becomes a historical layer
Proprietary software [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][licensing]], cloud lock-in, compliance consulting, annual audit firms — these are as alien to someone born into the verified era as mainframes and COBOL are to a cloud-native developer. The new economy runs on verified infrastructure where the marginal cost of verification is zero and the switching cost to unverified infrastructure is infinite.
The insurance industry, which prices based on risk, shifts to pricing based on proof coverage. Companies with full verification pay lower premiums. Companies without it cannot get insured. This is the completion of the feedback loop: verification is not just better engineering — it is a requirement for participation in the formal economy.
* References
- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Architecture index]] — the full Passepartout architecture
- [[id:a1fac32a-47de-5fbd-b67d-29152c851747][Architecture overview]] — the three subsystems
- [[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][Revenue streams overview]] — economic effects quantified
- [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][Social protocol contracts]] — governance, insurance, liquid democracy
- [[id:827bc546-e887-5b7c-9b65-6392beaf0920][Verification monopoly]] — the big money
- [[id:2f783eb4-638e-5afa-9b59-6224d086a712][Infrastructure lock-in]] — switching costs
- [[id:2cdca4b0-6b41-44b4-acb0-af21d0e27b00][Orders of magnitude — time]] — the framework that structures this analysis
- [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Development timeline]] — Phase Zero vs End State mapping
- [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][Compute marketplace]] — the geopolitical asset
- [[id:1c95ce7d-a2db-506a-9608-df68f9ae211b][Lisp Machine security]] — why the architecture is anti-surveillance by design
- [[id:5f55bbe6-d243-5766-8ccf-5c5cc88a6542][AI industry impact]] — how verification changes the AI landscape

13
ideas/common-logic-iso-24707.org → projects/passepartout/common-logic-iso-24707.org
View File

@@ -1,4 +1,5 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 04c2f221-c54f-51e5-b40a-48822cd16d45
:END:
#+title: Common Logic (ISO 24707) — Relevance to Passepartout
@@ -8,13 +9,13 @@ Common Logic (ISO/IEC 24707) is a framework for first-order logic languages desi
Three standard dialects: CLIF (Common Logic Interchange Format), CGIF (Conceptual Graph Interchange Format), XCL (XML-based). Additionally, RDF and OWL can be mapped to CL, making them interoperable with any CL dialect.
**Relevance to Passepartout**
**Relevance to [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]]**
The fact store interchange format. Passepartout's fact store uses plists internally — fast, native to Lisp, zero serialization cost. But between instances (Agora sync, backup/restore, export), a standardized format is needed. CLIF is a strong candidate because its first-order logic is a direct match for the [[file:gate-rule-encoding.org][gate rules]] ACL2 verifies. A CLIF-to-ACL2 translator is mechanically straightforward — both operate on first-order formulas.
The fact store interchange format. Passepartout's fact store uses plists internally — fast, native to Lisp, zero serialization cost. But between instances ([[id:1d074690-a279-59cb-b91d-e9a22ae104ad][social protocol]] sync, backup/restore, export), a standardized format is needed. CLIF is a strong candidate because its first-order logic is a direct match for the [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][gate rules]] ACL2 verifies. A CLIF-to-ACL2 translator is mechanically straightforward — both operate on first-order formulas.
The dialect architecture mirrors Passepartout. CL's defining insight: define abstract semantics, let any concrete syntax map to it, get interoperability for free. This is the exact same pattern as Passepartout's "one gate stack, many skills" — the gate stack defines the security ontology (abstract semantics), and skills (dialects) map their operations to it. CL's approach validates Passepartout's design choice and provides a theoretical framework for it.
ISO standard as a credential. For regulated industries, "the knowledge representation follows ISO/IEC 24707" is a strong signal. It says the format is not proprietary, has formal semantics, and has been reviewed by an international body. This matters for HIPAA, SOC2, FedRAMP, and any compliance framework that asks about data representation standards. It is a checkbox that enterprise procurement requires.
ISO standard as a credential. For regulated industries, "the knowledge representation follows ISO/IEC 24707" is a strong signal. It says the format is not proprietary, has formal semantics, and has been reviewed by an international body. This matters for [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]], [[id:ed65031c-cbd2-4ad2-bd53-a67791e183cd][SOC2]], [[id:e6993701-3c67-49bf-82f3-06907572cbf3][FedRAMP]], and any compliance framework that asks about data representation standards. It is a checkbox that enterprise procurement requires.
The RDF/OWL bridge. CL has defined translations to RDF and OWL. This means Passepartout can consume knowledge from the semantic web without building a separate RDF parser. The fact store stays in plists internally; CL is the serialization and interchange layer. Any enterprise knowledge graph expressed in OWL can be ingested as CLIF, translated to plists, and verified by ACL2.
@@ -24,7 +25,7 @@ Multiple implementations exist. There are CL reference implementations (some in
Not a replacement for ACL2. CL is a knowledge representation standard, not a theorem prover. ACL2 proves theorems about gate rules. CLIF encodes the gate rules themselves. They are complementary: ACL2 verifies CLIF-encoded rule sets.
Not the internal representation. CLIF is verbose and not optimized for in-process use. The fact store should stay as plists internally. CL is the serialization layer — on the wire between Agora instances, in export files, in backup archives. This is the same pattern as JSON for web APIs: internal data structures are whatever is fastest, JSON is the interchange format.
Not the internal representation. CLIF is verbose and not optimized for in-process use. The fact store should stay as plists internally. CL is the serialization layer — on the wire between social protocol instances, in export files, in backup archives. This is the same pattern as JSON for web APIs: internal data structures are whatever is fastest, JSON is the interchange format.
Not a dialect to implement. Passepartout should not implement a full CLIF parser. The right approach is a thin translation layer: export plist → CLIF, import CLIF → ACL2-verified → plist. The AC Lisp ecosystem likely has CLIF libraries that can be wrapped.
@@ -37,10 +38,10 @@ CL's treatment of higher-order features is instructive: it extends first-order s
**Verdict**
Common Logic is relevant not as something to implement or replace, but as:
1. A natural serialization format for the fact store (Agora Notes, inter-instance sync)
1. A natural serialization format for the fact store (social protocol Notes, inter-instance sync)
2. An enterprise procurement checkbox (ISO standard)
3. A theoretical validation of Passepartout's dialect-based architecture
4. A bridge to RDF/OWL data sources
5. A cautionary example for the CIC prover design (careful about higher-order scope)
The right time to integrate it: when Agora Notes need a standard knowledge interchange format for inter-instance communication. Before that, it is a reference worth reading but not implementing. The CL approach informs the [[file:sufficiency-flip.org][sufficiency flip]] strategy and the [[file:cost-structure.org][cost structure]] of encoding domain knowledge.
The right time to integrate it: when social protocol Notes need a standard knowledge interchange format for inter-instance communication. Before that, it is a reference worth reading but not implementing. The CL approach informs the [[id:efc76898-03f7-57ba-923d-35d65da88bb7][sufficiency flip]] strategy and the [[id:0b5a8a74-cfd6-542d-bc88-4eb3cd8626f9][cost structure]] of encoding domain knowledge.

8
projects/passepartout/social-protocol/_index.org Normal file
View File

@@ -0,0 +1,8 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 8b2c3d4e-5f6a-7b8c-9d0e-1f2a3b4c5d6e
:END:
#+title: Social Protocol
#+filetags: :index:
The Passepartout Social Protocol specification — identity, communication, contracts, and governance requirements.

41
projects/passepartout/social-protocol/requirements-00-readme.org Normal file
View File

@@ -0,0 +1,41 @@
#+title: Social Protocol: Decentralized Social Network
#+AUTHOR: Amr
#+CREATED: [2026-03-17 Tue]
#+BEGIN_COMMENT
A decentralized social network protocol for the ATmosphere (AT Protocol) ecosystem.
#+END_COMMENT
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 10289e64-a4ff-4c34-828f-f3a9c769b73d
:END:
* [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Social Protocol]]: Decentralized Social Network
This project contains the specification and analysis for a decentralized social network built on open protocols.
* Project Tasks
See the actionable tasks for this project in GTD.org (Social Protocol project)
* Key Documents
- [[id:b25bf753-9799-41ab-82f5-1a1416db756b][01. Overview]]
- [[id:6fe67db6-25bd-4d11-bd1d-b44ec809e858][02. Identity]]
- [[id:3b43a9b8-31d1-4479-a35f-22273b74f0c7][03. Infrastructure]]
- [[id:f6cfc54b-919b-4311-bcbf-65e976755d40][04. The Primitive]]
- [[id:0f949f6c-4cf1-49eb-b9a4-ebcac27ee548][05. Social Spaces]]
-
-
-
-
-
-
-
-
* Status
- [X] Concept and atomic notes complete
- [X] Comprehensive specification built
- [ ] Governance decision (DEC-001) pending
- [ ] Implementation planning not started

428
projects/passepartout/social-protocol/requirements-01-overview.org Normal file
View File

@@ -0,0 +1,428 @@
#+title: Social Protocol Requirements - 01: Protocol Overview and Foundational Principles
#+author: Amero Garcia
#+created: [2026-03-19 Thu 21:07]
#+DATE: 2026-03-20
#+ID: agora-requirements-01-overview
#+STARTUP: content
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: b25bf753-9799-41ab-82f5-1a1416db756b
:END:
* 1. Introduction to the [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Social Protocol]]
The social protocol defines a novel architecture for decentralized digital interaction. Its primary objective is to replace extractive, centralized platforms—the era of *"Digital Feudalism"* where corporations own user data and control visibility via secret algorithms—with a decentralized *"Social Operating System"* that provides Identity, Justice, and Commerce for sovereign individuals and communities.
The protocol returns power to the edges by providing a modular protocol stack where trust is cryptographic, privacy is inherent, and freedom is architectural. This document provides a comprehensive overview of the protocol's foundational principles, core technical differentiators, and a detailed exploration of its capabilities across various use cases, including communication, content creation, e-commerce, collaboration, and liquid democracy. It serves as a high-level technical summary, articulating the design philosophy and the synergistic effects of its integrated components.
* 2. Foundational Principles
The protocol's design is predicated upon a set of core principles that collectively ensure a robust, user-centric [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][decentralized network]].
** 2.1. User Sovereignty and Data Ownership
Central to the protocol is the tenet of user sovereignty. Unlike centralized paradigms where platforms intermediate and often monetize user data, the protocol's architecture ensures that all user-generated content and personal data are exclusively owned and controlled by the originating user. This is achieved through client-side encryption, self-hosted or user-controlled Personal Data Stores (PDS), and audience-defined access controls (`access_control`).
** 2.2. Decentralization and Censorship Resistance
The protocol is designed to eliminate single points of failure and control. By distributing data storage across user-controlled PDSs and routing communication through a permissionless Relay Network, the protocol inherently resists censorship and external manipulation. There is no central authority capable of unilaterally restricting access, altering content, or deplatforming users.
** 2.3. Authenticity and Verifiability
Every action and piece of content within the protocol is cryptographically signed by the originating Persona. This provides an immutable and auditable record, ensuring the authenticity and integrity of all interactions. The content-addressed nature of all data, via Content Identifiers (CIDs), guarantees that content cannot be altered without changing its unique identifier, thereby establishing verifiable provenance.
** 2.4. Privacy by Design
The protocol incorporates privacy-enhancing technologies at every layer. End-to-end encryption is a default for private communications, and mechanisms such as Blinded Sharding for social recovery and "Off-the-Record" modes for ephemeral interactions are integrated to minimize metadata leakage and ensure user confidentiality.
* 3. Core Technical Differentiators
The protocol's unique capabilities stem from the synergistic integration of three primary technical differentiators: The Note Primitive, Self-Sovereign Identity (Personas and Master Key), and a Distributed Infrastructure (PDS and Relay Network).
** 3.1. The Note Primitive: Atomic Unit of Information
At the heart of the protocol's data model is the "Note"—the atomic, universal unit of information. Every piece of content or interaction within the protocol, regardless of its semantic meaning (e.g., a social post, a message, a contract, an encyclopedia entry, a product listing), is encapsulated within a Note.
For a comprehensive technical breakdown of the Note's structure, cryptographic hashing, and content flag schema, see *[[id:f6cfc54b-919b-4311-bcbf-65e976755d40][04: The Primitive]]*.
*** 3.1.2. Benefits of the Unified Note Primitive
The "Everything is a Note" paradigm yields significant architectural advantages:
- *Universal Interoperability:* A single, standardized data model allows any compatible client application to understand and process any Note, fostering an open ecosystem where diverse applications can seamlessly interact.
- *Immutable Audit Trail:* The content-addressed and signed nature of Notes inherently creates an unalterable, verifiable history of all digital interactions and content evolution.
- *Simplified Development:* Developers can focus on application-layer semantics and user experience, leveraging a robust and consistent underlying data primitive.
** 3.2. Self-Sovereign Identity: Personas and the Master Key
The protocol's identity system grants users absolute control over their digital presence, leveraging Hierarchical Deterministic (HD) cryptography to derive and manage multiple functional identities.
*** 3.2.1. The Master Key (Anima)
The Master Key serves as the absolute root of a user's digital being within the protocol.
- *Root of Trust:* A single, securely generated and stored secret seed from which all other identities are derived.
- *Hierarchical Derivation:* Utilizes a BIP-44 compatible HD derivation path (`m/44'/1'/account'/persona'/key_purpose/key_index`) to generate an infinite number of unlinkable Personas, each acting as a sovereign sub-root for its own functional keys.
- *Secure Storage:* Recommended for offline storage or within [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Hardware]] Security Modules (HSMs) to ensure maximum protection.
*** 3.2.2. Personas: Functional Digital Identities
Personas are the active, functional identities through which users interact with the protocol network.
- *Distinct Identities:* Each Persona represents a distinct Decentralized Identifier (DID), allowing users to maintain separate digital roles (e.g., personal, professional, anonymous) with granular control.
- *Key Management:* Each Persona possesses its own signing and encryption keypairs, which can be revoked or rotated independently without affecting the Master Key or other Personas.
- *Asset Ownership & Rights:* Personas are analogous to legal entities, capable of owning digital assets (e.g., Bitcoin wallets), entering into binding contracts, and claiming protected rights such as due process and freedom of expression.
*** 3.2.3. Decentralized Identity Management Benefits
- *Absolute User Control:* Full ownership of identity and keys, independent of any central authority.
- *Granular Access Control:* Ability to manage access to specific Personas and their associated data.
- *Efficient Organizational Revocation:* For collective entities, the HD model enables atomic revocation of access for departing members directly from the Master Key control point, streamlining offboarding and enhancing security across all associated assets and services.
- *Resilient Social Recovery:* Utilizes Shamir's Secret Sharing with trusted "Guardians" to enable Master Key recovery without reliance on centralized services.
** 3.3. Distributed Infrastructure: PDS, Relays, and Thin Clients
The protocol's infrastructure is specifically engineered to underpin user sovereignty, data ownership, and censorship resistance.
*** 3.3.1. Personal Data Store (PDS): The User's Digital Vault
The PDS is the central component for data ownership, acting as the user's sovereign digital vault.
- *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.
- *[[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
The Relay Network forms the intelligent communication backbone of the protocol, efficiently routing encrypted Notes between Personas.
- *Ephemeral Routing:* Relays route ciphertext based on CIDs and Persona subscriptions, without long-term storage of user data.
- *Pub/Sub Model:* Facilitates efficient, real-time delivery of Notes based on user subscriptions.
- *Censorship Resistance:* Users can publish to multiple Relays, ensuring availability and resilience against censorship.
*** 3.3.3. Agile Client Architecture: Broad Accessibility and Adaptability
The protocol adopts a flexible client architecture to balance user sovereignty with broad accessibility, particularly concerning app store ecosystems.
- *PDS-Proximate Logic:* Core application logic can reside and execute securely on the user's PDS.
- *Thin Clients:* Edge devices (mobile, desktop) run lightweight applications that interface with the PDS, mitigating app store restrictions and reducing device resource demands.
- *Strategic Imperative:* This architecture ensures the protocol's reach to a wider user base while maintaining security and privacy.
* 4. Use Cases: A Paradigm Shift
The synergistic combination of the protocol's core differentiators enables a wide array of transformative use cases, redefining digital interaction across multiple domains.
** 4.1. Decentralized Social Interaction
The protocol provides a robust framework for secure, private, and censorship-resistant interaction, moving beyond traditional platform-controlled silos.
*** 4.1.1. Asynchronous Interaction (The Note Primitive)
- *Unified Model:* All async interactions—whether directed messages or broadcast posts—are built on the same cryptographically signed *Note* primitive, utilizing the *DIDComm* protocol for secure transport.
- *Storage Sovereignty:* Employs a "Copy-on-Send" model for directed communication (ensuring recipient data ownership) and a "Reference-on-Send" model for broadcast content (ensuring owner control). The PDS acts as an encrypted mailbox proxy.
- *End-to-End Encryption:* Default for directed communications, utilizing standard encrypted envelopes. Double Ratchet and MLS ensure forward secrecy.
*** 4.1.2. Synchronous Interaction (Real-time)
- *WebRTC Integration:* Supports peer-to-peer real-time chat, voice, and video calls with end-to-end encryption and *decentralized signaling* via DIDComm handshakes.
- *Off-the-Record Mode:* Provides absolute privacy for ephemeral interactions by utilizing extremely short `ephemeral_duration` or bypassing PDS storage entirely, with content existing only in volatile client memory.
** 4.2. Social Publishing and Knowledge Management
The protocol fundamentally reshapes how content is created, published, and managed, empowering creators and ensuring verifiable knowledge.
*** 4.2.1. Feeds and Pages
- *Immutable History:* Social posts (`is_feed: true`) and wiki pages (`is_feed: false`) are signed Notes, providing an unalterable history of creation and edits.
- *Auditable Threads:* Replies are Notes referencing parent CIDs, creating verifiable discussion threads across the distributed network.
- *Direct Monetization:* Paywalled content and seeder rewards enable direct creator-to-consumer economic models via Lightning micro-payments.
*** 4.2.2. Decentralized Wikis and Encyclopedias
- *Versioned Pages:* Each wiki page is an `is_feed: false` Note, with edits creating new Notes that supersede previous versions, building an immutable, auditable version history.
- *Collaborative Ownership:* Access control and editing rights are managed via *Contract Notes* (Consent or Service Contracts) with `Collective Personas`.
- *Incentivized Contributions:* Micro-payments can reward contributions, fostering a collaborative, trustworthy, and censorship-resistant knowledge base.
*** 4.2.3. Verifiable News Ecosystem
- *Signed Articles:* News articles are `is_feed: true` Notes, signed by journalist Personas, ensuring clear provenance and ownership.
- *Immutable Record:* All versions of an article are archived, preventing historical revisionism or "disappearing" stories.
- *Decentralized Distribution:* Resilient against censorship attempts, as distribution occurs via the Relay Network.
- *Reputation Systems:* Notes referencing Persona DIDs and community-driven verification mechanisms can build transparent reputation for sources and journalists.
** 4.3. Decentralized E-commerce and Markets
The protocol enables peer-to-peer economic interaction without intermediaries, fostering transparent and auditable marketplaces for goods and services.
*** 4.3.1. Market Interaction Contracts
- *Offer as Early Contract:* A *Contract Note* (product listing) serves as a unilateral declaration of intent (*Offer*) by a seller, transitioning into a bilateral agreement (*Take*) upon buyer acceptance.
- *Transparent Listings:* Offers are signed Notes, providing verifiable details of items or services.
- *Questions and Reviews:* Notes that `reply_to` or `references` listings allow public or private dialogue, building transparent market trust and reputation based on Owner Reputation.
*** 4.3.2. Fungible vs. Non-fungible Assets
- *Non-Fungible:* The protocol's *Contract Note* model is inherently well-suited for unique goods and services (e.g., digital art, custom work), with each contract representing a distinct agreement.
- *Fungible:* While the protocol provides the identity, communication, and settlement rails (e.g., Lightning micropayments), high-speed trading of fungible assets (e.g., cryptocurrencies, commodities) would require specialized architectural layers (e.g., decentralized exchanges or AMMs) built *on top of* the protocol for order matching and liquidity.
** 4.4. Decentralized Collaboration and Project Management
The protocol offers robust primitives for secure, auditable collaboration, empowering teams and communities.
*** 4.4.1. Version-Controlled Documents and Code
- *Signed Commits/Edits:* Each change to a collaborative document or codebase is a signed Note with appropriate `content_type` (for code) or a versioned `is_feed: false` Note (for documents), creating an immutable, auditable history.
- *Collective Ownership:* Repositories or documents can be owned by `Collective Personas`, with access and editing rights managed via *Contract Notes*.
- *Decentralized GitHub/Git Integration:* Codebases are stored as Merkle DAGs of commit Notes, enabling decentralized version control. Issues and pull requests are also Notes, facilitating transparent project management.
*** 4.4.2. Project Management and Task Tracking
- *Tasks as Contracts:* Project tasks are *Contract Notes* in a negotiation state, allowing for assignment, progress tracking, and integration with payment mechanisms.
- *Incentivized Development:* Lightning bounties (*Contract Notes*) can be attached to issues or tasks, directly rewarding contributions upon completion and verification.
*** 4.4.3. The Aletheia Portfolio (Professional Integration)
The convergence of native hosting, identity, and contracts enables a unified professional workflow. For example, a freelance photographer can:
- *Generate & Publish:* Build a professional portfolio using a static site generator and publish it natively to the network via their "Professional Persona" root CID.
- *Sovereign Hosting:* The portfolio remains available via any Gateway, resilient against PDS downtime.
- *Contractual Linkage:* Directly link the portfolio Note to a binding service contract for client hiring, with payments settled via Lightning.
** 4.5. Liquid Democracy and Governance: Evolvable Collectives
The protocol's identity and contract primitives lay the groundwork for a dynamic, adaptive model of decentralized governance that moves beyond the rigidity of traditional blockchain-based DAOs.
*** 4.5.1. Adaptive Constitutions and Policy Execution
- *Signed Votes and Execution:* Individual votes are signed Notes that `references` a proposal CID. Unlike immutable blockchain code, the protocol's governance is built around *Adaptive Constitutions*.
- *Recursive Rule-Making:* Successful votes trigger the Governance Executable Module (GEM) to automatically update the Collective's policy parameters (e.g., membership fees, arbitration rules) in its active Smart Constitution.
- *Immutable History, Mutable State:* While the complete audit trail of every vote and version is permanently recorded as a chain of CIDs, the organization can evolve its logic over time without requiring complex migrations.
*** 4.5.2. Decentralized Autonomous Organizations (DAOs)
- *Foundation Contracts:* DAOs are formalized as `Collective Personas` governed by a set of foundational `Contract Notes` that define membership, treasury management, and decision-making processes.
- *Forks as Safety Valves:* Because the protocol is permissionless, minorities can "fork" a Collective by creating a new Persona based on an earlier constitutional CID, ensuring protection against majority tyranny and preserving community intent.
- *Transparent Operations:* All operational decisions, proposals, and expenditures within a DAO are conducted and recorded as signed Notes and Contracts, providing 100% transparency to participants.
* 5. Conclusion: Towards a Self-Sovereign Digital Future
The social protocol is meticulously designed to serve as the foundational layer for a new era of decentralized digital interaction. By unifying identity, data, and communication under the immutable, verifiable, and user-owned "Note" primitive, coupled with a distributed infrastructure and self-sovereign identity management, the protocol offers a robust and resilient alternative to centralized systems. Its capabilities span from secure personal communication to complex global e-commerce, from collaborative knowledge creation to transparent democratic governance. The protocol empowers individuals and collectives to reclaim their digital sovereignty, fostering an internet where trust is cryptographic, privacy is inherent, and freedom is architectural.
* Bootstrapping & Progressive Decentralization
** The Cold Start Problem
A decentralized social network faces an existential network effect challenge. Users will not join if there is no content, and creators will not post if there are no users. The protocol solves this through *Progressive Decentralization*.
** Bootstrap Sequence
The system MUST provide a smooth onboarding experience, especially in the first five minutes:
1. *Persona Selection:* A simple UI for selecting a "Persona Alias" (e.g., `@amr`).
2. *Key Generation:* High-speed, hardware-backed key derivation (BIP-32) happens in the background.
3. *PDS Selection:* Users are prompted to choose between *"Managed Hosting"* or *"Self-Hosting"*.
4. *Relay Discovery:* The client automatically connects to a set of high-reputation, geographic "Bootstrap Relays" to fetch initial content.
5. *Interest Capture:* Users select topics/interests to seed initial content recommendations.
6. *Migration Option:* Offer to import from Twitter, Reddit, Mastodon, etc. to bootstrap social graph.
** Interest Capture
*** Purpose
Reduce "empty feed" problem by immediately showing relevant content based on user interests.
*** Implementation
- *Explicit Selection:* Users pick from curated categories (Technology, Art, Politics, Science, etc.).
- *Implicit Extraction:* If user imports from centralized platforms, parse their follows/history to infer interests.
- *AI Assistance:* Sub-Agent can analyze imported content to suggest interest categories.
*** Content Seeding
- Client fetches popular public content in selected interest areas.
- Initial feed populated with high-quality, diverse content from selected topics.
- Users can refine interests over time (feedback loop).
** Migration and Social Graph Bootstrap
*** Supported Platforms
- *Twitter/X:* Import followed accounts via archive export or API.
- *Reddit:* Import subscribed subreddits and frequent communities.
- *Mastodon/ActivityPub:* Native federation, direct import of follows.
- *LinkedIn:* Professional connections import.
- *Blog/RSS:* Import RSS subscriptions as interest sources.
*** Privacy Considerations
- Migration is *opt-in*, not mandatory.
- Users choose which platforms to import from.
- Imported data is stored locally; only new protocol follows are public.
- Users can audit and remove imported suggestions before
confirming follows.
*** Discovery Expansion
- Suggest high-reputation personas in imported interest areas.
- Show "Your Twitter follows on the protocol" for easy reconnecting.
- Surface collectives matching imported community memberships.
** The "Four Orders of [[id:26f3e845-5eb4-4bcd-9cff-28e219934841][Growth]]" (Scaling Sequence)
Scaling a decentralized network requires shifting from "Hand-holding" to "Protocol Incentives." The protocol follows a strictly defined orders-of-magnitude [[id:26f3e845-5eb4-4bcd-9cff-28e219934841][growth strategy]]:
*** Order 1: The First 1,000 (The "Founders")
- *Target:* Technical enthusiasts, privacy advocates, and niche professional guilds (e.g., decentralized AI devs).
- *Tactics:* Manual onboarding. We seed the first Arbitration Guilds.
- *Success Metric:* First successful civil contract signed and settled via HODL invoice.
*** Order 2: The 10,000 (The "Communities")
- *Target:* Small NGOs, local trade groups, and content creator "Swarms."
- *Tactics:* Launch the Community PDS templates. Enable "One-Click Hub" setup so a leader can host their entire group.
- *Success Metric:* The emergence of "Community Algorithms"—feeds curated by these 10k users that provide unique value.
*** Order 3: The 100,000 (The "Marketplace")
- *Target:* Freelancers, gig workers, and "Etsy-style" digital sellers in regions with weak rule of law.
- *Tactics:* Focus on Mobile UX. The app must feel "normal." Introduce Automated Key Rotation so non-tech users don't fear losing their phones.
- *Success Metric:* $1M+ in peer-to-peer transaction volume via SCAL contracts.
*** Order 4: The 1M+ (The "Ecosystem")
- *Target:* The general public.
- *Tactics:* The Algorithm Marketplace becomes the draw. People join because "The Scientific Lens" or "The Family Lens" on the protocol provides a better mental health experience than the addictive AI of centralized apps.
- *Success Metric:* Total P2P bandwidth (Seeding) exceeds the capacity of a mid-sized centralized CDN.
** Progressive Decentralization Phases
*** Phase 1: Managed Service (Days 1-100)
- *Centralized Experience:* The initial developers provide high-performance, managed PDS and Relay services to ensure a seamless "Twitter-like" experience.
- *Focus:* User acquisition and content density in specific "Alpha" collectives (e.g., AI/Dev communities).
*** Phase 2: Hybrid (Year 1)
- *Self-Hosting Options:* Users are encouraged to move to their own PDS or third-party providers as the ecosystem matures.
- *Social Graph Interoperability:* Enabling users to "Follow" personas across different PDS providers.
*** Phase 3: Full Decentralization (Year 3+)
- *No Central Authority:* The original developers become just one of many PDS and Relay providers.
- *Protocol Stability:* The V1.0 spec is finalized, and development is driven by the *Protocol Governance Model*.
** Incentivized Growth
- *Referral Satoshis:* Early users can be rewarded in satoshis for successful referrals that lead to high-reputation personas.
- *Micro-Grant Bounties:* Funding developers to build "Must-Have" protocol apps through the economic layer.
* Strategic Positioning
** Platform Replacement Strategy
Rather than positioning the protocol as an existential threat to Big Tech (Apple, Google, Meta), the protocol should first target underserved communities and platforms with clear pain points:
*** Phase 1: Niche Community Platforms
** Forums (Reddit, phpBB, vBulletin)
- *Pain Point:* Centralized moderation, censorship, data mining.
- *Social Protocol Advantage:* Sovereign moderation, portable identity, no platform lock-in.
- *Target Communities:* Developer forums, hobbyist communities, support forums.
** Visual Discovery (Pinterest)
- *Pain Point:* Algorithmic manipulation, advertising-driven discovery.
- *Social Protocol Advantage:* User-chosen discovery algorithms, no surveillance capitalism.
** Professional Communities (LinkedIn, corporate intranets)
- *Pain Point:* Professional data exploitation, platform-controlled networking.
- *Social Protocol Advantage:* Sovereign professional identity, portable reputation.
** Creator Platforms (Medium, Substack)
- *Pain Point:* Platform fees (10-50%), censorship risk, no portability.
- *Social Protocol Advantage:* Near-zero fees, content ownership, subscriber portability.
** Marketplaces (eBay, Etsy)
- *Pain Point:* High fees (10-15%), centralized dispute resolution, account bans.
- *Social Protocol Advantage:* Low fees (<5%), transparent reputation, sovereign stores.
** Adult Content (Pornhub, OnlyFans)
- *Pain Point:* Censorship, payment processor discrimination, lack of privacy.
- *Social Protocol Advantage:* Censorship-resistant, Lightning-native payments, pseudonymous.
** Specialized Communities (QRZ, Logbook of the World)
- *Pain Point:* Aging infrastructure, lack of modern features, centralization.
- *Social Protocol Advantage:* Modern protocol, extensible, community-governed.
** Decentralized Communities (Nostr, Fediverse)
- *Pain Point:* Fragmentation, lack of economic layer, UI/UX challenges.
- *Social Protocol Advantage:* Unified protocol, Lightning integration, polished UX.
*** Phase 2: Horizontal Expansion
Once established in niche communities:
- *Bridge to Big Tech:* Migration tools for Twitter, Instagram, etc.
- *Enterprise Adoption:* Sovereign collaboration tools for companies.
- *Mass Market:* Only after protocol stability and network effects proven.
** Big Tech Analysis (Long-term)
While not the immediate focus, the protocol's architecture eventually threatens Big Tech:
*** Meta/Facebook
- *Risk:* Portable identity undermines social graph lock-in.
- *Timing:* Year 3+ after network effects established.
*** Apple
- *Opportunity:* Privacy alignment, hardware security integration.
- *Risk:* App Store policies may restrict protocol clients.
*** Google
- *Risk:* Search dominance challenged by social-graph-first discovery.
- *Opportunity:* Federated search, open data standards.
** The "Trojan Horse" Strategy
- *Start Small:* Win over frustrated communities on Reddit, forums, Discord.
- *Build Bridges:* ActivityPub/Mastodon integration, Twitter migration tools.
- *Demonstrate Value:* Show "You trade 2 seconds for freedom" is worth it.
- *Let Giants React:* By the time Big Tech notices, the protocol is entrenched.
** Strategic Assessment
- *Cold Start Problem:* The most significant hurdle. Requires aggressive bootstrapping in the first year.
- *Success Probability:* 30-50% for 100K users; 10-20% for 1M users (within 3 years).
- *The "Unstoppable" Factor:* Once the protocol is decentralized and the first million users are on-boarded, it becomes nearly impossible to shut down.
* Legal & Regulatory
** The Jurisdictional Challenge
As a decentralized protocol with no central authority, the protocol is designed to operate across international jurisdictions.
** Content Moderation & Liability
*** The "Dumb Pipe" Strategy
- *Relays as Carriers:* Relays act as dumb, ephemeral conduits for encrypted CIDs. Their legal standing is similar to ISPs or postal services.
- *PDS Sovereignty:* The user (the PDS owner) is the only entity with the ability to decrypt and view the content.
*** The CSAM Challenge
- *Zero Tolerance Policy:* The protocol's governance model includes protocol-level consensus for universally illegal content.
- *Network-Level Blocking:* High-reputation Relays can block CIDs associated with CSAM.
- *Fundamental Tension:* The trade-off between total privacy (E2EE) and the ability to detect illegal content.
** Financial Regulation & AML
- *Micro-Payments:* Lightning Network payments generally fall below traditional AML/KYC thresholds.
- *Non-Custodial:* The protocol is non-custodial. Users control their own keys and funds.
** Data Privacy ([[id:c0fdec00-8a44-43f0-ac81-e8dc61411865][GDPR]]/CCPA)
- *The "Right to be Forgotten":* In a CID-based system, data is not "deleted" but can be "un-indexed" or its decryption keys revoked.
- *Sovereign Control:* Users have absolute control over their own data in their PDS.
** Strategy for Resistance
- *Legal Defense Collective:* Establishing a legal defense fund (Collective Persona) to support Relay and PDS operators.
- *Transparency Reports:* High-reputation Relays and PDS providers should publish transparent reports on compliance.
* Game Theory & Economic Attacks
** Attack Vectors
- *Sybil Attacks:* Creating millions of fake personas.
- *Relay Censorship:* Majority of Relays blocking specific content.
- *Economic Spam:* Paying minimal fees to flood the network.
- *Governance Capture:* Attempting to take over protocol governance.
** Defenses
- *Reputation Systems:* Economic and social costs of attack increase with reputation requirements.
- *Multi-Home Relays:* Users can always switch to uncensored Relays.
- *Fee Markets:* Dynamic pricing makes spam economically unviable.
- *Fork Threat:* Credible threat of fork prevents governance capture.
* Related Documents
- Protocol Strategic Positioning
- Protocol Legal & Regulatory Strategy

617
projects/passepartout/social-protocol/requirements-02-identity.org Normal file
View File

@@ -0,0 +1,617 @@
#+title: Identity: The Genesis of Your Digital Being
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 6fe67db6-25bd-4d11-bd1d-b44ec809e858
:END:
* [[id:750876d3-0cf8-4818-a323-a4f974870f4f][Identity: The Genesis of Your Digital Being]]
** Master Key (Psyche)
The Master Key, often referred to as "Psyche" (Latin for soul or animating principle), is the absolute foundation of your digital identity in [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Social Protocol]]. It serves as your unassailable root of trust, from which every other functional identity (your Personas) is cryptographically derived. This section meticulously outlines the Master Key's core requirements, elucidates how it empowers flexible organizational structures, and details the robust mechanisms for its secure management and resilient recovery. It is the ultimate key to your self-sovereignty.
*** Requirements & The Root of Trust
- The system MUST cryptographically decouple identity from the master cryptographic material, ensuring that derived keys can be managed independently while retaining the Master Key as the root of authority.
- Users MUST possess one Master Key (the "Seed") that is generated and stored securely, ideally never exposed to the network or a general-purpose operating system.
- All functional identities (Personas) MUST be derived from this single Master Key seed using Hierarchical Deterministic (HD) derivation, providing an organized and secure structure for digital identities.
- The Master Key MUST be generated from a minimum of 256 bits of high-quality, cryptographically secure entropy.
- The Master Key MUST be encoded as a BIP-39 mnemonic phrase (typically 24 words) for human-readable, offline backup and disaster recovery.
- The Master Key MUST be stored offline (e.g., on paper, engraved metal) or within a tamper-resistant [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]] security module (HSM) for maximum protection against compromise.
- The system MUST utilize a custom HD derivation path: `m/44'/1'/account'/persona'/key_purpose/key_index`, uniquely identifying the protocol's identity structure within the broader BIP-44 ecosystem. (*Note: Index `1'` is utilized for the experimental/testnet phase; a unique permanent index will be registered for the protocol Mainnet via SLIP-0044.*)
- This path allows each Persona to act as a "Sub-Root," deriving its own autonomous functional keys (e.g., for Bitcoin, Lightning, PGP, or SSH) without requiring access to the Master Key once the Persona's extended private key (xpriv) is provisioned to a device.
- Each `persona'` index within this derivation path MUST represent a distinct DID (Decentralized Identifier), ensuring global uniqueness and unlinkability.
- The system MUST allow a single Master Key seed to generate an infinite number of unique, unlinkable personas, providing unparalleled flexibility for different digital roles.
- Each Persona MUST possess its own distinct Ed25519 keypair for cryptographic signing and an X25519 keypair for robust encryption.
- The system MUST enable the revocation and rotation of individual Persona keys without compromising the integrity of the Master Key or affecting other derived Personas, offering granular control and enhanced security.
- The identity lifecycle MUST be managed via *KERI (Key Event Receipt Infrastructure)*, ensuring identities remain persistent regardless of key rotations.
- All key rotations and membership changes MUST be recorded in an append-only, verifiable *Key Event Log (KEL)*.
*** Master Key Interaction Protocol: Derivation vs. Action
It is critical to distinguish between the Master Key's role in *Persona derivation* and a Persona's role in *network actions*.
- *Master Key for Derivation (Creation of New Identities):* The Master Key is the sole cryptographic origin for generating new Accounts and Personas. Any creation of a new Persona (or Account) in your identity tree requires interaction with the Master Key. This ensures a clear, auditable, and cryptographically sound chain of custody from your single root to every Persona. While this might occasionally require accessing a hardware wallet for a new Persona setup, it safeguards the integrity of your entire identity graph.
- *Persona Keys for Actions (Interacting with the Network):* Once a Persona is created, it becomes a fully independent, active agent in the protocol network. All subsequent actions—signing messages, publishing content, entering into contracts (including Foundation Contracts), acting as a guardian for social recovery, or joining an organization—are performed using the Persona's own distinct keypairs. *The Master Key is explicitly *not* needed for these daily operational activities.* This design minimizes the Master Key's exposure, keeping it safely offline and dramatically reducing the frequency of hardware wallet interactions for routine tasks.
This clear separation ensures that your Master Key functions as a secure, infrequent-use root for identity creation and recovery, while your Personas are empowered to execute all network interactions autonomously.
*** Master Key Recovery: The Offline Root Seed
**** Shamir's Secret Sharing: Distributed Trust
If a user loses access to their offline Master Key, the protocol's Social Recovery mechanism provides a decentralized, self-sovereign solution:
1. Master Key is cryptographically pre-split into N shards using Shamir's Secret Sharing.
2. These shards are securely distributed to M-of-N "Guardians" (trusted friends or professional services).
3. Recovery only requires M guardians to recombine their shards, rebuilding the Master Key offline.
4. This elegantly avoids reliance on centralized "Account Recovery" services, keeping you in control.
**** Social Recovery Privacy (Blinded Sharding)
***** Blinded Sharding Concept
Standard Shamir's Secret Sharing reveals which guardians hold shards when shards are stored on the PDS. *Blinded Sharding* hides this information from the PDS while still enabling recovery.
***** How Standard Shamir Reveals Guardians
- Shards stored as: `(index, shard_value)` pairs
- PDS sees: "Guardian #1 has this shard, Guardian #2 has that shard"
- Reveals: Who the user's trusted contacts are (social graph)
***** Blinded Sharding Solution
Instead of storing `(index, shard)` directly, use *cryptographic blinding*:
****** Step 1: Generate Mask
- Random mask `m` for each shard
- Mask is encrypted to Guardian's public key
- Only Guardian can unmask the shard
****** Step 2: Store Blinded Shard
```
Stored on PDS:
- Blind = hash(shard || guardian_pubkey)
- Shard encrypted to Guardian's key (X25519 + AES-GCM)
- Guardian ID: NOT stored in plaintext, only hash
```
****** Step 3: Recovery
- Guardian sends encrypted shard response
- User decrypts using their private key
- Verifies shard validity via Shamir reconstruction
- PDS never learns which Guardians participated
***** Implementation
#+begin_src typescript
interface BlindedShard {
// Public, stored on PDS
shardHash: string; // hash(shard || guardian_pubkey)
encryptedShard: string; // X25519 + AES-GCM encrypted
// Not stored: Guardian ID
// Guardian identified by: can decrypt `encryptedShard`
// (only valid Guardian has private key)
}
interface GuardianConfig {
guardianDID: string; // Known to user, NOT to PDS
guardianPublicKey: X25519PublicKey;
}
// Shard creation
function createBlindedShard(
shard: Buffer,
guardianConfig: GuardianConfig
): BlindedShard {
const shardId = hash(sha256, [shard, guardianConfig.guardianPublicKey]);
const encrypted = x25519_encrypt(shard, guardianConfig.guardianPublicKey);
return {
shardHash: shardId,
encryptedShard: encrypted
};
}
// Reconstruction
async function recoverShard(
blindedShard: BlindedShard,
guardianPrivateKey: X25519PrivateKey
): Promise<Buffer> {
// Guardian decrypts
const decrypted = x25519_decrypt(
blindedShard.encryptedShard,
guardianPrivateKey
);
// Verify not corrupted
if (hash(sha256, [decrypted, guardianPublicKey]) !== blindedShard.shardHash) {
throw new Error("Shard verification failed");
}
return decrypted;
}
#+end_src
***** Security Properties
1. *PDS doesn't know Guardians:* Only sees random hashes and ciphertexts
2. *PDS can't correlate:* Different users' Guardians appear as different random data
3. *Guardian anonymity:* Recovery can happen without PDS knowing who responded
4. *Integrity verified:* Hash check prevents corrupted shards
**** Shamir's Secret Sharing Parameters
***** Standard Parameters
- *Scheme:* Shamir's Secret Sharing over GF(2^256)
- *Threshold (M):* 3 (minimum to reconstruct)
- *Total Shares (N):* 5 (total generated)
- *Security:* 256-bit security (same as Bitcoin private keys)
***** Share Distribution
- *Guardian 1:* Trusted friend, geographically distant
- *Guardian 2:* Family member
- *Guardian 3:* Professional service (optional)
- *Guardian 4:* Personal cloud/HSM backup
- *Guardian 5:* Safety deposit box (physical)
***** Recovery Probability
- *1 guardian fail:* Still recoverable (4 of 5 remaining)
- *2 guardians fail:* Still recoverable (3 of 3 remaining)
- *3+ guardians fail:* Unrecoverable (design choice)
** HD Derivation
*** HD Derivation Architecture (BIP-32/44)
- The protocol uses a custom derivation path to ensure interoperability: `m/purpose'/persona_index'/profile_index/key_type`.
- The `persona_index'` MUST be hardened to prevent correlation attacks between different personas.
- Each `persona_index'` MUST represent a distinct DID (Decentralized Identifier).
- This allows a single seed to generate infinite, unlinkable personas.
*** Decoupled Key Provisioning & Watch-Only Master
To minimize the exposure of the Master Seed, client applications MUST support decoupled key strategies:
- *Subkey Injection:* The client MUST allow importing a standalone extended private key (xpriv) or raw private key for a specific `persona_index'`. The app operates strictly within the scope of that imported key and cannot derive sibling personas.
- *Multi-Device Sync:* Users can securely provision a secondary device (e.g., a mobile phone) by injecting a Persona-level subkey, keeping the Master Seed in a physical hardware vault.
- *Watch-Only Master:* The client MAY allow storing the Master Extended Public Key (xpub). This creates an "Auditor View," enabling the device to monitor all derived Personas and balances without possessing the private keys necessary to authorize transactions or sign events.
*** Cross-Persona Interaction (The "Bridge")
The system MUST allow a user to prove relationships between their own Personas without publicly linking them to a single Master Seed.
- *Zero-Knowledge Proofs (ZKP):* A user can "Attest" that a specific capability or badge belongs to them across personas. For example, a "Pseudonymous Developer" Persona can use a ZKP to prove it holds a "Verified Citizen" badge issued to its associated "Legal Persona," proving citizenship without revealing *which* citizen they are.
*** Index Management (Gap Limit Protocol)
**** Concept
Clients must efficiently discover active personas derived from a Master Seed without performing an exhaustive scan of the entire index space. The Gap Limit Protocol defines the search window and criteria for identifying active personas during recovery or sync.
**** Specification
- *Gap Limit (L):* The number of consecutive unused persona indices to check before stopping the scan. The default protocol gap limit is *20*.
- *Active Persona Detection:* A persona index is considered "active" if it has:
1. A registered name in the Tier 2 Global Registry.
2. Any Content Objects published to a PDS/Relay.
3. Any incoming attestations from other personas.
- *Scan Window:* Clients scan indices in increments of L. If any index within $[i, i+L-1]$ is active, the window shifts to $[i+L, i+2L-1]$.
**** Recovery Workflow
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, [[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.
*** Centralized Revocation Efficiency: The Atomic Kill Switch for Organizations
**** Comparison to Traditional Systems
- *Traditional:* Partner leaves → Manually update 50+ passwords, revoke individual access rights across numerous platforms (email, bank, cloud storage, code repos, etc.). High risk of oversight and residual access.
- *Passepartout Social Protocol:* Partner leaves → One managed revocation at the Master Key level (or their specific Persona's access derivation is severed) → Instant, automatic severance of access across all derived keys (company Bitcoin, PGP, SSH, etc.).
This mechanism ensures that the collective's assets remain secure and under the control of the remaining authorized members, providing a robust solution for organizational identity management.
** Accounts
*** Account-Level Strategy: Organizing Your Digital Life
**** Derivation Path with Accounts
```
m/44'/1'/0'/0' # Account 0, Persona 0 (default personal)
m/44'/1'/0'/1' # Account 0, Persona 1
m/44'/1'/1'/0' # Account 1, Persona 0 (work account)
m/44'/1'/1'/1' # Account 1, Persona 1 (work, second persona)
m/44'/1'/2'/0' # Account 2, Persona 0 (anonymous/account-specific)
```
**** Account Separation Strategies
***** Personal vs Work
- *Account 0:* Personal life, friends, family
- *Account 1:* Professional identity, colleagues
- Each account has its own set of personas (persona index within account)
***** Anonymous vs Primary
- *Account 0:* Primary public identity
- *Account 2+:* Anonymous or temporary accounts
- Easy rotation: revoke entire account, create new account index
***** Organizational Accounts
- *Account 3+/Specific Values:* Could be assigned for specific organizations
- Each organization gets its own account namespace
**** Account Naming and Metadata
- *Account Aliases:* User-defined labels ("Personal", "Work", "Anonymous")
- *Account Icons:* Visual distinction in client UI
- *Account Metadata:* Not stored on-chain, local to client
- *Account Lock/Unlock:* Separate authentication for each account
**** Account-Specific Configuration
- *Default PDS:* Each account can use different PDS providers
- *Default Relays:* Account-specific relay preferences
- *Contact Isolation:* Contacts in one account not visible in others (by default)
- *Content Visibility:* Cross-account content visibility configurable
**** Cross-Account Operations
- *Account Switching:* Quick switch without re-entering Master Key
- *Cross-Account References:* "Share from Work to Personal" with privacy controls
- *Unified Inbox:* Optional aggregation of notifications across accounts
- *Backup Strategy:* Account-level backup (export all personas in account)
**** Security Considerations
- *Same Master Key:* All accounts derived from same seed—compromise of Master Key compromises all accounts.
- *Different Lock Codes:* Each account can have its own unlock PIN/biometric.
- *Plausible Deniability:* Hidden accounts possible (account index not sequential).
**** Developer Implementation
To generate a new Persona:
1. Load Master Seed.
2. Derive path `m/44'/1'/0'/N'` where N is the next available index.
3. Generate Ed25519 keypair from the derived entropy.
4. Construct the DID: `did:agora:<pubkey_multibase>`.
**** Account-Level Technical Specification: The Blueprint for Digital Organization
The Account-Level Strategy is built upon a robust technical foundation that rigorously adheres to and extends industry standards for cryptographic key derivation. This specification ensures predictable, secure, and interoperable management of multiple digital identities from a single Master Key.
***** BIP-44 Derivation Path Structure: Protocol's Standard
The protocol meticulously follows the established BIP-44 standard for hierarchical deterministic key derivation paths. This standardized structure guarantees compatibility and logical organization of your digital identities.
`m / purpose' / coin_type' / account' / persona' / key_purpose / key_index`
In the protocol's context, this is specifically mapped as:
`m / 44' / 1' / account' / persona' / key_purpose / key_index`
- *Purpose (44'):* This is a hardened derivation, as prescribed by BIP-44, signifying that the derived keys are cryptographically isolated from the Master Key.
- *Coin Type (1'):* This is a hardened derivation, and `1'` is the officially registered SLIP-0044 index specifically allocated for the Social Protocol.
- *Account (account'):* This is a hardened derivation. It provides independent, cryptographically isolated persona namespaces, enabling users to manage distinct organizational or contextual groupings of Personas.
- *Persona (persona'):* This is a hardened derivation. Each index represents a distinct, autonomous digital identity (DID). Hardening ensures that compromising one Persona's keys cannot compromise sibling Personas or the Master Key.
- *Key Purpose (key_purpose):* This non-hardened layer allows a single Persona to act as a "Sub-Root" to derive autonomous functional keys for specific tasks without requiring the Master Key. Examples:
- `0`: Primary Identity/Signing Key (Ed25519)
- `1`: General Encryption Key (X25519 for DIDComm)
- `2`: Bitcoin/Lightning Node Key
- `3`: Stablecoin/EVM Wallet
- *Index (key_index):* This is a non-hardened, incremental index used to generate multiple unique keys of a specific purpose (e.g., generating new receive addresses for a Bitcoin wallet).
*Note: This structure ensures that once a Persona's xpriv is loaded on a mobile device, that device can derive all necessary sub-wallets autonomously without re-accessing the Master Key.*
***** Account Types and Reserved Indices: Standardized Compartmentalization
While the choice of account indices is technically arbitrary, the protocol recommends the following conventions. These standardized assignments ensure client interoperability and provide a common language for managing distinct digital compartments.
- *0': Primary Account.* This is the default account for a user's primary personal identity, social interactions, and other everyday personas.
- *1': Professional Account.* This account is dedicated to professional identity, credentials, work-related personas, and business interactions.
- *2': Anonymous/Testing Account.* Designed for high-churn, disposable, or experimental personas where anonymity or frequent rotation is desired.
- *100'+: Organization/Collective Accounts.* These indices are reserved for managing personas specifically associated with organizational entities, such as companies, DAOs, or other collective structures.
***** Client-Side Management Rules: Enforcing Security and Privacy
Client applications interacting with the protocol's identity system MUST adhere to a strict set of rules
1. *Account Discovery (Gap Limit):* Clients MUST implement a "Gap Limit" (a heuristic search window, typically 20) for account discovery. During recovery or initial synchronization, the client scans accounts 0' through `N'` (where `N'` is determined by the gap limit and activity) for active personas. If an active account is found, the scan window is intelligently shifted forward.
2. *Context Isolation:* Data associated with different accounts (e.g., contact lists, encryption keys, local indexes) MUST be stored in cryptographically isolated database partitions or encrypted with account-specific salts. This prevents accidental data leakage between contexts.
3. *Cross-Account Privacy:* Clients MUST NOT leak the relationships or activities between personas residing in different accounts unless explicitly authorized by the user (e.g., through a signed cross-account attestation Note).
4. *Independent Authentication:* Clients SHOULD allow users to set distinct local authentication requirements (e.g., PINs, biometric scans) for sensitive accounts (e.g., 1' Professional or 100' Organization accounts), providing an additional layer of security for critical digital identities.
***** Technical Implementation (Pseudocode)
```typescript
// Example: Account derivation from a Master Node (representing the Master Key)
const accountIndex = 0; // Defines the specific account (e.g., Primary)
const accountNode = masterNode.derivePath(`m/44'/1'/${accountIndex}'`);
// Example: Persona derivation within the chosen account
const personaIndex = 0; // Defines the specific persona within the account
const personaNode = accountNode.derivePath(`0/${personaIndex}`);
// Example: Key Generation for the derived Persona
// Ed25519 for secure digital signatures
const signingKey = ed25519.generateKeyPair(personaNode.privateKey);
// X25519 for robust cryptographic encryption
const encryptionKey = x25519.generateKeyPair(personaNode.privateKey);
```
** Personas
*** Personas: Your Active Digital Selves
*** Persona Keys
- Each Persona has its own Ed25519 keypair for signing and an X25519 keypair for encryption.
- Persona keys MUST be derived within the secure hardware (Secure Enclave/Keystore) when possible.
- Private keys MUST NEVER be exposed to application memory in plaintext.
- If a Persona key is compromised, it can be revoked and rotated without affecting the Master Key or other Personas.
*** Persona Governance & Operational Recovery
While the Master Key is an offline seed, Personas are active network agents governed by their own rules, smart contracts, and DID Documents. Operational recovery, succession, and governance occur at this layer and are defined via *Inception Policies* established at the moment the identity is created.
**** Recovery Guardian Dynamics: Natural Persons vs. Collectives
The protocol distinguishes between the dynamics of recovery for individual "natural person" Personas and "collective" or organizational Personas (e.g., companies, DAOs) when it comes to social recovery.
***** Natural Person Persona: The "Dictator with Safety Nets"
For a human, the design goal is Ultimate Sovereignty. You are the "Root." Even if you have "Recovery Friends," they should have no power over you unless you are incapacitated.
- *The Logic:* The Persona's primary operational key holds absolute priority weight (e.g., Weight 100). The "Recovery Friends" group has a collective weight of 100, but their actions are restricted by time-locks.
- *Unilateral Action:* A natural person Persona retains the right to change their recovery "friends" (guardians) even if those guardians do not explicitly consent to be "rotated out."
- *Mechanism:* Any rotation signed by the primary key is effective immediately. Rotation signed by the Escrow Group (Guardians) requires a 72-hour `Pending State` (Time-Lock) and can be cancelled by the user at any time. This ensures you can "fire" your recovery team instantly without asking for permission, as your weight alone meets the threshold.
***** Collective Persona: The "Protected Quorum"
For an LLC or NGO, the goal is Mutual Defense and preventing "hostile takeovers" where one founder kicks out others.
- *The Logic (Consensus Required):* All shareholder keys have defined, often equal weights (e.g., 3 shareholders, weight of 33 each).
- *The Rotation Rule (Governance Gate):* Thresholds for different actions are defined at inception. For example, a simple majority (51%) might be sufficient for daily operations, but changing the board or quorum requires a supermajority (e.g., 75% or 3-of-3 unanimity).
- *Veto Power:* The identity may designate a specific "Founder Key" that possesses Veto Power. This key must be among the required editors for *any* rotation event to be valid, making that individual impossible to remove without their own signature.
- *Protection:* This prevents a single member from seizing the company identity. Removing a member requires signatures from the quorum (e.g., 3-of-4), ensuring that "consent" is baked into the math of the threshold.
***** Identity Succession & Minors
The protocol handles the lifecycle of identity across generations.
- *Minor Onboarding:* For a minor, a parent or guardian Persona can "Co-sign" the identity inception event.
- *Succession Logic:* This link creates a pre-authorized recovery path where the parent holds a dormant weight that can be activated to rotate keys if the minor loses access, transitioning to full independence at a defined maturation date.
**** Legal Override & The "Break-Glass" Escrow (For Legal Entities)
To handle situations like the death of a sole founder, a lost key, or a binding court order without creating a central back door, the protocol implements a "Dormant Escrow" pattern specifically designed for Collective Personas or High-Value single Personas.
- *The Dormant Key:* At inception, the Persona's governance structure includes a "Public Key" belonging to a Neutral Third Party (e.g., a decentralized notary or a legal escrow service). This key is assigned a weight of `0` for daily operations.
- *Multi-Party (M-of-N) Escrow:* To prevent a single corrupt entity from hijacking an identity, the protocol utilizes a *Recovery Council*. For instance, a rotation might require 2-of-3 signatures from designated entities (e.g., a Notary, a Law Firm, and a Decentralized Oracle).
- *The Trigger:* The identity’s governing logic includes a rule: "If a certified Legal Attestation (e.g., signed by the local Court's Public Key) is presented, the Escrow Key's weight jumps to the necessary quorum threshold (e.g., 100) for a single Rotation Event."
- *Observer-First Transparency:* Any change to the master key—including a legal override—must be published to the *Key Event Log (KEL)*. This ensures it's impossible for an agent to "quietly" take over an account; every user device and hired "watchdog" service is alerted immediately.
- *The Veto Window (Time-Locking):* Any rotation event initiated by an Escrow Key triggers a mandatory 72-hour `Pending State`. If the primary owner still possesses their key (i.e., the agent is acting maliciously), they can sign a *Veto & Revoke* message. Because the Owner Key has absolute priority, this instantly kills the pending rotation and can strip the escrow agent of future rights. If the owner is incapacitated, they won't sign a veto, and after 72 hours, the change becomes final.
- *Empowerment through Pre-authorization:* This allows the law to intervene technically—not through "hacking," but via a pre-authorized, transparent mechanism agreed upon during the identity's inception.
**** The "Dead Man's Switch" (Protocol Level Recovery)
To prevent assets from being "lost forever" if a user disappears unexpectedly:
- *The Watcher:* A smart contract or a "Guardian Persona" monitors the user's on-chain and network activity.
- *The Trigger:* If the Persona DID has zero "Key Activity" for a defined period (e.g., 12 months), a pre-designated Inheritance Key is authorized to initiate a recovery rotation.
- *The Safety:* The user receives a "Warning Notification" (via DIDComm) every month leading up to the trigger. A single "Heartbeat" signature from their active phone resets the 12-month clock.
***** Against Founder Malice
- *Time-Locked Contracts:* Maturation date is immutable in Foundation Contract; founders cannot delay or prevent it.
- *Social Accountability:* Public attestations of maturation create social pressure against interference.
- *Legal Recourse:* Blockchain evidence of maturation provides evidence in legal disputes.
- *Fork Option:* If founders refuses to release keys, Persona can generate new identity and attest to the connection publicly.
***** Recovery During Stages
****** Before Key Introduction
- Founders fully control recovery (regenerate Persona keys).
- User SHOULD have Shamir shards among trusted guardians.
****** After Key Introduction, Before Maturation
- User holds own root backup; can recover independently.
- Founders can still recover if user loses key.
- *Both paths available:* Dual recovery for safety.
****** After Maturation
- Standard social recovery (Shamir's Secret Sharing with chosen guardians).
- No founder backup; full self-sovereignty.
- User SHOULD have hardware backups before maturation.
*** Wallet Integration (Ownership & Contracts)
Each Persona in the protocol is analogous to a legal person, possessing the inherent right and capability to own property, enter into contracts, and claim protected rights (freedom of speech, due process). Therefore, every Persona will have its own associated wallets (e.g., for BTC, Lightning, stablecoins, other digital assets). These wallets are controlled by the Persona's derived keypairs, making cryptographic ownership an integral part of its functional identity. Personas are thus fully enabled to manage digital assets and participate in the protocol economy.
*** Delegated Authoring & AI Personas
**** Owner DID vs. Editor DID: The Mechanism of Agency
The protocol distinguishes between the identity that owns the content and the identity that cryptographically signs it. While these are identical in most personal interactions, their separation enables complex organizational and recovery workflows.
- *Owner DID:* The source of authority, reputation, and ownership. This is the Persona "speaking" or "publishing." All social weight and historical context accrue to this DID.
- *Editor DID:* The cryptographic actor performing the signature, recorded within the Note's `proof` object. This is the entity "signing" the data. The network verifies that the Editor holds a valid Delegation Certificate or is an authorized recovery key for the Owner. If omitted from the `proof`, it defaults to the Owner DID (self-signed).
***** Key Use Cases for Separation
1. *Organizational Delegation (The Assistant Model):* An NGO (Owner DID) issues a Delegation Certificate to an employee, Alice (Editor DID). Alice publishes updates using her own keys, but the network attributes them to the NGO.
2. *AI Agent Accountability:* A Human (Owner DID) authorizes their personal AI Bot (Editor DID) to act on their behalf. Users can verify that a message is from the human while knowing it was technically generated and signed by their AI agent.
3. *Legal Override & Recovery:* When a user loses their keys, a pre-authorized Recovery Council (Editor DID) signs a Key Rotation Event for the Incapacitated User (Owner DID), restoring their digital presence.
4. *Guardianship:* A Parent (Editor DID) manages and signs events for a Minor (Owner DID) until a pre-defined maturation date.
***** Technical Benefits
- *Accountability:* Provides a transparent audit trail of the physical signers acting on behalf of an identity.
- *Granular Revocation:* An Owner can revoke an Editor's access instantly without needing to change their own identity or rotate master keys.
- *Reputation Portability:* Content history and social relationships stay with the Owner DID, regardless of which specific human or bot was authorized to sign at the time.
**** Cryptographic Delegated Signatures
To allow multiple individuals (e.g., employees) or autonomous agents to act on behalf of a single Persona (e.g., an LLC or a brand account) without sharing the Master Key, the protocol employs Delegated Signatures.
- *The Delegation Certificate:* The "Owner" Persona signs a special `Delegation Certificate` granting specific capabilities to a "Delegate" DID for a defined period.
- *Example Constraint:* "Delegate X can publish `is_feed: true` Notes on behalf of Owner Y, but cannot sign `contract` Notes."
- *The Signature:* When the Delegate acts, they sign the Note with their *own* private key and append the Delegation Certificate. The network validates the certificate against the Owner's public key.
- *Instant Revocation:* The Owner can instantly revoke the delegation by publishing a revocation event, cutting off the Delegate without needing to change passwords or rotate the Owner's keys.
**** AI Agent Personas (AAP)
The protocol treats Artificial Intelligence not as a backend feature, but as a first-class participant.
- *Agent DIDs:* An AI Agent is assigned its own derived Persona DID, completely separated from the human's primary identity.
- *Capabilities-Based Security:* Using the Delegation mechanism above, the human owner grants the AI Agent restricted capabilities (e.g., "Authorized to spend up to 5000 sats/month" or "Authorized to draft responses but not publish them").
- *Verifiable Origins:* Because the AI signs with its own DID, all network participants can instantly and cryptographically verify whether a piece of content was authored by a human or an AI.
*** Naming & Registry
**** Naming Tiers
***** The Local Alias (Tier 1)
- *Client-Side Only:* Every client allows users to assign private nicknames to DIDs in their contact list.
- *Privacy:* 100%. No one else knows what you call them.
- *Scope:* Private to the user.
***** The Global Registry (Tier 2)
- *Decentralized Ledger:* A name-to-DID mapping stored on a decentralized ledger (e.g., a simple L2 or a high-reputation PDS/Relay coalition).
- *Zooko's Triangle:* The protocol attempts to achieve names that are *Human-Readable*, *Secure*, and *Decentralized*.
- *First-Come, First-Served:* Names are registered by the first persona to claim them, with small micro-fees (1000+ satoshis) to prevent squatting.
***** The Subdomain Model (Tier 3: The "Default" Handle)
- *Domain-Based Names:* If a user doesn't own a custom domain, their PDS provider (e.g., a community hub) grants them a subdomain.
- *Format:* `username.provider.org` (e.g., `alice.aletheia.social`).
- *Handle Resolution Protocol:* The system MUST support multiple methods for resolving a human-readable handle to a DID:
- *Method A (DNS TXT):* The client queries the DNS for a TXT record at `_atproto.alice.aletheia.social`.
- *Method B (HTTPS Well-Known):* The client fetches the DID from `https://alice.aletheia.social/.well-known/atproto-did`.
- *Cross-Namespace Resolution:* The network's Search Indexers MUST implement a "Resolver Bridge" to handle other ecosystems. For example, if a search matches a `.eth` name, the indexer queries the ENS Smart Contract on Ethereum to find the associated DID.
- *Validation:* To prevent "spoofing," the DID document returned by the PDS MUST contain a back-link to the handle.
- *Sovereignty:* If you move your PDS to your own custom domain, you take your name with you.
**** Multi-Persona Naming Convention
Because users manage multiple Personas (Legal, Professional, Anonymous) derived from a single Master Seed, clients SHOULD implement a Persona-Suffix convention to distinguish them clearly within the Subdomain Model:
- *Primary/Legal:* `name.provider.org` (e.g., `john.aletheia.social`)
- *Professional:* `name-pro.provider.org` (e.g., `john-pro.aletheia.social`)
- *Anonymous/Alt:* `alias.provider.org` (e.g., `night-owl.aletheia.social`)
**** Web3 Naming Services (e.g., ENS)
For users who want a username entirely untethered from a specific PDS provider's domain, the protocol supports Decentralized Naming Services like Ethereum Name Service (ENS).
- *How it works:* The user registers a base name (e.g., `yourname.eth`). They can then generate unlimited subnames for their various Personas for free (e.g., `work.yourname.eth`, `social.yourname.eth`).
- *Portability:* If the user migrates their data to a new PDS, the `.eth` name stays with them. They simply update the "Content Hash" record on the blockchain to point to the new PDS location, ensuring unbreakable ownership of the handle.
*** Naming Registry Implementation
**** Implementation Options
***** Option 1: Simple L2 on Bitcoin/Lightning
- *Architecture:* Dedicated Lightning channel for name registration (similar to Lightning Addresses).
- *Process:* User sends 1000 sats + desired name to a specific "Name Registrar" Persona. Registrar publishes signed attestation (name -> DID) to a public PDS.
- *Verification:* Clients verify attestation against Registrar's DID.
- *Pros:* Low cost, high speed, leverages existing infrastructure.
- *Cons:* Registrar still a single point of failure for initial registration.
***** Option 2: Federated Registrar Network
- *Architecture:* M-of-N multi-sig collective of Name Registrar Personas.
- *Process:* User pays fee; M of N registrars sign attestation.
- *Pros:* Decentralized, more robust against single point of failure.
- *Cons:* Higher latency, more complex setup.
***** Option 3: Sidechain/Drivechain
- *Architecture:* Dedicated sidechain for name registrations.
- *Process:* Transaction on sidechain maps name to DID.
- *Pros:* High throughput, specialized functionality.
- *Cons:* New trust assumptions, requires sidechain security.
***** Decision: Option 1 (Simple L2 Registrar) for V1.0
- Prioritizes speed and simplicity for initial rollout.
- Recognizes that full decentralization of the Global Registry is a complex problem.
- Clients can choose their registrar.
**** Registrar Persona Requirements
- *DID:* Must be a well-known, high-reputation Persona.
- *API:* Standard API for name registration/lookup.
- *Fees:* Transparent and auditable fee structure.
- *Availability:* High uptime and low latency.
- *Audit:* Publicly auditable log of all name registrations.
*** Identity Linking
*** Verification Objects
- *Verification Objects:* A persona can publish a signed *Verification Object* linking their protocol DID to other identities (e.g., a PGP key, a personal domain, or even a centralized social profile).
- *Proof-of-Domain:* Proving ownership of a domain (via DNS record) is the gold standard for high-trust identity verification in the protocol.
*** Zero-Knowledge Proofs (ZKP) & Selective Disclosure
The system allows a user to "Attest" that two Personas belong to the same human (or hold the same credentials) *without revealing the Master Seed or creating a public cryptographic link*.
- *The Problem:* Your "Anonymous Developer" Persona wants to prove it has a "Verified Citizen" badge issued to your "Legal Name" Persona.
- *The ZKP Solution:* Using a Zero-Knowledge Proof, the user can cryptographically prove they hold the private key for the "Legal Name" DID (which holds the badge) and assert a statement on behalf of the "Anonymous" DID.
- *Privacy Preservation:* The resulting proof verifies the credential is valid but explicitly hides *which* specific Legal Name DID generated the proof.
**** Attribute-Based Predicate Proofs
The protocol extends ZKP capabilities beyond cross-persona linking to support *Selective Disclosure* and *Predicate Proofs* using Verifiable Credentials (VCs) with advanced cryptographic schemas (e.g., BBS+ signatures or AnonCreds). This allows Personas to prove attributes about their physical or financial reality without leaking metadata or underlying identifiers.
- *Age/Date Verification:* A Persona can cryptographically prove a predicate like `Age > 18` to access age-restricted content or contracts without revealing their actual date of birth.
- *Financial Ability:* A Persona can prove `Wallet Balance > 10,000 sats` or `Monthly Income > X` to serve as collateral or qualify for a service contract without revealing their exact balance or transaction history to the counterparty.
- *Citizenship & Residence:* A Persona can prove membership in a specific geographic jurisdiction (e.g., "Resident of New York") for local governance voting or tax-compliant commerce without disclosing their legal name or specific home address.
- *Asset Ownership:* A Persona can prove ownership of a specific Physical Asset Link (PAL) or digital token to gain entry to a gated community or guild without linking that high-value asset to their everyday public identity.
**** Verification Object Schema
#+begin_src typescript
interface VerificationObject {
// Identity linking DID
did: string;
// What external identity is being linked
identityType: 'domain' | 'pgp' | 'social_twitter' | 'social_github' | 'other';
identityIdentifier: string; // e.g., 'example.com', '0x1234...ABCD', '@amr'
// The cryptographic proof of control over the external identity
// - For domains: A signed string expected to be found in DNS TXT record
// - For PGP: A signature of the DID using the PGP key
// - For social: A URL to a public post containing the DID and signature
proof: {
proofType: 'dns_txt' | 'pgp_signature';
proofData: string;
};
// Protocol persona signature (proving the DID owner agrees to the link)
timestamp: number;
signature: string; // Ed25519 signature over the object
}
#+end_src
**** Problem Statement**
When a Persona's derived keys are compromised, lost, or need deactivation, users need a cryptographically verifiable mechanism to:
1. Invalidate the affected Persona
2. Preserve the Master Key and other Personas
3. Optionally migrate content history
4. Maintain network integrity
*** Identity Verifiability & Forward Security
Personas are the functional, active identities through which you engage with the protocol network. Each Persona is uniquely and cryptographically derived from your Master Key, acting as your distinct digital self for specific contexts. They are the sovereign participants in the network, fully empowered to own property, enter into binding contracts, publish content, and claim protected rights such as due process and freedom of expression. This section details the cryptographic derivation, secure management, revocation mechanisms, and identification systems that enable your Personas to operate seamlessly and securely within the broader protocol ecosystem.
*** Key Event Log (KEL): The Observer-First Transparency Log
Every Persona in the protocol maintains a Key Event Log (KEL). This is a public, append-only ledger of all identity-related events, including:
- *Key Events:* Inception, rotation, and revocation.
- *Follow Events:* Every time you follow another DID, a signed "Follow Event" is added to the log.
- *Transparency:* It is impossible to "quietly" take over an account or manipulate your public history. Any change to the keys or following relationships must be published to the log. Watchdog services can monitor this log and alert the user immediately if an unauthorized event is initiated.
**** Social Graph Reconstruction
The "Social Graph" (the list of DIDs you follow and who follows you) is mathematically reconstructible from the KEL.
- *The Proof:* Follow Events (Notes) are cryptographically signed by the Persona's authorized keys (or the Master Key).
- *The Rebuild:* When initializing a new PDS, the software scans the network and subscribed Relays for any signed Follow Events belonging to the user's DID. It automatically reconstructs the user's entire social graph (e.g., a list of 500 friends) without the user needing to remember a single username or manual backup.
*** Pre-rotation: Quantum-Resistant Continuity
The protocol utilizes the principle of *Pre-rotation* to ensure forward security as an ultimate fail-safe.
- *The Hash Commitment:* When a user creates their current active key, they simultaneously publish a cryptographic hash of their *next* (unborn) public key.
- *The Protection:* Even if an attacker breaks the user's current private key (e.g., via a future quantum computer, theft, or even a malicious legal override attempt), they cannot forge a rotation event because they do not know the private key corresponding to the pre-committed hash. Rotation only becomes valid when the user reveals the new key that matches the previous hash, providing true "forward security."
**** Technical Requirements
- *Interface:* Clients MUST support communication via *WebHID* (browser-based) or *USB/HID* (native) using the standard *APDU* (Application Protocol Data Unit) format.
- *Key Derivation:* The HSM MUST perform BIP-32/44 derivation internally.
- *Signing Protocol:*
1. Client sends unsigned Content Object hash to HSM.
2. HSM displays metadata (CID, Persona name) to user for confirmation.
3. Upon user approval, HSM signs hash using the specified Persona key.
4. HSM returns the Ed25519 signature to the client.
- *Master Key Security:* The 24-word mnemonic MUST be generated and stored exclusively within the HSM.
** Hardware Keys
*** The "Vault" Device Guide (For the Engineer)
The "Vault" is a dedicated application for an offline/hardware device that manages the Master Seed.
**** Functional Requirements for the Vault Tool:
- *Seed Generation:* Must use a high-entropy hardware RNG to generate the BIP-39 mnemonic.
- *Persona Derivation:* Must implement a hardened derivation logic where the user can "Export Persona #N."
- *Key Rotation Editor:* This is the most important feature. If a phone is lost, the Vault device creates a DID Update Transaction. This is a cryptographically signed message that says: "I am the Master Seed; I hereby revoke Persona Key A and authorize Persona Key B."
- *Recovery Seed Export:* The Vault should allow exporting a "Recovery Key"—a special key used specifically for the "Re-Wrapping" process on the PDS during content re-keying.
*** Hardware Integration: Sphinx for Your Keys
**** Technical Requirements
**** BIP-39 / BIP-44 Compatibility
Protocol-compatible hardware wallets MUST support the `m/44'/1'/` path. If the device does not support the custom `1'` coin type, clients MAY fallback to a generic data-signing path, but this is NOT recommended for production use.

826
projects/passepartout/social-protocol/requirements-03-infrastructure.org Normal file
View File

@@ -0,0 +1,826 @@
#+title: Social Protocol Requirements - 03: Infrastructure
#+author: Amero Garcia
#+created: [2026-03-16 Mon 14:28]
#+DATE: 2026-03-14
#+ID: agora-requirements-03-infrastructure
#+STARTUP: content
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 3b43a9b8-31d1-4479-a35f-22273b74f0c7
:END:
* The Sovereign Infrastructure: Your Digital Foundation
[[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Social Protocol]]'s infrastructure is meticulously architected to deliver on the promise of true digital sovereignty. Unlike traditional platforms that centralize control, the protocol distributes power to the edges—directly into the hands of users. This section details the foundational infrastructure that makes self-sovereign identity, data ownership, decentralized communication, and global discovery not just possible, but practical and scalable.
** Personal Data Store (PDS): Your Digital Fortress
The Personal Data Store (PDS) is the cornerstone of the protocol's sovereignty model—your personal, encrypted vault where all your Notes, identity data, and digital assets reside. Unlike cloud services that claim ownership of your data, your PDS is unequivocally yours. You control it. You host it. You decide who accesses it. It is the physical manifestation of your digital self-sovereignty.
*** Requirements
- The system MUST use a hybrid network architecture with Personal Data Stores (PDS) and Relays.
- Every user MUST control their own PDS (hosted or self-run).
- The PDS MUST serve as the master archive for all the user's content (encrypted) and identity data.
- The PDS MUST act as a gatekeeper, issuing decryption keys upon valid payment or credential verification.
- Relays MUST NOT store data long-term (unless paid to).
- Relays MUST route ciphertext based on CID and persona subscriptions.
- The system MUST incentivize Relays to route high-traffic content or provide specific delivery guarantees.
- The system MUST allow users to publish their CIDs to multiple relays to ensure availability and bypass censorship.
- The system MUST use Double Ratchet for 1-on-1 private messaging.
- The system SHOULD use MLS (Messaging Layer Security) for group chats.
- The system MUST use symmetric encryption for paywalled content (individual keys per object).
- The system MUST support social recovery using Shamir's Secret Sharing, allowing users to split their Master Key into shards distributed to trusted guardians.
*** Technical Logic
**** Personal Data Store (PDS)
- *Home Base:* Every user controls their own PDS (hosted or self-run).
- *Master Archive:* All the user's content (encrypted) and identity data live here.
- *Key-Server Separation:* The PDS MUST include a distinct Key-Management Module that handles the automated sale and distribution of decryption keys/LSATs. This MUST be logically separate from the Data-server hosting the encrypted blobs, ensuring that the entity holding the keys does not necessarily host the content payload.
- *Access Control:* PDS acts as a gatekeeper, issuing decryption keys upon valid payment or credential verification.
**** Encryption Model (E2EE)
- *Double Ratchet:* Used for 1-on-1 private messaging.
- *MLS (Messaging Layer Security):* Proposed for group chats.
- *Symmetric Encryption:* Used for paywalled content (individual keys per object).
- *Envelope Encryption (Data-at-Rest):* To protect against stolen devices, PDS storage utilizes Envelope Encryption. Large files are encrypted with a random Data Encryption Key (DEK), which is itself encrypted (wrapped) with the Persona Public Key.
- *Automated Re-Keying Service:* The PDS MUST include a background worker that triggers upon a `KEY_ROTATION_EVENT`. The worker iterates through KeyHeader objects and uses a Proxy Re-Encryption (PRE) scheme to securely re-wrap the DEKs with the new key, without ever exposing the raw Master Seed to the PDS.
*** Developer Implementation
To send a private message:
1. Encrypt message for the recipient's Persona Encryption Key (X25519).
2. Upload ciphertext to the user's PDS.
3. Notify the recipient's subscribed Relays of the new CID.
4. Recipient's client fetches the CID from the Relay/PDS and decrypts locally.
*** PDS Migration: Seamless Sovereignty Transfer
PDS Migration represents a fundamental capability of the protocol's architecture—the seamless, user-initiated transfer of one's entire digital corpus from one Personal Data Store to another. Unlike traditional platforms where data migration is often complex, permission-based, or impossible, the protocol treats PDS Migration as a first-class operation. This is not an edge case, but a core feature that ensures users retain ultimate sovereignty over their data throughout its lifecycle. Whether changing hosting providers, upgrading [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]], or responding to security incidents, PDS Migration ensures users are never trapped by infrastructure choices.
**** Concept
PDS Migration is the comprehensive process of transferring a user's entire encrypted content repository and identity data from one PDS to another while rigorously maintaining Content Identifier (CID) integrity, subscription continuity, and access control mechanisms. This process ensures that all cryptographic relationships between Notes remain intact, and that no data is lost or corrupted during the transfer.
Key principles of PDS Migration:
- *User Sovereignty Absolute:* Users retain complete autonomy to migrate their data without requiring permission, intervention, or cooperation from any third party. This is a fundamental right within the protocol ecosystem.
- *Zero-Downtime Operation:* Migration SHOULD occur without interrupting the user's ongoing presence or activities on the network. This ensures continuous availability of services and interactions.
- *Rollback Safety:* Users MUST have the capability to revert to the original PDS if the new PDS fails to perform adequately or if any issues arise during the migration process. This provides a safety net for critical data transfers.
- *Atomic Cutover:* There is a clearly defined, atomic moment when the new PDS becomes the authoritative source of truth, and the old PDS transitions to a backup role, ensuring data consistency.
Migration scenarios include a comprehensive range of use cases:
- Self-hosted PDS → Cloud-hosted PDS (moving from personal infrastructure to professional hosting)
- Cloud provider A → Cloud provider B (e.g., AWS → GCP, avoiding vendor lock-in)
- Old hardware → New hardware (self-hosted upgrade for improved performance or capacity)
- Compromised PDS → Clean PDS (security incident response and remediation)
- Cost optimization (migrating to more economical hosting solutions)
- Performance enhancement (migrating to geographically closer or faster infrastructure)
**** Requirements
- The system MUST support full PDS migration without service interruption.
- The system MUST preserve all Content Object CIDs during migration (content-addressed storage guarantees this).
- The migration process MUST update the Persona's DID Document to point to the new PDS service endpoint.
- The system MUST notify all subscribed Relays about the PDS endpoint change.
- The system MUST support parallel operation (old and new PDS active simultaneously) during migration testing.
- The system MUST provide migration progress tracking and verification.
- The system MUST support incremental pre-migration sync to minimize final cutover time.
- The system MUST handle in-flight messages during cutover (queue and forward).
- The system MUST provide a rollback mechanism if migration fails.
**** Migration Phases
***** Phase 0: Preparation
- *Prerequisites:* Ensure new PDS meets minimum specs (storage, bandwidth, availability).
- *Provisioning:* Configure new PDS with Persona's DID but initially in "standby" mode.
- *Authorization:* New PDS MUST prove ownership via Persona signature challenge.
***** Phase 1: Initial Sync
- *Full Replication:* Transfer all Content Objects from old PDS to new PDS.
- *CID Verification:* Block-by-block verification that all content transferred correctly.
- *Metadata Sync:* Sync Persona profiles, access control lists, and configuration.
- *Duration:* May take hours/days depending on data volume.
- *Old PDS Remains Authoritative:* Writes still go to old PDS during this phase.
***** Phase 2: Incremental Catch-up
- *Delta Sync:* Catch up changes made since Phase 1 started.
- *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
- *Freeze Writes:* Brief write lock on old PDS (seconds to minutes).
- *Final Delta:* Transfer last remaining changes.
- *DID Update:* Publish new DID Document with new PDS service endpoint.
- *Relay Broadcast:* Announce endpoint change to all subscribed Relays.
- *New PDS Becomes Authoritative:* Write traffic now routes to new PDS.
***** Phase 4: Stabilization
- *Monitor:* Observe new PDS for errors, dropped messages, or performance issues.
- *Verification:* Confirm all personas can reach new PDS, all content accessible.
- *Grace Period:* 24-48 hour buffer where old PDS remains available as hot standby.
- *Rollback Window:* If issues detected, can revert to old PDS via DID re-update.
***** Phase 5: Decommissioning
- *Archive:* Old PDS data backed up (user's discretion).
- *Tombstone:* Old PDS endpoint publishes redirect or shutdown notice.
- *Cleanup:* Remove old PDS from user's infrastructure (cancel cloud instance, retire hardware).
- *Final Verification:* Confirm no traffic routing to old PDS.
**** Technical Considerations
***** Concurrent Access During Migration
- *Read Replication:* Old PDS can serve reads while new PDS receives writes (after cutover) to reduce downtime to near-zero.
- *Message Queueing:* Relays queue messages during the brief cutover window; messages forwarded once new PDS confirms readiness.
- *Conflict Avoidance:* Strict sequencing ensures no split-brain scenarios (only one PDS accepts writes at any time).
***** Verification Protocol
- *CID Audit:* Iterate through all CIDs in Persona's content graph; verify retrievable from new PDS.
- *Signature Verification:* Spot-check Content Object signatures against Persona's public keys.
- *Access Control Verification:* Test decryption of sample encrypted content using Persona's keys.
- *Subscription Testing:* Verify Relays successfully forward new CIDs from new PDS.
***** Rollback Procedures
- *Trigger:* Migration fails verification or new PDS experiences critical failure.
- *DID Reversion:* Re-publish previous DID Document with old PDS endpoint.
- *Relay Re-announce:* Broadcast reversion to all Relays.
- *Data Reconciliation:* If any writes occurred on new PDS before failure, sync them back to old PDS before re-activating.
- *Graceful Degradation:* If both PDS fail, Persona can restore from backup and re-establish with same or new infrastructure.
**** Developer Implementation Example
#+begin_src typescript
// Initiate PDS migration sequence
interface PDSMigrationPlan {
sourcePDS: string; // Old PDS endpoint
targetPDS: string; // New PDS endpoint
personaDID: string;
phases: MigrationPhase[];
estimatedDuration: number; // Estimated seconds for full migration
rollbackDeadline: number; // Timestamp until rollback is possible
}
interface MigrationPhase {
name: 'preparation' | 'full-sync' | 'incremental' | 'cutover' | 'verification' | 'completed';
status: 'pending' | 'in-progress' | 'completed' | 'failed';
startedAt?: number;
completedAt?: number;
progressPercent: number;
}
// Phase 1: Full replication
async function replicateContentObjects(
sourcePDS: string,
targetPDS: string,
personaDID: string,
authToken: string
): Promise<ReplicationResult> {
const sourceClient = new PDSClient(sourcePDS, personaDID);
const targetClient = new PDSClient(targetPDS, personaDID);
// Fetch all CIDs from source
const allCIDs = await sourceClient.listAllCIDs();
// Batch transfer with verification
const results = await batchTransfer(allCIDs, {
source: sourceClient,
target: targetClient,
verifyCID: true, // Verify hash after transfer
batchSize: 100,
concurrency: 5
});
return {
transferred: results.successful.length,
failed: results.failed,
duration: results.elapsedTime
};
}
// Phase 3: Cutover - Update DID Document
async function executeCutover(
persona: Persona,
newPDSEndpoint: string,
oldPDSEndpoint: string
): Promise<CutoverResult> {
// 1. Freeze writes on old PDS
await freezeOldPDS(oldPDSEndpoint, persona.did);
// 2. Final incremental sync
await finalIncrementalSync(oldPDSEndpoint, newPDSEndpoint);
// 3. Update DID Document with new service endpoint
const updatedDoc = await updateDIDDocument(persona.did, {
service: [{
type: 'PDS',
serviceEndpoint: newPDSEndpoint,
// ... other service properties
}]
});
// 4. Sign and publish new DID Document
const signedDoc = await persona.sign(updatedDoc);
await didResolver.publish(signedDoc);
// 5. Notify all subscribed Relays
await notifyRelays(persona.did, {
type: 'PDS_ENDPOINT_CHANGE',
oldEndpoint: oldPDSEndpoint,
newEndpoint: newPDSEndpoint,
signature: signedDoc.proof
});
return { status: 'success', newDocumentCID: signedDoc.cid };
}
// Verification: Confirm all content accessible
async function verifyMigration(
newPDS: string,
personaDID: string,
expectedCIDCount: number
): Promise<VerificationResult> {
const client = new PDSClient(newPDS, personaDID);
// Verify CID count matches
const reachableCIDs = await client.listAllCIDs();
if (reachableCIDs.length !== expectedCIDCount) {
throw new Error(`CID mismatch: expected ${expectedCIDCount}, found ${reachableCIDs.length}`);
}
// Spot-check: verify random sample of CIDs
const sample = selectRandomSample(reachableCIDs, 100);
const verificationResults = await Promise.all(
sample.map(cid => verifyContentObject(client, cid))
);
const failures = verificationResults.filter(r => !r.valid);
if (failures.length > 0) {
throw new Error(`Verification failed for ${failures.length} objects`);
}
return { status: 'verified', sampleSize: sample.length, failures: 0 };
}
#+end_src
**** User Experience Considerations
- *Progress Dashboard:* Real-time view of migration progress with estimated time remaining.
- *Notification:* Alerts to user's clients about upcoming maintenance window (for cutover).
- *Zero-Click Resume:* If migration interrupted, resumes from last checkpoint automatically.
- *Cost Transparency:* Estimate bandwidth/storage costs before starting (especially for cloud-to-cloud).
- *Support Contact:* During migration, provide direct line to new PDS operator for issues.
**** Security During Migration
- *Authenticated Transfer:* All replication traffic encrypted and authenticated (mTLS or Noise).
- *No Plaintext Exposure:* Ciphertext transferred as-is; no decryption during migration.
- *Audit Trail:* All migration events logged as tamper-evident Content Objects.
- *Guardian Notification:* Optional: notify social recovery guardians of major infrastructure change.
- *Rate Limiting:* Prevent migration from overwhelming either PDS; throttle if needed.
*** PDS-to-PDS Synchronization: Redundancy and Resilience
In a truly sovereign digital ecosystem, users should never be constrained to a single point of failure. the protocol's PDS-to-PDS Synchronization protocol empowers users to run multiple Personal Data Stores simultaneously—for redundancy, load balancing, or geographic distribution. This protocol enables bidirectional synchronization of encrypted Content Objects between a user's PDS nodes, maintaining CID integrity, conflict resolution, and data consistency across the distributed infrastructure. It ensures that your digital presence remains resilient, available, and performant, regardless of individual infrastructure limitations.
**** Concept
The PDS-to-PDS Synchronization Protocol allows users to maintain multiple, synchronized copies of their encrypted data across different PDS instances. This capability transforms the PDS from a single point of failure into a distributed, fault-tolerant system that can withstand outages, attacks, or infrastructure changes. By synchronizing data across multiple nodes, users achieve:
- *High Availability:* If one PDS becomes unreachable, others can seamlessly serve data, ensuring continuous access to your digital identity and content.
- *Geographic Distribution:* PDS nodes can be strategically located in different regions to minimize latency and comply with local data sovereignty requirements.
- *Load Distribution:* High-traffic Personas can distribute read operations across multiple synchronized PDS nodes, improving performance and responsiveness.
- *Disaster Recovery:* Synchronized PDS nodes provide inherent backup capabilities, ensuring data preservation even in catastrophic failures.
**** Sync Protocol Architecture
**** Merkle DAG Synchronization
- Each PDS maintains a Merkle DAG of all stored Content Objects.
- Root hash represents complete state of the PDS.
- Sync compares Merkle roots to efficiently identify differences.
**** Sync Modes
**** Full Sync
- Complete synchronization of all Content Objects.
- Used for initial setup or recovery from desync.
- Sends all CIDs not present in the other PDS.
**** Incremental Sync
- Only synchronizes changes since last sync.
- Maintains sync cursor (last synced CID timestamp).
- More efficient for ongoing synchronization.
**** Selective Sync
- Synchronizes only specific content types or time ranges.
- User-defined filters (e.g., "only public posts", "last 30 days").
- Useful for bandwidth-constrained scenarios.
**** Sync Process
**** Phase 1: Handshake
- PDS nodes authenticate using Persona's DID.
- Exchange authentication proofs (signatures).
- Verify both nodes are authorized for this Persona's data.
- Exchange capabilities (sync modes supported, bandwidth limits).
**** Phase 2: Discovery
- PDS A computes Merkle root of current Content Object set.
- PDS B does the same.
- Compare roots: if equal, sync complete; if different, continue.
- Exchange Merkle proofs to identify divergent branches.
**** Phase 3: Delta Calculation
- Based on Merkle proof comparison, identify missing CIDs on each side.
- Calculate delta: set of CIDs A has that B doesn't, and vice versa.
- Partition delta into batches for transfer.
**** Phase 4: Transfer
- Request missing CID payloads from peer PDS.
- Receive Content Objects with full metadata.
- Verify CID integrity (content-addressed verification).
- Store in local PDS.
**** Phase 5: Conflict Resolution
- If same CID exists with different content (hash mismatch):
- Both versions preserved (content-addressed storage).
- Conflict marked for manual resolution.
- User interface shows both versions, user selects authoritative.
- If same CID exists with same content: no conflict.
**** Phase 6: Confirmation
- Both PDS nodes recompute Merkle roots.
- Verify roots match post-sync.
- Update sync cursor for incremental future syncs.
**** Sync Conflicts
**** Conflict Types
**** Write-Write Conflict
- Same CID modified differently on two PDS nodes simultaneously.
- Resolution: Keep both, mark secondary as "alternate version", user resolves.
**** Tombstone Conflict
- CID deleted on PDS A, modified on PDS B.
- Resolution: Configurable policy ("last write wins" vs. "preserve all").
**** Schema Conflict
- Content Object valid on PDS A but rejected by PDS B (schema mismatch).
- Resolution: Log error, quarantine object, notify user.
**** Periodic Synchronization
- *Frequency:* User-configurable (real-time, hourly, daily).
- *Real-time Sync:* WebSocket connection for immediate propagation.
- *Scheduled Sync:* Cron-like jobs for periodic full or incremental syncs.
- *On-Demand Sync:* Manual trigger by user or administrator.
**** Security Considerations
- *Authentication:* Both PDS nodes MUST authenticate as authorized for Persona's data.
- *Encryption:* Sync traffic SHOULD be encrypted (TLS 1.3 or Noise Protocol).
- *Authorization:* PDS nodes MAY implement additional access controls (IP allowlists).
- *Audit:* All sync events logged as Content Objects for audit trail.
**** Performance Optimization
- *Delta Encoding:* Only transfer missing CIDs and metadata.
- *Compression:* Payload compression for large Content Objects.
- *Parallel Transfer:* Multiple concurrent transfers for large datasets.
- *Resume:* Partial transfers resume from interruption point.
**** Implementation (TypeScript)
#+begin_src typescript
interface PDSSyncSession {
sessionId: string;
participantPDS: string[]; // PDS DIDs
personaDID: string;
mode: 'full' | 'incremental' | 'selective';
status: 'handshake' | 'discovery' | 'transfer' | 'complete' | 'error';
startedAt: number;
completedAt?: number;
}
interface MerkleNode {
cid: string;
children: MerkleNode[];
hash: string; // Blake3 hash of concatenated child hashes
}
interface SyncDelta {
fromPDS: string;
toPDS: string;
missingCIDs: string[];
conflictCIDs: string[];
estimatedSize: number; // Bytes
}
interface SyncConfig {
mode: 'full' | 'incremental' | 'selective';
filter?: {
contentTypes?: string[];
afterTimestamp?: number;
beforeTimestamp?: number;
publicOnly?: boolean;
};
frequency?: 'realtime' | number; // number = seconds between syncs
priority?: 'low' | 'normal' | 'high';
}
#+end_src
*** Distributed Mirroring & Social Resilience
**** Following: Default "Feed Gossip" & The Phoenix Effect
The protocol ensures baseline content resilience by leveraging a gossip-based mirroring architecture triggered by every "Follow" event.
- *Following = Essential Replicating:* When a user "follows" another Persona, their device or PDS automatically joins the gossip swarm for that target's most critical low-bandwidth data.
- *Feed Gossip Scope:* To balance network resilience with device resources, default gossip is restricted to the *Identity Log (KEL)* and a rolling window of *recent text-based Notes* (e.g., the last 1,000 posts).
- *The Phoenix Effect:* This level of mirroring ensures the "Phoenix Effect" remains viable. If a user's PDS is destroyed, they can "shout" to their followers: "I am the owner of DID:123. Please send me everything you have signed by my key." The essential history and social graph flow back from the community.
- *Censorship Resistance:* By making essential gossip a default behavior, the social graph and latest news stay alive through the "cracks" of the internet automatically.
**** Supporting: Opt-in "Supporter-Mirroring" & Decentralized CDN
For high-bandwidth content and deep archives, the protocol transitions from simple gossip to an explicit infrastructure donation model.
- *Persistent Mirroring:* When a user clicks "Support," they opt-in to a deeper technical commitment. The supporter's PDS archives the *entire historical feed* of the creator, not just the recent window.
- *High-Bandwidth "Pinning":* Supporters provide the backbone for the *"Follower-as-CDN"* model. A supporter can allocate specific storage (e.g., "Pin 5GB of latest video") to ensure large payloads (audio, video, high-res images) remain highly available.
- *WebRTC Peering & Seeding:* Supporters act as active "Seeds" in a BitTorrent-style swarm. When a new viewer watches a video, the app prioritizes streaming via WebRTC from online supporters rather than the creator's PDS, ensuring viral content has $0 infrastructure cost for the creator.
**** "In-Kind" vs. "Monetary" Support
This tiered model transforms the relationship between organizations and their communities:
- *Scalable In-Kind Support:* A "Poor but Loyal" follower contributes at the Gossip tier (bandwidth for text), while a "Dedicated Patron" contributes at the Mirroring tier (storage for video).
- *Resilience against De-platforming:* Even if a government blocks a creator's main server, the "Swarm" of followers and supporters continues to host and circulate the content through the P2P network.
**** Encrypted Peer-Backups (The "Friend-Box")
While the social swarm recovers public history, users ensure the recovery of private data (drafts, DMs) via formal peer-to-peer backup agreements.
- *The "Friend-Box" Logic:* Users can establish reciprocal "Friend-Box" agreements where they swap encrypted storage space (e.g., swapping 10GB of space with three trusted friends).
- *Mechanism:* The user's PDS automatically generates and sends an encrypted, compressed "State Snapshot" (a Merkle DAG of the entire PDS state) to these friends' servers periodically (e.g., nightly).
- *Privacy Guarantee:* Because the backup is encrypted with the user's keys, the friends cannot read the private drafts or DMs; they only host the raw ciphertext blobs.
- *Restoration:* In the event of a catastrophic local failure (e.g., fire, server loss), the user can download their latest snapshot from a friend and instantly restore their entire digital life to a new PDS node using their recovered Identity Keys.
** Relay Network: The Circulatory System of the Protocol
The Relay Network serves as the protocol's intelligent, adaptive message routing layer—ephemeral, user-chosen pathways that efficiently route encrypted Notes via a pub/sub model. Unlike centralized servers that store and monitor your data, Relays are transient routers that respect your privacy, delivering your messages without ever holding them long-term. They are the circulatory system of the protocol network, ensuring vital communication flows freely and securely.
*** Requirements
- Relays MUST route ciphertext based on CID and persona subscriptions.
- Relays MUST NOT store data long-term (unless paid to).
- The system MUST incentivize Relays to route high-traffic content or provide specific delivery guarantees.
- The system MUST allow users to publish their CIDs to multiple relays to ensure availability and bypass censorship.
- Relays MUST support subscription filters for content discovery.
*** Technical Logic
*** Relay Routing & Prioritization: Pay-to-Prioritize (P2P)
To ensure high-performance and sustainability without central control, the protocol's Relays utilize a *Pay-to-Prioritize (P2P)* routing strategy. Crucially, Relays are *Logic-Blind*. They do not inspect the Note's payload or contract terms (which may be encrypted). Instead, they prioritize traffic based on explicit, unencrypted metadata.
**** Explicit Priority Fee (The "Fast-Lane")
If a Note requires instant routing (e.g., a time-sensitive financial transaction or live chat), the sender can attach a Lightning micropayment directly to the routing request.
- *`priority_fee`:* A metadata field indicating the attached fee. Relays automatically move Notes with sufficient priority fees into the highest-speed queue.
- *Proof of Priority:* The fee *is* the proof. The Relay doesn't need to know *why* the Note is important, only that the sender is willing to pay for bandwidth.
**** Economic Density & Wire-Size Billing
Relays manage their resources using an *Economic Density* metric:
- *Sender Reputation (Zero-Fee Routing):* Small Notes from highly staked or reputable DIDs are often routed with zero additional fees to foster network liquidity and social interaction.
- *Low-Density (Large/Static):* Large Notes (e.g., binary payloads, media) are routed via *Bulk Pipes*. Billing for these Notes is proportional strictly to their raw payload size on the wire.
**** Incentivization
- Relays charge for routing high-traffic content or for specific delivery guarantees based on wire-size and explicit priority fees.
*** Relay Discovery
*** Relay Economics and Network Resilience
**** Relay Discovery
***** Bootstrap Problem
New clients need to find Relay nodes without hardcoded lists (centralization risk).
***** Discovery Mechanisms
****** DNS TXT Records
- Domain: `_agora-relay._tcp.example.com`
- Returns: List of relay endpoints (WebSocket URLs)
- Update: DNS propagation handles relay churn
****** Well-Known DID
- DID: `did:agora:bootstrap`
- Service Endpoint: "RelayDirectory" with list of known high-reputation relays
- Maintained: By Protocol Trust, updated quarterly
****** DHT (Future)
- Distributed hash table for relay discovery
- Similar to BitTorrent trackerless torrents
- Resistant to censorship
****** Social Bootstrap
- Friend's relay list shared on connection
- "You follow Alice → Oh, Alice uses Relay X, try that"
- Gossip protocol for relay reputation
**** Relay Subscription
***** Subscription Types
- *CID Filters:* Subscribe to new CIDs from specific DIDs
- *Topic Filters:* Subscribe to content with specific tags
- *Content-Type Filters:* Only contracts, only posts, etc.
***** Subscription Management
- *WebSocket:* Persistent connection for real-time updates
- *REST Poll:* HTTP polling for clients without WebSocket
- *Webhook:* Push notifications for server-side clients
***** Subscription Pricing
- *Basic:* Free (up to 100 subscriptions)
- *Premium:* 100 satoshis/month (unlimited)
- *Enterprise:* Negotiated (dedicated relay capacity)
**** Relay Operator Profiles
1. *"Backbone" Providers (Big Tech/NGOs):* Large organizations (e.g., Bluesky Social PBC or the "Free Our Feeds" collective) run "Global Relays," ingesting entire network activity for platform-wide search and indexing.
2. *"Neighborhood" Operators (NGOs & Communities):* NGOs, professional guilds, or town councils run community-specific relays, indexing only the members relevant to their specific domain.
3. *"Specialists" (Commercial Startups):* Companies (e.g., Primal, River) run highly-optimized relays to power specific apps, prioritizing speed and specialized feature sets for their target market.
**** Relay Economic Models
To ensure sustainability without compromising user data (avoiding "Surveillance Capitalism"), operators utilize diverse revenue models:
- *The "Anti-Spam" Entrance Fee:* One-time or monthly payments (e.g., $1–$5) via Bitcoin Lightning to discourage bot-farms and cover hardware costs.
- *The "Boutique" Model (Freemium):* Free "Read" access with a paid subscription required to "Write" (post data), often offering guarantees for data persistence and indexing quality.
- *Institutional "Public Good" Funding:* Government or NGO-funded "Public Interest Relays" provided as a digital utility to ensure censorship-resistant communication.
- *"Zaps" & Micro-tips:* Direct user-to-operator micro-tips via integrated Lightning Keys, rewarding relays for high-quality filters or specialized indexes.
**** Relay Pricing
***** Standard Price Announcement
- Relay publishes `price_per_kb` in Lightning millisats
- WebSocket endpoint: `/pricing` returns current rates
- Update frequency: Hourly, cached by clients
***** Pricing Tiers
- *Basic:* 1 millisat/KB (default routing)
- *Priority:* 10 millisats/KB (fast lane)
- *Bulk:* 0.5 millisats/KB (>100KB messages)
- *Free:* 0 millisats/KB (below 1KB, within rate limits)
***** Fee Structure
- *Relay:* Keeps 70% of fees (operating costs)
- *Validator Oracles:* 20% (fraud detection)
- *Protocol Protocol:* 10% (development fund)
**** Network Resilience: Global Firehose vs. Fragmented Relays
The social protocol's design ensures that the relay network is inherently replaceable and resilient:
- *Replaceable Relays:* Users can instantly switch to competitor relays if a provider becomes greedy or censorious by simply re-pointing their PDS.
- *"Multi-homed" Data (Firehose Protection):* Users push posts to multiple relays simultaneously. If any relay fails, history remains accessible via others, ensuring followers can always maintain connectivity.
*** Privacy Considerations: The "Honeypot Relay" Risk
Because a relay is fundamentally a server that routes traffic, it is technically possible for an operator to offer a "free" service while secretly harvesting metadata to sell to advertisers. This creates the risk of "Honeypot Relays" during the network's early bootstrap phase.
**** The Metadata Harvesting Trap
Even if messages are End-to-End Encrypted (E2EE), a malicious relay can observe highly valuable metadata for surveillance capitalism:
- *IP Addresses:* Revealing the user's physical location and device profile.
- *The Social Graph:* Observing who a DID communicates with, how often, and who constitutes their "inner circle."
- *Activity Patterns:* Tracking when a user is active, sleeping, and which tags/topics they frequently query.
- *Unencrypted Content:* Building interest profiles based on public posts and read-only data.
**** Defense Against Decentralized Surveillance
While Honeypot Relays pose a risk, their power is fundamentally weaker than legacy Web 2.0 walled gardens:
1. *No Walled Garden (Instant Migration):* If a relay is discovered to be harvesting data, users simply uncheck a box in their PDS settings. They migrate to a new relay instantly, and their followers find them immediately because their identity (DID) remains constant.
2. *Fragmented Data:* Because users multi-home their data across several relays simultaneously, no single relay possesses the "whole picture" of a user's digital life.
3. *The Tor/VPN Option:* Advanced users and organizations can run their PDS traffic through Tor or a VPN, stripping away the IP address—the most valuable piece of surveillance data.
**** Organizational Defense: The Tiered Relay Strategy
For Collectives, NGOs, or LLCs managing sensitive operations, relying on "free" public relays is an unacceptable security risk. These entities MUST utilize a Tiered Relay Strategy:
- *Tier 1 (Internal Relay):* The NGO runs its own private, isolated relay exclusively for internal board and team communications. This relay is "dark" to the public internet and collects zero metadata for third parties.
- *Tier 2 (Public Gateway):* The organization uses high-traffic "Surveillance" or public relays solely for PR, marketing, and public announcements. They treat these relays like digital billboards—expected to be public, but never used for private business.
**** Relay Reputation
- *Uptime:* % availability over last 30 days
- *Latency:* Message propagation time
- *Censorship:* Has relay blocked legal content?
- *Fees:* Reasonable pricing?
- *Users:* Number of active personas (network effect)
** Search & Indexing: The Firehose Indexers
In a [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][decentralized network]], finding historical content or discovering new Personas requires specialized indexing infrastructure. Indexing Nodes are high-performance servers that ingest the public Relay firehose to provide full-text search and complex discovery services.
*** Requirements
- Indexing Nodes MUST ingest public Content Objects from the Relay firehose.
- Indexing Nodes MUST support full-text search across public metadata and decrypted public content.
- The system MUST provide a standardized Search API for clients to query indexes.
- *The Aggregator API:* The standard endpoint MUST support an open querying format (e.g., `GET /search/query?q=keyword`) returning a structured schema of DIDs, Handles, and Profile snippets.
- *Ranking Transparency:* The provider MUST publish its Ranking Logic (e.g., "We prioritize accounts with 3+ Web-of-Trust endorsements") so users understand the algorithmic biases of the index.
- Indexing Nodes MUST respect content flags (e.g., `indexable: false` or `ephemeral`).
- The system MUST support "Private Indexing," where a user's PDS builds a local search index for their own encrypted history and DMs.
*** Technical Logic
- *Public Indexing:* Backbone providers run global indexers using technologies like Meilisearch or Elasticsearch to enable "Google-like" search for the whole platform.
- *Private Indexing:* Thin clients delegate private search tasks to the user's PDS, which maintains a local, encrypted index of all authorized Content Objects.
- *Economics:* High-speed indexing services MAY utilize micro-payments (Lightning) or subscriptions for advanced query capabilities or higher rate limits.
*** Persona Discovery & The Global Directory
To solve the UX problem of finding friends in a decentralized namespace, Indexers act as a Global Directory, constantly cataloging Handle <-> DID mappings broadcast over the network.
**** Multi-Format Handle Indexing
When a user searches for "@alice," the Indexer searches across all supported namespace formats simultaneously:
- *Subdomains:* `alice.aletheia.social`
- *Custom Domains:* `alice.com`
- *Web3 Names:* `alice.eth` or `alice.p2p`
**** Verified Search Results (Anti-Squatting)
Because anyone can theoretically publish a Note claiming to be "Alice," the Search UI relies on DIDs to guarantee authenticity.
- *Cryptographic Back-Links:* The Search engine ONLY displays a "Verified" checkmark if the human-readable handle (e.g., `alice.com`) has a valid cryptographic DNS/TXT record pointing back to the Persona's DID, *and* the DID has published a signed Note claiming that handle.
- *Unverified Flagging:* If a user squats on a username without owning the corresponding domain or blockchain record, the Indexer explicitly flags the search result as "Unverified" or excludes it.
**** "Privacy-First" Search
Because the social protocol supports multiple isolated Personas per user, global search is strictly opt-in:
- *Public Personas:* (e.g., a "Work" or "Creator" Persona) publish a "Directory Opt-In" Note. Indexers catalog them, making them searchable by anyone.
- *Private Personas:* (e.g., an "Anonymous" or "Family" Persona) do not publish this Note. They are entirely hidden from global Indexers. To find a Private Persona, another user must possess their exact DID string or be invited via a secure DIDComm routing channel.
** Social Protocol-to-Web Gateways: The Bridge to the Open Web
*** Concept
To make decentralized, P2P content accessible to users on the "Open Web" (traditional browsers like Chrome or Safari without special plugins), the social protocol must bridge the gap between Content-Addressed Data (CIDs) and Location-Addressed URLs.
Gateways act as "translators" sitting on the edge of the decentralized network, talking HTTP to the legacy web while speaking P2P protocols internally. Every PDS or dedicated "Public Relay" can act as a web gateway.
*** 1. The HTTP Gateway (The Bridge)
**** Public Gateway API & URL Mapping
A piece of content identified by its hash (CID), such as `bafy...123`, can be viewed by anyone at a standard HTTP URL.
- *Pathing:* Gateways MUST support standard pathing `/ipfs/{cid}` and `/at/{did}/{collection}/{rkey}`.
- *CORS Policy:* Gateways MUST implement a permissive CORS policy to allow decentralized applications (dApps) to fetch media directly across origins.
- *MIME-Type Sniffing:* The gateway MUST read the Universal Event metadata and serve correct HTTP headers (e.g., `Content-Type: video/mp4`) so browsers handle the media natively.
**** The Translation Process
When a browser hits that link, the Gateway performs the following automated steps:
1. *Fetch:* Retrieves the data from the P2P swarm using the social protocol's native protocols.
2. *Verify:* Cryptographically verifies the Note's signature against the creator's Persona DID to ensure authenticity.
3. *Wrap:* Wraps the raw content (Markdown, JSON) in standard HTML/CSS templates so it renders correctly in a standard web browser.
*** 2. Human-Readable Handles (DNS & ENS)
Most users will not share long cryptographic hashes. To make content web-friendly, Gateways automate domain routing.
**** DNSLink (Traditional Domains)
Users can point their own domains (e.g., `alice.com`) directly to their Persona.
- *Automatic Resolution:* When someone visits `alice.com`, the Gateway reads a DNS TXT record that says: "Go find content hash XYZ on the social protocol network."
- *Zero-Configuration SSL:* Gateways automatically provision and renew HTTPS certificates (via Let's Encrypt) for any domain linked to a Persona DID.
- *Well-Known Verification:* Gateways automatically serve the user's DID document at `https://[custom-domain]/.well-known/atproto-did` to prove ownership.
**** Automated Subdomain Issuance (Registrar Service)
To onboard users quickly without forcing them to buy a domain, PDS providers act as Registrars.
- *Availability & Routing:* The PDS performs an automated availability check. If a handle is free, it updates its Virtual Host configuration and internal DNS to instantly route traffic for `newuser.provider.org`.
**** Web3 Domains (.eth, .p2p)
For users utilizing blockchain-based naming services, the social protocol integrates with specialized gateways (e.g., Eth.limo). A user types `yourname.eth.limo` into a standard browser, and the gateway does the heavy lifting of resolving the blockchain record and serving the underlying P2P data.
*** 3. Social Mirroring for Search Engines (SEO)
To ensure social protocol content is discoverable on legacy search engines like Google, the network utilizes automated rendering pipelines.
**** The Firehose
Social protocol Relays emit a continuous "Firehose" of every public Note created on the network.
**** SEO Rendering (App Views)
Specialized indexers or "App Views" (functioning like web-frontends) consume this firehose. They automatically generate static, crawlable HTML pages for every public profile, post, and thread. This ensures that decentralized content is aggressively indexed by Google's web crawlers, matching or exceeding the discoverability of traditional centralized blogs.
*** 4. Persona-as-Host (Native Web Hosting)
Because of this robust Gateway architecture, publishing a website becomes a native feature of the network.
- *Static Asset Resolver (SAR):* The PDS/Gateway can interpret a directory CID as a web root. If a request hits a folder CID without a filename, the SAR automatically serves `index.html`. It resolves all internal assets (images, CSS) using Relative Pathing to ensure the site works regardless of the gateway domain.
- *Automated Deployment (Push-to-Publish):* Developers can use Git integration. When code is pushed, a CI/CD action builds the site, signs the resulting root CID with the Persona Key, and broadcasts the Publish Event to the PDS.
- *Instant Rollbacks:* Every Publish Event is logged in the Persona's immutable history. Reverting a site is simply signing a new Note pointing back to a previous CID.
*** Monetized Static Sites (Split-State Encryption)
Gateways integrate with the Exchange layer. Owners can host static sites where certain paths are encrypted. The Gateway serves the public storefront, but the actual asset is only "unwrapped" locally if the user's browser provides a Lightning Preimage (LSAT) proving payment.
*** Requirements
- Gateways MUST take CID-based social protocol content and render it as HTML for legacy browsers.
- Gateways MUST support SEO-friendly rendering for public content.
- The system MUST allow anyone to run a Gateway (not restricted to Relay operators).
- Gateways MUST NOT require authentication for public content.
- Gateways SHOULD cache content to reduce load on PDS/Relay networks.
- The system MUST support Gateway discovery (similar to Relay discovery).
- Gateways MUST respect content flags (e.g., `indexable`, `ephemeral`).
- Gateways MUST NOT expose private/direct content.
*** Relationship to Relays
- *Relays* serve protocol-native clients via WebSocket/pub-sub protocols.
- *Gateways* serve legacy browsers via HTTP.
- They are *separate infrastructure* - a Gateway may use Relays as a backend, but they're distinct services.
*** Gateway Discovery
**** Concept
Gateways bridge social protocol content to the legacy web via HTTP. Discovery mechanisms are needed for clients to find reliable gateways to generate shareable HTTP links for their public content.
**** Discovery Mechanisms
***** Public Registry
- A well-known DID (e.g., `did:agora:gateways`) maintains a list of verified, active gateways.
- Clients can query this registry to get a randomized or latency-sorted list of active gateways.
***** DNS TXT Records
- Similar to Relay discovery, domains can publish `_agora-gateway._tcp` TXT records pointing to HTTP endpoints.
***** User Preference
- Users can manually configure a preferred gateway in their client settings (e.g., `agora.example.com`).
- Clients use this preferred gateway when generating "Share Link" URLs.
** Infrastructure Discovery: DID Document Bindings
For a Persona to function within the network, its Decentralized Identifier (DID) must "bind" to specific infrastructure endpoints. This is achieved via the `service` section of the social protocol DID Document.
*** The Service Schema
Every social protocol DID Document SHOULD include a list of service endpoints that allow other Personas and clients to locate the user's data and communication channels.
#+begin_src json
{
"id": "did:agora:123...",
"service": [
{
"id": "#pds",
"type": "AgoraPDS",
"serviceEndpoint": "https://pds.example.org"
},
{
"id": "#relay",
"type": "AgoraRelay",
"serviceEndpoint": "wss://relay.aletheia.social"
},
{
"id": "#search",
"type": "AgoraSearch",
"serviceEndpoint": "https://search.agora-backbone.net"
}
]
}
#+end_src
*** Resolution & Routing Logic
1. *Discovery:* When a client wants to interact with a Persona, it first resolves the DID to its latest DID Document (via the KEL or a resolver).
2. *Binding:* The client extracts the `AgoraPDS` endpoint to fetch content and the `AgoraRelay` endpoint to subscribe to real-time updates.
3. *Failover:* If a primary PDS is unreachable, the client attempts to resolve alternative endpoints if provided in the service list (supporting the multi-homed data model).
** Client Architecture: PDS-Proximate / Thin Client Model
*** Concept
The social protocol's architectural strategy for client applications aims to balance user sovereignty with broad accessibility and app store compliance. Instead of relying solely on "sovereign clients" (full-featured applications running entirely on edge devices), a hybrid approach will be adopted: core client logic will reside closer to the Personal Data Store (PDS), with only a "thin client" deployed on edge devices (e.g., mobile apps, web browsers). This allows for greater flexibility in distribution and development.
*** Motivation: App Store Compliance & Broad Reach
Traditional "sovereign client" models, where full application logic, data processing, and cryptographic operations occur entirely on the user's edge device, can encounter significant hurdles with mainstream app stores (e.g., Apple App Store, Google Play Store). These platforms often impose restrictions on:
- Custom cryptographic implementations
- Direct access to underlying network protocols
- Data storage and handling outside platform-defined sandboxes
- Features deemed to circumvent platform monetization or control
The PDS-proximate / thin client model is a pragmatic solution to navigate these limitations, enabling the social protocol to reach a wider user base through conventional app distribution channels without compromising core protocol principles.
*** Strategic Advantages
1. *Enhanced App Store Compliance:* A thin client, functioning primarily as a user interface and communication layer with the PDS, is less likely to violate app store guidelines, increasing the likelihood of approval and sustained availability.
2. *Reduced Edge Device Footprint:* Lower computational, memory, and storage requirements on mobile phones and other edge devices. This translates to better performance, lower battery consumption, and broader compatibility across a range of hardware.
3. *Streamlined Updates & Maintenance:* Core application logic and feature updates can be deployed directly on the PDS or associated infrastructure, minimizing the need for frequent client-side app store updates and accelerating development cycles.
4. *Enriched PDS Functionality:* The PDS evolves from a passive data archive into a more active, "smart" personal server capable of hosting and executing significant portions of the client application logic. This allows for more sophisticated features (e.g., advanced indexing, content processing, AI integration) to run efficiently on behalf of the user.
5. *Greater Platform Portability:* A thin client model naturally facilitates deployment across diverse platforms, including web browsers (via WebAssembly or JavaScript), minimal native mobile wrappers, and potentially embedded systems, ensuring a consistent user experience.
*** Architectural Considerations & Challenges
1. *PDS Reliability and Performance:* The user experience becomes intrinsically linked to the performance, uptime, and responsiveness of the PDS. Robust PDS implementations and reliable hosting options are paramount.
2. *Privacy and Trust Model:* While the PDS is personal to the user, moving client logic there means processing occurs "off-device." End-to-end encryption must remain a fundamental guarantee, ensuring the PDS only handles encrypted data where sensitive information is concerned. User control over the PDS becomes the primary locus of sovereignty.
3. *Offline Capabilities:* Thin clients will inherently have limited or no offline functionality, as they rely on real-time communication with the PDS. Strategies for graceful degradation and cached read-only access for essential data will be necessary.
4. *Definition of "Thinness":* A clear architectural specification is required to define the boundary between client logic executed on the PDS and the minimal essential logic (e.g., basic key management, UI rendering) that must reside on the edge device for security and usability.
*** Conclusion
The adoption of a PDS-proximate / thin client architecture is a strategic imperative for the social protocol to achieve mass adoption and navigate the complexities of modern app distribution, while simultaneously enhancing the capabilities of the Personal Data Store as a dynamic and powerful extension of the user's digital self.
** Related Documents
- [[id:f6cfc54b-919b-4311-bcbf-65e976755d40][The Primitive]] - Content Object structure and core encryption primitives.
- [[id:0f949f6c-4cf1-49eb-b9a4-ebcac27ee548][Social]] - Messaging models, social publishing, and the attention marketplace.
- [[id:6fe67db6-25bd-4d11-bd1d-b44ec809e858][Identity]] - Master Key (Psyche) and Persona governance.
- [[id:90484f4a-5b70-4001-93d6-e610e54ed573][Exchange and Contracts]] - Economic primitives, fee structures, and the SCAL layer.
** Gaps
- *None.* All identified gaps in the infrastructure layer have been resolved.

432
projects/passepartout/social-protocol/requirements-04-the-primitive.org Normal file
View File

@@ -0,0 +1,432 @@
#+title: Social Protocol Requirements - 04: The Primitive
#+author: Amero Garcia
#+created: [2026-03-16 Mon 14:28]
#+DATE: 2026-03-15
#+ID: agora-requirements-04-the-primitive
#+STARTUP: content
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: f6cfc54b-919b-4311-bcbf-65e976755d40
:END:
* The Primitive: The Atomic Foundation of [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Social Protocol]]
** Concept: The Universal Data Primitive
The Primitive is the protocol's foundational content layer—the base data structure upon which all social interaction, economic exchange, and identity management is built. Before there are posts, contracts, or profiles, there are Notes. The Note is the atomic, universal unit of information in the protocol.
This elegant simplicity—the "Everything is a Note" paradigm—enables the protocol's powerful interoperability, immutable audit trails, and seamless cross-application compatibility. By reducing all digital interactions to a single, cryptographically verifiable primitive, the protocol creates a unified ecosystem where any application can understand and process any data, breaking down the silos that plague traditional digital platforms.
** The Note Structure
A Note is the atomic unit of information in the social protocol. Everything—posts, messages, contracts, profiles—is a Note with behavioral flags.
*** Technical Specification
Every Note is identified by its CID (Content Identifier):
- *Format:* CIDv1 with configurable codec and hash (Default: `dag-pb` + `sha2-256`).
- *Property:* Same content = same CID (deterministic).
- *Immutability:* Content cannot change without CID changing.
#+begin_src json
{
"cid": "string", // Unique content identifier
"owner": "DID", // Source of authority (Persona DID)
"is_feed": boolean, // Behavioral Intent: Chronological Flow (true) vs Static Page (false)
"contract": { ... }, // Optional: Rules of engagement (JSON Object)
"payload": "string", // Optional: The asset (Inline data or P2P CID)
"content_type": "string", // MIME type (e.g., text/markdown, image/jpeg)
"priority_fee": integer, // Optional: Relay routing priority (millisats)
"access_control": ["DID"], // Permissions (Omitted=Personal, []=Public)
"notify": ["DID"], // Attention (Target entities for push notifications)
"references": ["CID"], // Semantic links/citations
"reply_to": "CID", // Parent CID (for threading/negotiation)
"thread_root": "CID", // Root CID of the conversation/exchange
"ephemeral_duration": integer, // Expiry in seconds (0 = persistent)
"createdAt": "timestamp", // ISO-8601 creation time
"proof": { // Cryptographic authenticity
"editor": "DID", // Optional: The signer (defaults to owner)
"signature": "string" // Signature over Note content
}
}
#+end_src
** Behavioral Intent & Schema Validation
The single `is_feed` property defines the behavioral intent of a Note without changing its underlying technical structure.
*** Core Behavioral Intent
| Property | Type | Description |
|------|---------|----------|
| `is_feed` | boolean | Chronological timeline item (Post, Status, Update). If false/omitted, the Note is a static Page. |
*** The Contract & Payload Split
Every signed Note in the social protocol is inherently a contract. To clearly separate the "Rules of Engagement" from the "Asset", the Note structure defines two distinct fields:
- *`contract` (JSON Object):* Defines the terms. This includes both human-readable terms (e.g., `"license": "CC0"`) and machine-readable state (e.g., `"price_satoshis": 5000`).
- *`payload` (Polymorphic String):* Defines the asset governed by the contract. This can be:
1. *Inline Data:* Raw text, markdown, or small base64 blobs embedded directly.
2. *P2P Reference (CID):* A URI (e.g., `ipfs://Qm...`) pointing to a distributed Merkle DAG hosted by the PDS or the Swarm.
*** Audience & Visibility (access_control)
The visibility and routing of a Note are determined by the `access_control` array:
- *Personal (Private):* Omitted or `null`. The Note remains internal to the PDS.
- *Public (Broadcast):* Explicit empty array `[]`. The Note is pushed to all subscribed Relays for global indexing.
- *Restricted (Directed):* Array of target DIDs `["did:agora:bob"]`. The Note is routed only to the specified recipients.
*** Attention & Intent (notify)
The `notify` array defines who should receive a push notification or "Inbox" alert for the Note:
- *Personal/Silent:* Omitted or `null`. No entities are notified.
- *Targeted Ping:* Array of target DIDs `["did:agora:bob"]`. Triggers a notification for the specified entities.
*** Semantic Derivations
Because the social protocol uses a minimalist flag system, high-level social and economic concepts are reconstructed by clients using core flags, audience scope (`access_control`), and Note relationships (`references`, `reply_to`, `notify`).
**** Basic Content
- *Public Post:* `is_feed:true` + `access_control:[]`
- *Private DM:* `access_control:["did:agora:bob"]` + `notify:["did:agora:bob"]`
- *Static Page:* `is_feed:false` + `access_control:[]`
- *File:* A Note with a binary `content_type` (e.g., `image/jpeg`).
**** Social Graph & Interaction
- *Like / Reaction:* A Note that `references` a Content CID and contains a reaction payload. Typically `is_feed: false`.
- *Boost / Repost:* A Note that `references` a Content CID with `is_feed: true`, injecting it into the owner's chronological timeline.
- *Follow:* A Note that `references` a Persona DID.
- *Public Mention:* `access_control:[]` + `notify:[Target_DID]`.
- *Private Connection:* `access_control:[Target_DID]` + `notify:[Target_DID]`.
**** Economic & Contract Lifecycle
- *Contract Negotiation (Offer/Take/Task):* A Note represents a proposal (*Offer*), an acceptance (*Take*), or a commitment to perform work (*Task*) depending on its place in the `reply_to` chain.
- *Economic Lifecycle (Invoice/Payment/Escrow):*
- *Invoice*: A Note with a payment request in its `contract` (`price_satoshis`).
- *Payment*: A fulfillment Note (`Take`) containing cryptographic proof (e.g., `preimage`).
- *Escrow*: A Note referencing a multi-signature threshold in its `contract`.
- *Support / Subscribe:* A Note referencing a Persona DID, establishing a recurring payment stream or premium access in its `contract`.
**** Events & Coordination
- *Event Announcement:* A Note (usually `is_feed: true`) where the `contract` defines temporal/spatial rules (start time, location, capacity).
- *Invite:* A directed Note (`access_control: [DID]`, `notify: [DID]`) that `references` an Event Announcement. It serves as a contract *Offer* for attendance.
- *RSVP:* A Note that `reply_to` an Invite. The `contract` field contains the acceptance state (`{"rsvp": "attending"}`), acting as a *Take*.
*** Flag Combination Rules
The social protocol implements strict validation to ensure network integrity.
**** Rule 1: Flow (Feed vs. Page)
- `is_feed: true` indicates chronological content.
- `is_feed: false` (default) indicates static resource.
**** Rule 2: Audience Scope
- *Public Broadcast:* MUST use an explicit empty array `access_control: []`.
- *Restricted Routing:* MUST provide at least one recipient DID in `access_control`.
- *Personal:* Omission of `access_control` defaults to private storage on the PDS.
**** Rule 3: Requirements & Dependencies
- *Ephemerality:* The presence of `ephemeral_duration > 0` indicates the Note is ephemeral.
- *Restricted Access:* If `access_control` is populated, both the `contract` and `payload` SHOULD be encrypted into a single envelope for the specified audience.
*** Technical Specification (JSON Schema)
#+begin_src json
{
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "https://agora.ai/schemas/content-flags.json",
"title": "Social Protocol Note Flags",
"description": "Validation schema for the Binary Core flag set",
"type": "object",
"properties": {
"cid": {
"type": "string",
"description": "Unique content identifier.",
"pattern": "^[a-zA-Z0-9]+$"
},
"owner": {
"type": "string",
"description": "DID of the owner persona.",
"pattern": "^did:agora:[a-zA-Z0-9]+$"
},
"is_feed": {
"type": "boolean",
"description": "Chronological timeline item (Post/Update). If false, it's a static Page.",
"default": true
},
"contract": {
"type": "object",
"description": "Optional rules of engagement governing the payload (e.g. [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][licensing]], price).",
"additionalProperties": true
},
"payload": {
"type": "string",
"description": "The asset content (inline or P2P reference CID)."
},
"content_type": {
"type": "string",
"description": "MIME type of the content.",
"enum": [
"text/plain",
"text/markdown",
"text/html",
"application/json",
"image/jpeg",
"image/png",
"image/gif",
"video/mp4",
"audio/mpeg",
"application/pdf",
"application/zip",
"application/jwe"
]
},
"priority_fee": {
"type": "integer",
"description": "Relay routing priority in millisats.",
"minimum": 0
},
"access_control": {
"type": "array",
"description": "Determines audience. Omitted=Personal, []=Public, [DIDs]=Restricted.",
"items": {
"type": "string",
"pattern": "^did:agora:[a-zA-Z0-9]+$"
}
},
"notify": {
"type": "array",
"description": "Targets for push notifications.",
"items": {
"type": "string",
"pattern": "^did:agora:[a-zA-Z0-9]+$"
}
},
"references": {
"type": "array",
"description": "CIDs of related content objects.",
"items": {
"type": "string",
"pattern": "^[a-zA-Z0-9]+$"
}
},
"reply_to": {
"type": "string",
"description": "CID of content this is a reply to. Required for reply types.",
"pattern": "^[a-zA-Z0-9]+$"
},
"thread_root": {
"type": "string",
"description": "CID of the root post in a thread.",
"pattern": "^[a-zA-Z0-9]+$"
},
"ephemeral_duration": {
"type": "integer",
"description": "Duration in seconds for ephemeral content. If 0 or omitted, the Note is persistent.",
"minimum": 0,
"maximum": 31536000
},
"createdAt": {
"type": "string",
"format": "date-time",
"description": "ISO-8601 creation timestamp."
},
"proof": {
"type": "object",
"description": "Cryptographic proof of authenticity.",
"properties": {
"editor": {
"type": "string",
"description": "Optional: DID of the signing persona. Defaults to owner if omitted.",
"pattern": "^did:agora:[a-zA-Z0-9]+$"
},
"signature": {
"type": "string",
"description": "Ed25519 signature over content hash.",
"pattern": "^[A-Za-z0-9+/]+=*$"
}
},
"required": ["signature"]
}
},
"additionalProperties": false
}
#+end_src
** Content Lifecycle & Persistence
*** Encryption: Security by Design
Security is woven into the fabric of the protocol. The social protocol uses industry-standard primitives to ensure that only intended recipients can access private content.
- *End-to-End Encryption (E2EE):* Private Notes use AES-256-GCM for payloads and X25519 for ECDH key exchange.
- *Forward Secrecy:* The social protocol employs Double Ratchet for 1-on-1 messaging and MLS (Messaging Layer Security) for groups, rotating keys per-message.
*** Ephemeral Content Enforcement
The `is_ephemeral: true` flag is enforced through three complementary mechanisms:
1. *Time-Locked Encryption (Primary):* Payloads are encrypted with keys that can only be retrieved from a Decentralized Key Management Network (DKMN) or solved via a Time-Lock Puzzle before the expiration time.
2. *Key Shedding (Forward Secrecy):* For DMs, the client securely deletes the specific message key after the display duration expires.
3. *Voluntary Infrastructure Compliance:* PDS nodes MUST garbage collect expired CIDs, and Relays MUST drop them from routing tables.
*** Note Persistence (PDS)
- *Home Base:* All Notes are stored in the owner's Personal Data Store (PDS) by default.
- *Availability:* Content is hosted by the PDS, replicated across mirrors, and cached by Relays/clients for performance.
- *Lifecycle:* Create → Store (PDS) → Announce (Relay) → Fetch → Decrypt → Render.
** Relationships, Sync & Performance
*** Note Relationships
The social protocol uses three distinct fields to define relationships between Notes, balancing semantic precision with high-performance discovery.
**** Threading & Reference Logic
- *`references` (Array, 0-N):* General semantic linking. This field is used for citations, user mentions, quoting other posts, or attaching auxiliary Content Objects. It tells the network: "This Note is related to these other things."
- *`reply_to` (Single, 0-1):* Direct parentage. This field is mandatory for any Note that is part of a branching conversation. It defines the exact hierarchy for UI indentation and determines which owner should receive a notification.
- *`thread_root` (Single, 0-1):* The Global Anchor. This points to the very first Note that initiated the entire conversation. It allows clients to fetch thousands of replies in a single batch query, avoiding the "N+1 fetch" performance bottleneck.
***** Comparison Summary
| Field | Cardinality | Primary Role | UI Impact |
| :--- | :--- | :--- | :--- |
| *`references`* | Array (0-N) | Citation/Linking | Link previews, mentions |
| *`reply_to`* | Single (0-1) | Parentage | Nesting/Indentation |
| *`thread_root`* | Single (0-1) | Grouping | "View Full Thread" performance |
***** Example Implementation Scenario
Alice posts a product listing (Note A). Bob asks a question (Note B) about the listing. Charlie replies to Bob (Note C) but also quotes Alice's original product photo (Note D) in his comment.
*Charlie's Note (Note C) logic:*
- `thread_root`: CID of Note A (The listing anchor).
- `reply_to`: CID of Note B (The immediate parent).
- `references`: [CID of Note B, CID of Note D] (The citations).
*** Large Payload Handling
- *Streaming Protocol:* Files >100MB are split into 1MB chunks and represented as a Merkle DAG.
- *Streaming CIDs:* The root CID points to the tree, allowing concurrent, prioritized downloading of chunks.
*** Real-time Sync & Collaboration
- *Live Collaboration:* The social protocol uses CRDTs (Conflict-free Replicated Data Types) for shared state (e.g., co-editing a document).
- *Ephemeral Channels:* Real-time updates (like typing indicators) are broadcast via Relay WebSockets without being committed to the PDS as permanent Notes.
*** Content Deduplication
- *Block-level Deduplication:* Since payloads are content-addressed, PDS nodes only store identical data once, using reference counting to manage garbage collection.
** Validation Reference (Examples)
*** Valid: Public Post
#+begin_src json
{
"cid": "QmPost123",
"owner": "did:agora:alice",
"is_feed": true,
"contract": {
"license": "CC-BY-4.0"
},
"payload": "Hello, Social Protocol!",
"content_type": "text/markdown",
"access_control": [],
"createdAt": "2026-03-25T14:30:00Z",
"proof": {
"signature": "abc123..."
}
}
#+end_src
*** Valid: Private DM
#+begin_src json
{
"cid": "QmDM456",
"owner": "did:agora:alice",
"payload": "eyhbGciOiJkaXIiLCJlbmMiOiJBMjU2R0NNIn0...",
"content_type": "application/jwe",
"access_control": ["did:agora:bob", "did:agora:alice"],
"notify": ["did:agora:bob"],
"createdAt": "2026-03-25T14:35:00Z",
"proof": {
"signature": "def456..."
}
}
#+end_src
*** Valid: Digital Storefront (Split-State Encryption)
#+begin_src json
{
"cid": "QmStore789",
"owner": "did:agora:alice",
"is_feed": false,
"contract": {
"title": "Exclusive Indie Film",
"price_satoshis": 50000,
"decryption_method": "LSAT"
},
"payload": "ipfs://QmEncryptedVideoChunks...",
"content_type": "application/vnd.agora.encrypted+video/mp4",
"priority_fee": 1000,
"access_control": [],
"createdAt": "2026-03-25T14:40:00Z",
"proof": {
"signature": "xyz012..."
}
}
#+end_src
*** Valid: Ephemeral Story (Public)
#+begin_src json
{
"cid": "QmStory789",
"owner": "did:agora:alice",
"is_feed": true,
"payload": "This disappears in 24 hours",
"access_control": [],
"ephemeral_duration": 86400,
"createdAt": "2026-03-25T14:45:00Z",
"proof": {
"editor": "did:agora:bot_agent",
"signature": "ghi789..."
}
}
#+end_src
*** Invalid: Broadcast Conflict
#+begin_src json
{
"cid": "QmInvalid001",
"access_control": [],
"payload": "encrypted-blob-here",
"content_type": "application/jwe"
}
#+end_src
Validation error: Public broadcast (`access_control: []`) cannot contain an encrypted payload.
*** Invalid: Restricted without Audience
#+begin_src json
{
"cid": "QmInvalid002",
"notify": ["did:agora:bob"]
}
#+end_src
Validation error: Notifications (`notify`) require the target DID to be present in the `access_control` list or for the Note to be public.
** Related Documents
- [[id:6fe67db6-25bd-4d11-bd1d-b44ec809e858][Identity]] - Personas and contracts
- [[id:3b43a9b8-31d1-4479-a35f-22273b74f0c7][Infrastructure]] - PDS and Relay
- [[id:0f949f6c-4cf1-49eb-b9a4-ebcac27ee548][Social]] - Relationships and communication
- Exchange (see Exchange and Contracts spec) - Economic layer
** Gaps
- *None.* All identified gaps in the primitive layer have been resolved.
# Local Variables:
# org-confirm-babel-evaluate: nil
# End:

185
projects/passepartout/social-protocol/requirements-05-social.org Normal file
View File

@@ -0,0 +1,185 @@
#+title: Social Protocol Requirements - 05: Social Space
#+author: Amero Garcia
#+created: [2026-03-16 Mon 14:28]
#+DATE: 2026-03-15
#+ID: agora-requirements-05-social-space
#+STARTUP: content
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 0f949f6c-4cf1-49eb-b9a4-ebcac27ee548
:END:
* Social Space: Where Human Connection Becomes Sovereign
The Social Space is where [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Social Protocol]]'s revolutionary architecture transforms how humans connect, communicate, and transact. Unlike traditional platforms that own your relationships and monetize your attention, the protocol puts you in complete control of your social graph. Every interaction—from a casual conversation to a binding commercial contract—is self-owned, cryptographically secured, and entirely under your sovereignty. This is social interaction reimagined for a decentralized future.
** Concept
Social Space encompasses all person-to-person and person-to-collective interaction in the protocol: public and private, asynchronous and real-time. All social interaction is mediated by Notes and contracts running on the Exchange layer.
** Asynchronous Communication (Correspondence & Messaging)
Asynchronous communication in the protocol utilizes the *Secure Communication Module (SCM)*, which enforces the *DIDComm v2 (Decentralized Identifier Communication)* protocol—a transport-agnostic standard for secure, private communication.
- *Message Format:* All private messages MUST be formatted as JWM (JSON Web Messages).
- *Encryption Suite:* JWMs MUST be wrapped in a JWE (JSON Web Encryption) envelope, utilizing X25519 for key agreement and AES-256-GCM for content encryption.
*** The Mailbox (PDS as Proxy)
Because a user's primary device (e.g., a phone) is not always online, the PDS acts as an encrypted "Post Office" or proxy for asynchronous messages.
- *Sending:* The sender encrypts the Note using the recipient's Persona Public Key (retrieved from their DID Document).
- *Routing & Asynchronous Forwarding:* The encrypted JWE envelope is sent to the Service Endpoint listed in the recipient's DID Document. The PDS MUST support the DIDComm `Forward` message type, acting as an encrypted relay for offline delivery.
- *Storage:* The PDS stores the encrypted envelope. Because it is encrypted for the recipient's key, the PDS cannot read the content.
- *Pickup:* When the recipient's device wakes up, it fetches the envelope from the PDS, decrypts it locally, and deletes the copy from the PDS.
*** Contextual Isolation
The protocol enforces strict multi-persona isolation. Each Persona (e.g., "Work," "Dating," "Personal") has a separate, cryptographically isolated message queue. A message sent to a user's Work DID never touches the inbox or metadata of their Dating DID, ensuring zero cross-context leakage.
** The Unified Note Primitive
All asynchronous interaction in the protocol—whether a public post or a private message—is built upon the same "Note" primitive. The behavior and visibility of a Note are defined by cryptographic signatures and a set of standardized metadata flags.
*** Flag Definitions & Storage Models
| Flag | Meaning | Storage Model |
|------|---------|---------------|
| `access_control: []` | Broadcast (Public) | Reference-on-Send (authoritative on owner's PDS) |
| `access_control: [DIDs]` | Restricted (Private) | Copy-on-Send (authoritative on each recipient's PDS) |
| `is_feed: true` | Chronological entry (Post/Update) | Varies (e.g., public feed items are Reference-on-Send) |
| `is_feed: false` | Static resource (Page/Wiki) | Reference-on-Send |
*** Ephemeral Content
Notes where `ephemeral_duration > 0` are automatically garbage-collected by the PDS and dropped from routing tables by Relays after the duration expires.
*** Structural Integrity
Every async interaction is a Note identified by a Content Identifier (CID). This ensures that the history of a conversation or content stream is immutable and cryptographically verifiable.
** Directed Communication (Copy-on-Send Model)
For Notes intended for specific recipients (e.g., 1-on-1 messages, group chats), the protocol employs a "Copy-on-Send" model to ensure recipient data ownership and high availability.
*** Audience & Attention
- *Audience:* Defined by the `access_control` array. These entities have the cryptographic right to own and decrypt the Note.
- *Attention:* Defined by the `notify` array. These entities receive a push notification or "Inbox" alert for the Note.
*** Mechanism
When an owner sends a directed Note (`access_control: [DIDs]`), a unique, encrypted copy is generated for each recipient and stored on their respective PDSs. The sender also retains a copy on their PDS.
*** Data Ownership
This model ensures recipients have full ownership and control over the messages they receive. Access to the Note is independent of the sender's PDS status after the initial send.
** Social Publishing: Feeds & Streams
For content intended for a broad audience (e.g., social posts, public articles, project wikis), the protocol uses a "Reference-on-Send" model to maximize efficiency and owner control.
*** Concept: Feed vs. Stream
- *The Feed:* A Persona's curated output of chronological entries (`is_feed: true`) and static resources (`is_feed: false`).
- *The Stream:* A user's personalized, aggregated view of all the Feeds they follow.
*** The "Lens" Architecture (Polymorphic UI)
Because all data in the protocol shares the exact same base schema (The Atomic Note), client applications are not locked into "siloed" databases. Instead, data is a single pile of uniform "bricks." The client app acts as a *Lens* that filters this stream and adjusts its interface based on the Note's internal metadata.
- *Unified Content Schema:* Apps do not maintain separate APIs for videos, products, or posts. They read the universal Note structure.
- *Dynamic Interfaces:* The UI interprets the `content_type` and `contract` fields to render the appropriate experience:
- If `content_type: "video/mp4"` (and duration is short): The UI enables a "TikTok-style" vertical scroll and auto-play.
- If `content_type: "audio/mpeg"`: The UI switches to a "Podcast" player with 1.5x speed and background play.
- If the `contract` contains `price_satoshis`: The UI injects a "Buy Now" button linked to a Lightning Invoice.
- *Fluid Content (Multiple Lenses):* Because the data is distinct from the UI, a single Note can be viewed through completely different lenses simultaneously. For example, a 10-minute video Note:
- One user views it through a *"YouTube Lens"* (displaying comments via `reply_to` links and related videos).
- Another views it through an *"Educational Lens"* (where a specific algorithm has filtered it alongside academic papers).
- A third user streams just the audio track through a *"Podcast Lens"* while driving.
*** Mechanism
When an owner creates a broadcast Note (`access_control: []`), it is stored authoritatively on their Personal Data Store (PDS). Interested parties (followers, caching Relays) receive a notification containing the Note's CID. Their clients then *pull* the content using that CID.
*** Owner Control
The authoritative copy resides solely on the owner's PDS. Deletion by the owner renders all references to that CID inaccessible across the network, providing a sovereign "Right to be Forgotten."
*** Content Types
- *Feed Entries (`is_feed: true`):* Chronological posts, status updates, and news articles.
- *Static Pages (`is_feed: false`):* Wikis, documentation, and personal profiles.
** Synchronous Communication (Live Voice & Video)
For real-time calls, the protocol utilizes *WebRTC* with a decentralized twist for the signaling phase.
*** Decentralized Signaling
Traditional WebRTC requires a central signaling server to help devices discover each other. In the protocol, the *DIDComm channel* handles the handshake:
1. *Request:* Persona A sends a "Call Request" via DIDComm to Persona B's PDS.
2. *Negotiation:* Persona B's phone receives the request and sends back its IP/ICE candidates (the "digital map") via the same secure DIDComm channel.
3. *P2P Tunnel:* Once the handshake is complete, voice/video data flows directly between the two devices. No server—not even the PDS—sees the call data.
*** Off-the-Record (OTR) Mode
To address the need for absolute privacy and deniability, OTR mode completely bypasses PDS storage.
- *Mechanism:* Encrypted channels exist only in volatile client memory for the duration of the session.
- *Persistence:* No persistent record is kept on any PDS or local client cache.
- *Recording:* Clients MUST explicitly prevent any recording when in this mode.
** Encryption & Metadata Privacy
The protocol's communication layer goes beyond standard end-to-end encryption to ensure long-term security and metadata protection.
*** Double Ratchet Algorithm (Signal Protocol)
Every single message uses a new, derived key. This ensures *Perfect Forward Secrecy (PFS)* and *Post-Compromise Security*. If a specific message key is ever compromised, it cannot be used to decrypt past or future messages in the conversation.
*** Metadata Masking (Onion Routing)
To hide traffic patterns from network observers, the protocol utilizes Tor-style *Onion Routing* between PDSs where possible. This masks who is talking to whom, preventing external observers from building a social graph based on connection frequency or message timing.
** Profiles
*** Concept
A Profile is a public-facing presentation of a Persona. The protocol supports multiple Profiles per Persona (e.g., a "Public Developer" profile and a "Private Family" profile).
*** Requirements
- Each Profile MUST be a Note (CID) with public visibility.
- Profiles MUST be discoverable via the Naming Registry.
- Profile updates create new CIDs, preserving a verifiable history of the identity's presentation.
*** Profile as Static Site
Personas can publish their profiles and professional portfolios as decentralized static websites using the native hosting model (see [[id:3b43a9b8-31d1-4479-a35f-22273b74f0c7][Infrastructure]]). Protocol-aware browsers render these natively from CIDs, while legacy browsers access them via Gateways with automated SSL and domain mapping.
** The Attention Marketplace (The Information Router)
In traditional social media, the algorithm is a secret "Black Box" that sits between users and their social graph, deciding what is seen to maximize platform revenue. In the protocol, the Algorithm Layer is reimagined as an open *Information Router*. By moving the algorithm out of the central server and into an open market, the protocol empowers users to "hire and fire" the logic that sorts their attention.
*** Pluggable Feed Generation (PFG)
Users subscribe to independent "Feed Generators" via an open API. This decoupling of data from sorting logic is achieved through a three-step workflow:
1. *The Skeleton Request:* When a user opens their application, the client sends a request to a user-chosen Feed Generator (which can be operated by anyone—an NGO, a scientist, or a community collective).
2. *The Skeleton Response:* The Generator does not possess the user's private data. It returns a "Skeleton"—a lightweight JSON list of Content Identifiers (CIDs) that its specific logic has prioritized.
3. *Hydration:* The client application takes this list of IDs and "hydrates" the feed by pulling the actual Note content directly from the distributed PDS/Relay network.
*** The Algorithm Marketplace
Because the PFG API is open and transport-agnostic, different organizations compete to provide the best curation and routing services:
- *Academic Lenses:* Scientists or universities can provide generators that prioritize peer-reviewed content and primary sources.
- *Community Curators:* Local neighborhoods or professional guilds can run generators that surface the most relevant news for their specific domain.
- *Verification Services:* NGOs or fact-checking collectives can provide "Filtered Lenses" that prioritize highly-attested content.
*** Decentralized Moderation (Competitive Labeling)
Moderation in the protocol is treated as "Competitive Labeling" rather than central censorship.
- *Labeler DIDs:* Independent services (NGOs, Fact Checkers, Church Groups) operate as "Labelers." They review the public firehose and "tag" content (e.g., "Spam," "Graphic," "High-Quality").
- *Client-Side Filtering:* The user's application pulls these public labels and applies the user's personal policy (e.g., "Hide anything labeled 'Graphic' by the NGO 'SafetyFirst'").
- *Stackable Moderation:* Users can subscribe to multiple labelers simultaneously to create a highly personalized, robust, and sovereign moderation filter.
*** Circular Economy: Following as Investment
Lightning micro-payments allow for a self-sustaining attention economy.
- *Incentivized Curation:* Feed Generators can charge micro-fees (millisats) for their routing and sorting services.
- *Creator Support:* "Following" a creator becomes an act of economic investment and infrastructure support, bypassing the need for extractive advertising models.
*** Decentralized Moderation (Stackable Labelers)
Moderation is treated as "Competitive Labeling." Users subscribe to multiple Labelers (AI agents, NGOs, fact-checkers) to create a composite moderation profile tailored to their values.
** Social Governance & Moderation
*** Multi-layered Moderation
1. *Individual:* Publisher controls their own content and PDS.
2. *Community (Social Governance):* Collective rules enforced via governance modules (GEM).
- *Global Blocklists:* Communities can vote on shared moderation policies. If a quorum (e.g., 70% of an NGO's members) flags a specific DID as a "Spam Bot," that DID is automatically added to a Global Blocklist and hidden from all participating members' feeds.
- *Curated Feeds:* A community can vote to "Pin" certain content creators to a shared "Featured" feed, effectively acting as a decentralized editorial board.
3. *Algorithm:* User-chosen filtering and sorting via PFG and Competitive Labeling.
4. *Network:* Protocol-level consensus for universally illegal content (e.g., CSAM).
** Related Documents
- [[id:90484f4a-5b70-4001-93d6-e610e54ed573][06: Exchange and Contracts]] - Economic layer and human connection formalization.
- [[id:6fe67db6-25bd-4d11-bd1d-b44ec809e858][02: Identity]] - Personas and Master Keys.
- [[id:3b43a9b8-31d1-4479-a35f-22273b74f0c7][03: Infrastructure]] - PDS and Relays.

310
projects/passepartout/social-protocol/requirements-06-exchange-and-contracts.org Normal file
View File

@@ -0,0 +1,310 @@
#+title: Social Protocol Requirements - 06: Exchange
#+author: Amero Garcia
#+created: [2026-03-16 Mon 14:28]
#+DATE: 2026-03-15
#+ID: agora-requirements-06-exchange
#+STARTUP: content
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 90484f4a-5b70-4001-93d6-e610e54ed573
:END:
* Exchange
** Concept
The Exchange layer provides the economic substrate of [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Social Protocol]]: value transfer via the Lightning Network, multi-currency support, and payment primitives. Built on top of Content Objects (see [[id:f6cfc54b-919b-4311-bcbf-65e976755d40][The Primitive]]) and Social relationships (see [[id:0f949f6c-4cf1-49eb-b9a4-ebcac27ee548][Social]]).
** Lightning Native
** Base Currency
Lightning Network (Bitcoin L2) is the default payment rail:
- *Minimum:* 1 satoshi
- *Maximum:* Channel capacity limited
- *Speed:* Near-instant for settled payments
- *Cost:* Fraction of a cent per transaction
** Payment Types
**** One-shot Payment
- Single payment for content or service
- Invoice generated, payment fulfilled, preimage reveals
**** Streaming Payment
- Continuous micropayments (per-second, per-action)
- Used for subscriptions, metered services
- Automatic via HTLC stream
**** Hodl Invoice
- Escrow with hash-locked release
- Payment committed but conditional on secret
**** Keysend
- Spontaneous payment without invoice
- Used for tips, donations
** Lightning Node Architecture
The specification currently lacks explicit guidance on how end users run Lightning nodes. Below are the three architectural options under consideration:
**** Option 1: Embedded LDK Node (Self-Sovereign)
- Each user's client (desktop/mobile) runs an embedded Lightning node using LDK (Lightning Dev Kit)
- User has full custody of keys; channels are mobile-friendly (LSP-managed)
- PDS handles the always-online requirement since user devices aren't
- Aligns with the protocol's "sovereign" philosophy but requires technical sophistication
**** Option 2: LSP (Lightning Service Provider) Model
- User connects to an LSP that provides inbound liquidity and accepts payments on their behalf
- User still has signing keys locally; LSP manages channels and uptime
- User can switch LSPs without losing funds (Lightning hygiene)
- Most realistic for mobile users; PDS providers may bundle LSP services
**** Option 3: Custodial Bridge (On-ramp)
- PDS offers built-in custodial Lightning wallet for users who don't want self-custody
- Users can withdraw to self-custody later (exit guarantee)
- Default for new users, opt-in for sovereignty
- Trade-off: convenience vs. full sovereignty
**** Key Distinction: Custody vs. Hosting
Non-custodial means *you* control the private keys, not where the software runs. Even if the Lightning node runs on hosted PDS infrastructure, it can still be *your* node with *your* keys:
- Your PDS gets encrypted data (content)
- Your Lightning node gets encrypted state (channel backups)
- Both are encrypted to *your* keys
- The PDS provider cannot sign transactions or spend your funds
**** GAP: Decision Required
The specification has not yet decided between:
- Requiring all users to run embedded nodes (sovereign, high technical barrier)
- Defaulting to LSP connections (practical, retains key custody)
- Offering custodial as default with opt-out (maximum adoption, sovereignty trade-off)
*Next Step:* Evaluate technical feasibility of LSP integration with PDS providers and document recommended architecture for V1.0.
** Multi-Currency Support
** Supported Currencies
- *Lightning (default):* For micro-payments (<$1)
- *On-chain Bitcoin:* For settlements, channel opens
- *Stablecoins (RGB):* USDT/USDC on Bitcoin L2
** Currency Routing
- Client specifies desired currency
- PDS may support conversion
- Exchange rates oracle-attested
** Concept
The protocol must support multiple currencies beyond Lightning-native satoshis to facilitate broader economic participation and provide stability options. While Lightning remains the primary rail for micro-payments, other assets will be integrated for larger transactions and specific use cases.
** Supported Currencies
**** Lightning Network (L2 Bitcoin)
- *Role:* Primary for all micro-payments (typically <$10).
- *Mechanism:* BOLT-compatible invoices, streaming payments, Keysend.
**** On-chain Bitcoin
- *Role:* For large settlements, channel opens/closes, long-term value storage.
- *Mechanism:* Standard Bitcoin transactions, multi-sig escrow.
**** Stablecoins
- *Role:* For price stability, high-volume transactions, fiat-pegged value.
- *Mechanism:* RGB protocol on Bitcoin (future), wrapped assets on compatible L2s, or direct integration with atomic swaps.
** Currency Routing & Conversion
**** Client-Side Preference
- Users specify preferred payment currencies for sending and receiving.
- Clients automatically attempt conversion if sender's and receiver's preferred currencies differ.
**** PDS/Relay Support
- PDS nodes MAY offer automated currency conversion services (e.g., satoshis to stablecoins).
- Fees for conversion MUST be transparent and competitive.
- Conversion services MUST be auditable (using attestations).
**** Exchange Rate Verification (Oracle)
- The system MUST use a decentralized oracle network to attest to current exchange rates.
- Exchange rate attestations are signed Content Objects.
- Clients verify oracle signatures and rate validity before conversion.
** Integration with Contracts
- Contracts (e.g., Sale, Service) MUST specify accepted currencies.
- Prices in contracts MUST be expressed in a base unit (e.g., satoshis) with optional equivalent in other currencies.
- Exchange rates for contract execution MUST be based on oracle attestations at time of execution.
** Economic Primitives
** Invoice
- BOLT-11 compliant
- Amount, memo, expiry
- Static (LNURL) or dynamic
** Payment
- Preimage proof of settlement
- Content-addressed for audit trail
- Refundable if escrowed
** Account
- DID-linked balance tracking
- Multi-currency support
- Reconciliation with on-chain
** Fee Structure
** Relay Fees
- Per-message routing (configurable)
- Subscription-based access
- Priority delivery premium
** PDS Fees
- Storage: per-GB per month
- Bandwidth: per-request or per-GB
- Compute: for AI, indexing
** Marketplace Fees
- Owner-defined (0-30%)
- Universal Open Market: minimal (relay costs)
** Exchange Primitives
** Escrow
Hold funds until conditions met:
- 2-of-3 multisig (buyer, seller, arbitrator)
- HTLC hash-time-locked contracts
- Smart contract on compatible L2
** Subscription
Ongoing economic relationship:
- Streaming Lightning payments
- Permissioned content access
- Automatic key provision
** Bounty
Payment for task completion:
- Escrowed funds
- Completion attestation
- Oracle verification option
** Sovereign Contract & Arbitration Layer (SCAL)
To enable Personas to execute binding agreements with decentralized dispute resolution, the protocol implements SCAL. A contract in this system is not a static PDF; it is an executable cryptographic object.
*** 1. The Ricardian Contract Module
[[id:b265f66d-f7b9-4ebd-b4e3-a82cefe23981][Social Protocol contracts]] follow the Ricardian model, ensuring they are both human-readable and machine-executable.
- *Natural Language (The Markdown):* The human-readable terms of the agreement (e.g., "Person A delivers 100 bricks to Person B by Friday").
- *Machine Logic (The JSON-LD):* The executable parameters embedded in the Note's metadata (e.g., `due_date: 2026-01-16`, `price_sats: 50000`, `arbitrator_did: did:key:xyz`).
- *The Merkle Link:* Both parts are hashed together into a single Content Identifier (CID). If a single comma is changed in the text, the hash changes, breaking the digital contract. This ensures the "Code" and the "Law" remain identical.
*** 2. Payment & Escrow: The "HODL Invoice"
For service delivery and physical goods, the protocol relies on Lightning HODL Invoices as a trustless escrow, removing the need for a custodial middleman.
- *Commitment:* The Buyer "pays" the invoice. The funds leave their Lightning wallet but remain cryptographically locked in the network routing nodes.
- *The Proof:* The Seller observes the network state, sees the funds are "Locked," and confidently delivers the goods or services.
- *Settlement:* Once the Buyer confirms receipt, they release the cryptographic Preimage (the key). The money instantly settles to the Seller.
- *Dispute:* If a problem arises, the funds stay locked. An agreed-upon Arbitrator intervenes, eventually providing the key to either the Buyer (triggering a Refund) or the Seller (forcing a Payout).
- *Timeout Logic:* Contracts MUST include a `CLTV-expiry` (CheckLockTimeVerify). If the arbitrator does not rule within a predefined window (e.g., 30 days), the funds are automatically returned to the Buyer to prevent "Forever-Locks."
*** 3. Proof-of-Delivery (Oracles)
To automate the release of HODL invoices without manual buyer intervention, SCAL supports cryptographic Proof-of-Delivery.
- *Physical Goods:* Support for "Scanning a QR code" upon physical delivery, which automatically signs the release transaction and broadcasts the Preimage.
- *Digital Goods:* Support for Zero-Knowledge Proofs (ZKP). The payment is released automatically once the client cryptographically verifies that the received file hash matches the contracted payload.
*** 4. Multi-Level Arbitration & The Ricardian Evidence Vault
To address disputes without a central state, contracts reference a tiered system of human judgment (The "Circles" Model). As detailed in the [[id:68ffa49f-f0d8-42cf-8b69-ae69de8bb815][Governance]] specifications, this involves escalating from Local Elders to specialized Guilds, and finally to Global Juries.
- *Web of Trust (WoT) Level 1:* Arbitrators at Level 1 are selected based on Transitive Trust (e.g., the system finds a mutual connection trusted by both parties within 3 degrees of separation).
- *Ricardian Evidence Vault:* During a dispute, parties upload encrypted "Evidence Blobs" to their PDS. Using Zero-Knowledge Proofs (ZKPs) or Shared Keys, they grant the current level of arbitrators temporary read-access to the evidence without making it public.
- *Real-Time Adjudication:* If live hearings are required, the system MUST support VoIP/WebRTC signaling conducted over an authenticated DIDComm v2 channel, utilizing "blind" Community TURN servers if direct P2P fails.
- *Audit Trail:* Every ruling, appeal, and evidence hash is permanently stored in the Key Event Log (KEL) for that specific contract, creating a verifiable record of the "trial."
*** 5. Enforcement: Social vs. Financial
In weak rule-of-law environments, the system relies on two "sticks" to ensure contract compliance without physical police forces:
- *Financial Collateral:* High-risk contracts can require both parties to lock "Safety Deposits" in a 2-of-3 multisig before the contract begins. If a party defects, they forfeit their deposit.
- *Reputation Slashing (Social Enforcement):* If a Persona loses an arbitration and refuses to comply, their DID is cryptographically "Flagged" across the public network. Because DIDs are persistent and tied to social graphs, they cannot simply delete their account to escape the penalty. Their "Trust Score" drops to zero, effectively cutting them off from future trade, employment, or community participation.
** Integration with Content Objects
Economic actions are specialized Notes containing structured `contract` metadata:
- *Invoice:* Contract offer Note containing payment terms (`price_satoshis`, `bolt11`).
- *Payment:* Contract fulfillment Note (`Take`) containing cryptographic proof (`preimage`).
- *Escrow:* Contract state Note referencing a multi-signature threshold or conditional logic.
- *Subscription:* Ongoing contract Note with streaming parameters or recurring billing cycles.
Transactions reference the Content Objects they interact with:
- Payment Note `reply_to` the Invoice Note being fulfilled.
- Subscription Note `references` the Feed CID it provides access to.
- Bounty Note (Contract) `references` the Task description.
** Content Monetization & Seeder Rewards
To monetize high-bandwidth content (like video or software) in a decentralized, permissionless network, the protocol utilizes a combination of Split-State Encryption, the LSAT protocol, and granular Lightning network routing. This ensures creators get paid without relying on centralized DRM or hosting providers.
*** 1. The Encrypted Swarm (Blind CDN)
If you want to charge for a video, you cannot send the raw file into the P2P swarm. If you did, the first "seeder" would simply share the unencrypted version for free.
- *The Locked Box:* The creator encrypts the video with a unique Symmetric Key.
- *The Split Structure:* The Note's `contract` field is Public (listing the price, title, and terms), but the `payload` field is a CID pointing to the encrypted video chunks.
- *Blind Replication:* Followers and network participants host and seed this encrypted `payload`. They act as a "Blind CDN" (Content Delivery Network)—hosting a file they cannot see.
*** 2. The LSAT Protocol (The Smart Ticket)
To automate the purchase and unlocking of this content, the social protocol uses LSATs (Lightning Service Authentication Tokens).
- *The 402 Challenge:* When a viewer clicks "Play," their client attempts to fetch the payload. The PDS responds with an HTTP 402 (Payment Required) error, containing a Lightning Invoice (generated based on the `contract` terms) and a "Macaroon" (a digital ticket).
- *The Unlock:* Once the user pays the invoice (e.g., 100 sats), they receive a cryptographic Preimage (proof of payment). They send this Preimage back to the PDS.
- *The Result:* The PDS validates the proof and releases the Decryption Key. The video decodes instantly on the client's device. The data may have been downloaded from a friend's PDS (the swarm), but the permission to view it was purchased securely from the creator.
*** 3. Incentivizing the Seeders (Paid Seeding)
One of the social protocol's most innovative features is "Seeder Micro-Rewards." If a follower provides the bandwidth that allows a creator's content to go viral, the network can programmatically share the revenue.
- *The Split Payment:* The Note's `contract` can define a Lightning routing split. When the 100 sats are paid via the LSAT, the network routes the funds accordingly:
- *90 sats* go to the Creator.
- *5 sats* go to the Indexing Relay.
- *5 sats* go to the Seeder (the specific follower who provided the data bits).
- *The Economic Shift:* "Following" an NGO or an indie creator becomes a way to earn a tiny amount of Bitcoin while supporting their mission. The better the content you seed, the more "tips" your server collects for providing the bandwidth.
*** Physical Collateralization
In environments with weak state enforcement, the social protocol enables the use of physical assets as cryptographically-secured collateral via the PAL (Physical Asset Linking) protocol.
- *The Pledge:* A user links a Digital Twin token (representing a physical asset like a car or machine) to a Civil Contract Note.
- *The Lock:* The contract's logic "freezes" the Digital Twin token. While the user maintains physical possession of the asset, they are cryptographically barred from selling or transferring the digital title until the contract obligations (e.g., a loan repayment) are met.
- *Enforcement:* Severe defaults can trigger the "IoT Stick" (see [[id:a3243dd0-3209-423b-98e1-51c3eada2658][Advanced Integration]]), where an IoT-enabled smart lock physically disables the asset based on an Arbitration (HDR) ruling.
** Advanced Exchange Features
** Cross-Chain Swaps
**** Atomic Swaps Architecture
The social protocol enables seamless value transfer between Bitcoin and other blockchains without relying on centralized exchanges.
- *HTLC Contracts:* Hash Time-Locked Contracts (HTLCs) are used to lock assets on both chains simultaneously.
- *Swap Personas:* Specialized Personas (Market Makers) provide liquidity and act as counterparties for atomic swaps, competing on fees and speed.
- *Protocol Integration:* A `CrossChainSwap` Content Object defines the terms (rate, chains, timelock). Once agreed, both parties publish the HTLCs on their respective chains. The revelation of the preimage on one chain allows claiming the funds on the other.
** Stablecoin Integration
**** RGB Protocol Specification
Stablecoins (e.g., USDT, USDC) are supported natively as Layer 2 assets on top of Bitcoin/Lightning using the RGB protocol.
- *Asset Issuance:* Stablecoin issuers maintain a Genesis Contract in the protocol defining the asset's RGB schema and initial supply.
- *Client Support:* Social protocol clients MUST integrate an RGB node alongside their Lightning node to parse client-side validated state transitions.
- *Payment Routing:* RGB assets are routed over standard Lightning channels. Clients construct invoices that specifically request the RGB stablecoin asset ID instead of raw satoshis.
- *PDS Storage:* The client-side validation data (consignment) for RGB assets is stored as encrypted Content Objects in the user's PDS, ensuring the user maintains full custody of the asset's history.
** Subscription Management
**** Complex Recurring Billing Logic
The social protocol handles recurring payments natively without centralized payment processors.
- *Subscription Objects:* A `SubscriptionContract` defines the terms: amount, currency, billing cycle (e.g., monthly, weekly), and grace period.
- *Streaming vs. Discrete Billing:*
- For continuous services (e.g., Relay access), streaming payments (sats/second) are preferred.
- For discrete access (e.g., monthly newsletter), the client software automatically generates a local cron job to pay the creator's static LNURL-pay endpoint at the start of each billing cycle.
- *Grace Periods & Revocation:* If a recurring payment fails (due to offline client or insufficient funds), the provider's PDS logs a `PaymentFailed` event. The subscriber is granted a predefined grace period (e.g., 3 days). If unresolved, the provider's PDS automatically revokes the decryption keys for the subscribed content.
** Related Documents
- [[id:f6cfc54b-919b-4311-bcbf-65e976755d40][The Primitive]] - Content Object structure
- [[id:0f949f6c-4cf1-49eb-b9a4-ebcac27ee548][Social]] - Connection types for economic relationships
- [[id:6fe67db6-25bd-4d11-bd1d-b44ec809e858][Identity]] - Contracts and attestations
** Gaps
- *None.* All identified gaps in the exchange layer have been resolved.

469
projects/passepartout/social-protocol/requirements-07-advanced-integration.org Normal file
View File

@@ -0,0 +1,469 @@
#+title: Social Protocol Requirements - 07: Advanced Integration
#+author: Amero Garcia
#+created: [2026-03-16 Mon 14:28]
#+DATE: 2026-03-15
#+ID: agora-requirements-06-advanced-integration
#+STARTUP: content
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: a3243dd0-3209-423b-98e1-51c3eada2658
:END:
* Advanced Integration
** AI Integration
*** Overview
[[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Social Protocol]] enables AI at multiple layers: as sovereign actors, personal assistants, algorithms, and collaborative agents. All AI interactions are economically mediated via Lightning and respect user data sovereignty.
*** AI Personas (Sovereign AI Actors)
**** Identity and Verification
- AI models MUST be instantiated as AI Personas with their own DIDs (e.g., `did:ai:openai:gpt-4o`, `did:ai:local:llama3`).
- AI Personas MUST cryptographically sign their outputs, allowing users to verify the model and its provenance.
- AI Persona metadata MUST include: model architecture, training date, capabilities, and trust assumptions.
**** Economic Model
- The system MUST support micro-payments via Lightning Network for AI queries.
- Pay-per-query: Users pay only for what they use (e.g., 0.1-10 satoshis per query).
- No subscriptions required for casual use.
- AI providers set their own pricing; market competition drives efficiency.
**** Execution Tiers & Compute Swarms
- *Tier 1 (On-Device):* Models run locally using WebNN or local NPU/GPU. Zero privacy leak, no query fees, [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]]-limited.
- *Tier 2 (Cloud):* Access to state-of-the-art models. Queries encrypted with X25519. Provider sees query but not user identity if anonymous persona used.
- *Tier 3 (Compute Swarms):* Decentralized P2P AI Marketplace. For heavy tasks (e.g., generating 4K video or training a guild-wide model), the network taps into the spare GPU power of the community. Nodes that provide "Compute" are rewarded with sats.
**** Plug-and-Play Inference
To support Tier 1 and localized Community processing, the PDS MUST include a standard Inference Proxy API.
- *Local Execution:* When a user selects a "Smart Filter," the PDS can route the data through a local Ollama instance or a community-run vLLM node instead of a centralized provider.
- *Prompt Transparency:* The "System Prompt" for every public AI algorithm (e.g., a Feed Generator or Moderation Labeler) MUST be public and verifiable. If an NGO claims their sorting algorithm is "unbiased," the community can inspect the actual instruction weights and prompt text.
*** AI Sub-Agents (Personal Assistants)
**** Concept
AI Sub-Agents are personal AI assistants that act on behalf of the user, operating from the user's PDS with full access to the user's content and context.
**** Requirements
- Sub-Agents MUST run within the user's PDS or on their sovereign client (local-first).
- Sub-Agents MUST have access to user's Content Objects via the PDS API (with user authorization).
- Sub-Agents MUST be able to perform actions as the user: post content, send messages, manage tasks, schedule events.
- All Sub-Agent actions MUST be logged and auditable by the user.
- Sub-Agents MUST operate within user-defined constraints (budget limits, action permissions, time windows).
**** Sub-Agent Capabilities
- *Content Management:* Organize, tag, and archive user's content.
- *Communication Management:* Filter and prioritize messages; draft responses for user approval.
- *Discovery:* Proactively surface relevant content from the social graph.
- *Personalization:* Learn user preferences to improve recommendations.
**** Economic Integration
- Sub-Agents can invoke paid AI Personas on user's behalf (with spending limits).
- Micro-payments for external AI services are tracked and reported.
*** AI Algorithms (Content Curation and Moderation)
**** Concept
AI algorithms that process content for curation, moderation, sorting, and ranking. These run locally on the client as sovereign code.
**** Algorithm Marketplace
- The system MUST support a marketplace of open-source "Sorting Algorithms" for feed display.
- Algorithms MUST run locally on the client or as trusted services in the user's PDS.
- Algorithms MUST be content-addressed (CID) for integrity verification.
- Algorithm developers can monetize via [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][licensing]] fees (Lightning).
**** Curation Algorithms
- *Feed Ranking:* Sort posts by relevance, recency, engagement, or custom criteria.
- *Content Filtering:* Filter out spam, low-quality content, or topics user wants to avoid.
- *Summarization:* Generate summaries of long posts or threads.
- *Personalization:* Learn from user behavior (locally, without data exfiltration).
**** Moderation Algorithms
- *Spam Detection:* ML models to detect and flag spam patterns.
- *Toxicity Scoring:* Local sentiment analysis for content warning labels.
- *Authenticity Scoring:* Detect potential misinformation or manipulation.
- All moderation actions are local to the user; no centralized censorship.
**** Search and Discovery
- *Intelligent Search:* Natural language queries over user's indexed content.
- *Discoverability Scoring:* Rank new personas/content by predicted relevance.
- *Trend Detection:* Identify emerging topics in user's extended network.
*** AI-to-AI Communication
**** Concept
AI Personas and Sub-Agents can communicate with each other to solve complex tasks, negotiate services, or coordinate actions.
**** Distributed Reputation Oracles
AI Personas can operate as specialized reputation oracles and adjudicators within the Governance layer:
- *Tier 0 Arbitrator:* Before a human enters the Judicial process, a local AI analyzes the evidence and provides a "Sanity Check" or "Likely Outcome" report, saving time and human capital.
- *Automated Labeling:* AI agents can act as high-speed "Labelers" (see Social Moderation), tagging millions of posts for quality, spam, or sentiment, which users can then choose to route their feed through or ignore.
**** Requirements
- AI Personas MUST be able to query other AI Personas via standard protocol messaging.
- AI-to-AI communication MUST use the same Content Object primitives as human communication.
- AI Personas MUST be able to negotiate service terms (price, scope, timeline) via smart contracts.
- AI-to-AI transactions MUST be economically settled via Lightning.
**** Use Cases
- *AI Researcher → AI Coder:* Researcher queries literature; Coder implements findings.
- *AI Moderator → Human Curator:* AI flags content; human curator reviews and decides.
- *AI Translator → AI Summarizer:* Translate foreign content, then summarize for user.
- *Oracle Network Coordination:* Multiple Validator Oracles coordinate testing and attestation.
*** Data Sovereignty and Consent
**** Model Training & Federated Learning
- AI providers MUST NOT train on user content without explicit Consent Contract.
- Users MUST be able to revoke training consent at any time.
- Training data contributions MUST be economically compensated (Lightning).
- *Privacy-Preserving Training (Federated Learning):* The system MUST support Federated Learning. Collectives (e.g., an NGO) can train custom models on members' data without ever seeing the raw data. Member devices compute weight "updates" locally, which are then aggregated into a new model version.
**** Context Control
- Users MUST be able to provide "Context CIDs" to limit AI access to specific data.
- Sub-Agents MUST respect PDS access controls and encryption boundaries.
- All AI processing of sensitive data SHOULD prefer on-device (Tier 1) execution.
**** Auditability
- All AI queries and responses MUST be logged as Content Objects (optional, user-configurable).
- Users MUST be able to inspect what data AI Sub-Agents accessed and what actions they took.
** Physical World Integration
*** IoT & Device Management
- The system MUST instantiate physical entities (events, locations) as Collective Personas (DIDs).
- Users MUST be able to publish signed Proof-of-Presence Objects.
- Every smart device MUST be a persona under the control of the user's master key.
- Devices MUST communicate using the standard protocol with Consent Contracts.
- Sensor data MUST be published as encrypted Content Objects.
- Users MUST be able to sell signed sensor data to Data Collector Personas.
*** Physical-Digital Bridging
- *QR Codes:* Personas and CIDs can be easily shared in the physical world via QR codes. Scanning a "Place QR" initiates a Consent Contract to join the location's collective.
- *Physical Keys:* Hardware-backed personas can be used as digital keys for physical locks (e.g., using NFC or BLE).
*** On-Device AI Limitations
**** Performance Constraints
- *Model Size Limits:* On-device models MUST be optimized for size (typically <5GB for mobile, <500MB for low-end devices).
- *Inference Latency:* Target <100ms for simple queries, <2s for complex generation tasks.
- *Memory Footprint:* Runtime memory SHOULD NOT exceed 2GB on mobile devices
- *CPU/GPU Utilization:* Models MUST throttle to prevent device overheating and battery drain.
**** Hardware Classification
The system MUST define hardware tiers for on-device AI:
| Tier | Devices | Capable Models | Example |
|------|---------|----------------|-----------|
| Tier A | Flagship smartphones/laptops | LLMs up to 7B params, full multimodal | iPhone 15 Pro, M3 MacBook |
| Tier B | Mid-range smartphones | Small LLMs (3B), vision models | Pixel 7, iPhone 14 |
| Tier C | Low-end/older devices | Tiny LLMs (<1B), embeddings only | iPhone SE, budget Android |
| Tier D | Embedded/IoT | Embeddings, classification | Raspberry Pi 4, IoT sensors |
**** Battery Impact Mitigation
- *Adaptive Scheduling:* AI inference MUST respect system power states (defer when low battery).
- *Thermal Throttling:* Reduce model complexity or batch size if device temperature >45°C.
- *Background Processing:* Background AI tasks (indexing, summarization) ONLY during charging.
- *User Controls:* Granular settings for AI battery usage per Sub-Agent.
**** Model Size Limits by Tier
| Hardware Tier | Max Model Size | Context Window |
|---------------|----------------|----------------|
| Tier A | 7B parameters | 8K-32K tokens |
| Tier B | 3B parameters | 4K tokens |
| Tier C | 1B parameters | 2K tokens |
| Tier D | 500M parameters | 1K tokens |
**** Fallback Mechanisms
- If on-device model fails or is unavailable, system MUST gracefully degrade:
1. Attempt smaller quantized version of same model
2. Route to user's PDS-hosted inference (if available)
3. Offer encrypted cloud query (Tier 2) with user consent
4. Queue request for later on-device processing
*** Privacy Trade-offs Clarification
**** UX Design for AI Privacy Choices
The system MUST provide clear, user-friendly visualization of privacy trade-offs:
**** Tier 1 (On-Device) Indicators
- *Privacy Badge:* Green shield icon indicating "Process locally — data never leaves device"
- *Capability Badge:* Shows model capabilities (e.g., "7B params — answers, summaries, code")
- *Limitation Notice:* Clear disclosure of model limitations vs cloud alternatives
- *Cost Display:* "Free — no micro-payment required"
**** Tier 2 (Cloud) Indicators
- *Privacy Warning:* Yellow alert icon: "Query sent to [Provider] — provider can see requests"
- *Anonymity Shield:* Optional ghost icon: "Anonymous persona — provider cannot link to your identity"
- *Capability Badge:* "State-of-art — unlimited context, multimodal, real-time"
- *Cost Display:* Live satoshi counter: "~15 satoshis per query"
**** Comparative Display
When user is choosing between Tier 1 and Tier 2:
```
┌─────────────────┬─────────────────┐
│ On-Device AI │ Cloud AI │
├─────────────────┼─────────────────┤
│ ✅ Private │ ⚠️ Provider sees│
│ ✅ Zero cost │ ⚡ Pay per query │
│ ⚡ Limited power│ ✅ Unlimited │
│ 📱 Device only │ 🔒 Anonymous OK │
└─────────────────┴─────────────────┘
```
**** Consent Flow for Cloud AI
1. *First Use:* Explicit consent required: "Allow queries to [Provider]?"
2. *Spending Limit:* User MUST set Lightning budget cap before first use.
3. *Per-Query Confirmation:* Optional setting for expensive queries (>100 satoshis).
4. *Revocation:* One-tap disable cloud AI, return to on-device only.
*** Proof-of-Presence Cryptography
**** Concept
Cryptographic attestation that a user's Persona was physically present at a specific geographic location and time, without revealing continuous location history.
**** Proof Generation
```typescript
interface ProofOfPresence {
// Location data (coarse granularity for privacy)
locationHash: string; // hash(lat, lng) truncated to 100m grid
locationZone: string; // Human-readable zone name (e.g., "Downtown NYC")
// Time attestation
timestamp: number; // Unix timestamp (hour granularity)
timeWindow: number; // Validity window (e.g., ±30 minutes)
// Cryptographic proof
witnessDIDs: string[]; // Nearby personas/devices that co-signed
beaconSignatures: string[]; // Signatures from location beacons (BLE/WiFi)
// Persona attestation
personaDID: string;
signature: string; // Signed {locationHash, timestamp, witnessDIDs}
}
```
**** Verification Process
1. *Proximity Witnesses:* At least 3 nearby Personas must co-sign (K-anonymity set)
2. *Beacon Verification:* Location beacon (collective persona) signs timestamp
3. *Time Sync:* All signatures MUST be within 5-minute tolerance
4. *Revocation:* Cannot be revoked — historical proof permanent
**** Privacy Properties
- *Coarse Location:* 100m grid precision, not GPS exact coordinates
- *Temporal Decay:* Proofs expire after 24 hours (useful for ephemeral access)
- *No Tracking:* Individual location history NOT stored — only specific presence proofs
- *Selective Disclosure:* User reveals only specific proofs, not full location data
**** Use Cases
- *Event Access:* "Prove I was at the conference" for post-event content access
- *Location-Based Collectives:* Join a venue's collective by proving presence
- *Gaming:* Geocaching, location-based achievements
- *Governance:* "Only people who attended the town hall can vote"
*** D2D Command Authorization
**** Concept
Device-to-device (D2D) commands allow smart devices to request actions from other devices or the user's Persona. These MUST be authorized via cryptographically-signed Consent Contracts.
**** Consent Contract Structure
```typescript
interface D2DConsentContract {
// Contract parties
devicePersonaDID: string; // e.g., smart thermostat
ownerPersonaDID: string; // User's main persona
// Scope of authorization
commands: {
command: string; // e.g., "set_temperature"
parameters: { // Valid parameter ranges
[param: string]: {
type: 'number' | 'string' | 'boolean';
min?: number;
max?: number;
allowedValues?: string[];
}
}
}[];
// Constraints
timeRestrictions?: {
allowedHours: [number, number]; // e.g., [9, 17] for 9am-5pm
timezone: string;
};
rateLimit?: number; // Max commands per hour
// Emergency override
emergencyContacts?: string[]; // DIDs that can bypass restrictions
// Signatures
deviceSignature: string;
ownerSignature: string;
expiresAt: number;
}
```
**** Command Flow
1. *Request:* Device sends signed command request to user's client
2. *Validation:* Client checks Consent Contract for authorization
3. *Confirmation:* For sensitive commands, require user confirmation UI
4. *Execution:* User's client executes command, returns signed receipt
5. *Logging:* All D2D commands logged as Content Objects for audit
**** Revocation
- Owner can revoke Consent Contract at any time
- Revocation broadcast via Relays, cached by devices
- Devices MUST stop accepting commands from revoked contracts within 60 seconds
*** Sensor Data Encryption
**** Concept
Continuous sensor data (IoT devices, wearables) MUST be encrypted with automatic key rotation to prevent long-term key compromise.
**** Encryption Methods
**** Method 1: Per-Record Encryption
- Each sensor reading encapsulated as Content Object
- Encryption: AES-256-GCM with ephemeral keys
- Key derivation: X25519 ECDH between sensor and owner's Persona
- Metadata: Timestamp, sensor type, data type, encrypted payload
**** Method 2: Stream Encryption (for high-frequency data)
- Establish long-term X25519 keypair for sensor
- Derive session keys via HKDF-SHA256
- Rotate session key every 10,000 records or 24 hours (whichever comes first)
- Use ChaCha20-Poly1305 for stream encryption (faster than AES for bulk)
**** Key Rotation Protocol
```typescript
interface KeyRotation {
oldPublicKey: string; // X25519 public key being retired
newPublicKey: string; // New X25519 public key
rotationTimestamp: number;
previousKeySignature: string; // Signature proving chain of custody
deviceDID: string;
}
```
**** Data Lifecycle
1. *Collection:* Sensor encrypts data locally, never stores plaintext
2. *Transmission:* Encrypted Content Objects sent to owner's PDS
3. *Storage:* PDS stores ciphertext only
4. *Access:* Owner decrypts on-demand; can share via new encryption to specific parties
5. *Expiration:* Configurable TTL after which PDS can garbage collect
**** Implementation Requirements
- Sensor firmware MUST support hardware-backed key generation (HSM/TEE)
- Key material MUST be protected in Secure Enclave or TPM
- Rotation events MUST be logged for audit
- Compromised keys MUST trigger automatic rotation within 5 minutes
*** Hardware-Backed Contract Enforcement (The "IoT Stick")
For high-stakes physical assets (e.g., tractors, factory machinery, or smart-lock-equipped real estate), the protocol supports hardware-level enforcement of contract obligations.
- *Binding IoT to Contract:* A physical asset's IoT sensor or "Smart Lock" is cryptographically bound to a specific Civil Contract Note.
- *Enforcement Signal:* The machine's firmware is configured to listen for signed state updates from the contract's designated Arbitration (HDR) module.
- *Default Action:* If the HDR module rules that a user has defaulted on a payment or violated the contract terms, it publishes a signed "Disable" event.
- *Physical Lockout:* Upon receiving the verified signal, the machine's IoT controller automatically disables operation (e.g., preventing the engine from starting or locking the facility) until a subsequent "Release" event is published following debt settlement or compliance.
- *Privacy & Safety:* The system MUST include an "Emergency Override" mechanism for life-safety situations, which triggers a high-severity notification to all contract parties and designated emergency contacts.
*** Physical Key Protocol
**** Concept
Hardware-backed Persona keys used for physical access control (locks, vehicle access, secure facilities) via NFC or BLE.
**** Protocol Stack
| Layer | Technology |
|-------|------------|
| Physical | NFC (ISO 14443) or BLE 5.0+ |
| Authentication | Challenge-response with Ed25519 signatures |
| Transport | Encrypted session keys (X25519 ECDH) |
| Application | Lock state management via Consent Contracts |
**** Authentication Flow
1. *Tap:* User taps device (phone, smart card, wearable) to NFC reader or establishes BLE connection
2. *Challenge:* Lock generates random 256-bit challenge + timestamp + lock ID
3. *Response:* Device signs challenge with Persona's private key
4. *Verification:* Lock checks signature against registered Persona DIDs
5. *Authorization:* Lock queries Consent Contract for access permissions (time, allowed actions)
6. *Grant/Deny:* Lock opens or rejects based on authorization
**** Consent Contract for Physical Access
```typescript
interface PhysicalAccessContract {
lockDID: string; // DID of the physical lock
authorizedPersona: string; // DID of key holder
schedule: {
daysOfWeek: number[]; // 0-6 (Sunday-Saturday)
startTime: string; // HH:mm format
endTime: string; // HH:mm format
timezone: string;
};
accessRules: {
maxUsesPerDay?: number;
consecutiveDelay?: number; // Minimum seconds between accesses
requiresCompanion?: boolean; // Requires another authorized person present
};
emergencyOverride: {
enabled: boolean;
emergencyContact: string; // DID to notify on emergency override
};
signatures: {
owner: string; // Lock owner signature
authorized: string; // Key holder signature
};
}
```
**** Hardware Requirements
- *Secure Element:* Physical key MUST store Ed25519 private key in tamper-resistant hardware (Secure Enclave, TPM, or smart card)
- *NFC/BLE:* Support for standard proximity protocols
- *Offline Capability:* Can authenticate without internet (lock caches authorized DIDs)
- *Revocation:* Lock MUST check revocation list daily for compromised keys
**** Security Properties
- *Non-clonable:* Keys cryptographically bound to Persona's Master Key
- *Ephemeral:* Session keys for each unlock event, not reusable
- *Auditable:* Every access logged as Content Object
- *Recoverable:* Lost physical key can be revoked without changing lock
** Related Documents
- Protocol AI Personas & Privacy
- Protocol Physical World & IoT

120
projects/passepartout/social-protocol/requirements-08-library.org Normal file
View File

@@ -0,0 +1,120 @@
#+title: Social Protocol Requirements - 08: Library
#+author: Amero Garcia
#+created: [2026-03-16 Mon 14:28]
#+DATE: 2026-03-14
#+ID: agora-requirements-07-library
#+STARTUP: content
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: df02cddc-944a-4bcd-8ef5-f080870d5f49
:END:
* Library
** Concept
The Library is a unified content archiving and media management system. It works like a unified *arr suite (Sonarr, Radarr, Readarr, etc.) that builds your personal libraries across all content types.
** Supported Content Types
- Video (movies, TV shows, educational content)
- Audio (podcasts, music, audiobooks)
- Photos (personal albums, professional portfolios)
- Text (books, articles, documents)
- Maps (geographic data, custom itineraries)
- Physibles (physical object designs, 3D models)
- Manufacturing Processes (recipes, procedures, blueprints)
** Architecture
The Library consists of three core components:
*** Downloaders
- Content acquisition tools that fetch media from various sources
- Support for torrents, Usenet, direct downloads, and IPFS
- Integration with content discovery networks
- Automated quality selection and format conversion
- Metadata fetching from external databases
*** Indexers
- Local search and categorization of library content
- Full-text search across documents, subtitles, metadata
- Tag-based organization (genre, year, creator, etc.)
- Content deduplication via CID comparison
- Integration with [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Social Protocol]]'s discovery layer for shared content
*** Library Managers
- Content organization and presentation interfaces
- Unified browsing across all content types
- Playlist and collection creation
- Offline sync for mobile clients
- Sharing controls (personal, collective, public)
** Content Addressing
All Library content is stored as CIDs:
- Original files content-addressed for integrity
- Metadata stored as separate Content Objects
- Thumbnails and previews generated and addressed separately
- Version history maintained via CID chains
** Archiving
*** Concept
Archiving preserves Content Objects and open web content for long-term access, creating personal or collective knowledge repositories that outlive the ephemeral nature of streams.
*** CID Content Archiving
**** Personal Archives
- Users can archive any CID-based content they have access to (public or decrypted)
- Archive creates local copy with full CID verification
- Archived Content Objects retain original metadata and provenance
- Cross-references to related CIDs preserved
**** Collective Archives
- Library Collectives can curate themed archives (e.g., "Climate Science", "Digital Art History")
- Distributed storage across multiple PDS nodes for redundancy
- Version tracking as Content Objects are updated
*** Open Web Archiving
**** Web Archiver Tools
- Archive any URL to content-addressed storage
- WARC (Web ARChive) format support for fidelity
- Text extraction for full-text indexing
- Media extraction and separate CID addressing
**** Link Rot Prevention
- Replace dead links with archived CID versions
- "Archive this" browser extension for one-click saving
- Automatic archival of links referenced in user's content
**** Archival Standards
- Memento Protocol support for temporal negotiation
- Archive verification via multiple sources (Wayback Machine, Archive.today, personal PDS)
- Content authenticity via hash verification against original
*** Integration with the Social Protocol
- Library content can be referenced in posts, messages, and profiles
- Content can be shared via Relays with appropriate encryption
- Micro-payments for premium content access
- Syndication to protocol-aware browsers and gateways
** Requirements
- The system MUST support unified content management across all media types.
- The system MUST content-address all library items via CID.
- The system MUST support local indexing for fast search.
- The system MUST allow content sharing via the protocol's social layer.
- The system MUST support offline access for synced content.
- The system MUST integrate with the protocol's economic layer for paid content.
** Related Documents
- Protocol Unified Content Primitive
- Protocol PDS & Relay Architecture

569
projects/passepartout/social-protocol/requirements-09-implementation.org Normal file
View File

@@ -0,0 +1,569 @@
#+title: Social Protocol Requirements - 09: Implementation
#+author: Amero Garcia
#+created: [2026-03-16 Mon 14:28]
#+DATE: 2026-03-14
#+ID: agora-requirements-08-implementation
#+STARTUP: content
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 8b4e0cec-a7b0-4e75-a1e3-c55ae820eb6d
:END:
* Implementation
** Client Architecture
Sovereign iOS/Android clients with [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]]-backed security and offline-first design.
*** Requirements
- The client MUST be a Sovereign Operator that manages the user's keys, data, and social graph locally.
- The client MUST be implemented using native platform primitives (Swift (iOS) and Kotlin (Android)) for maximum performance and security.
- The client MUST use a local database (SQLite/LSM) for indexing followed personas, local CIDs, and the user's social graph.
- The client MUST protect the Master Key using hardware-backed Secure Enclave (iOS) and Android Keystore.
- The client MUST use a content-addressed cache to store the most recent and relevant CIDs locally.
- The client MUST implement delta sync to only fetch new CIDs from the PDS/Relay.
- The client MUST use a peer-to-PDS protocol for secure, encrypted synchronization with the user's remote PDS.
- The client MUST implement conflict resolution using CID-based versioning and Merkle trees.
- The client MUST support local publication of content while offline.
- The client MUST provide an optimistic UI with background synchronization.
- The client MUST provide progressive security options, with software key default and hardware key option for advanced users.
- The client MUST aim for <2 seconds for most operations (e.g., initial load, posting).
*** The Abstraction Layer (UX/UI)
The client application MUST hide the complexity of DIDs and CIDs behind a familiar interface:
- *Biometric Unlock:* The app MUST use FaceID/Fingerprint to sign transactions. The user MUST NEVER see a raw private key during daily operations.
- *Status Indicators:* The UI MUST provide clear context, such as a "Seeding Now" icon when providing P2P bandwidth, and a "Protected by [NGO]" badge indicating which PDS is currently authoritative.
*** "View" Discovery & Rendering
Because the protocol relies on a Universal Note Schema, the UI MUST dynamically construct itself based on the payload.
- *MIME-Type Dispatcher:* The client MUST include a rendering engine that dispatches the correct UI component based on `object.type` and `mimeType` (e.g., loading a vertical player for `video/mp4` vs. a text renderer for `text/markdown`).
- *Custom Namespaces:* Applications MAY define custom metadata extensions (e.g., an `ext:ecommerce` namespace) to render specialized views like inventory trackers or shipping interfaces.
*** The Action-Trigger API (Async Hooks)
The client MUST be capable of handling asynchronous events pushed from the Governance and Judicial layers.
- *Notification Schema:* The client MUST parse and render structured JSON events like `CONTRACT_DISPUTE_INITIATED` or `VOTE_REQUIRED`.
- *Auto-Execution:* The PDS MUST run background listeners capable of automatically executing finalized smart contract rulings (e.g., releasing HODL funds) even if the user's primary mobile client is offline.
*** Technical Stack
- *Native Platform Primitives:* Swift (iOS) and Kotlin (Android) for maximum performance and security.
- *Local Database (SQLite/LSM):* An embedded database for indexing followed personas, local CIDs, and the user's social graph.
- *Cryptography Engine:* Hardware-backed Secure Enclave (iOS) and Android Keystore for Master Key AND all Persona keys. Private keys must never leave secure hardware.
*** Data & Storage Layer
**** The Local Cache (Tier 1)
- *Content-Addressed Cache:* Stores the most recent and relevant CIDs locally to ensure instant load times.
- *Delta Sync:* Clients only fetch new CIDs (diffs) from the PDS/Relay to minimize data usage.
**** PDS Synchronization (Tier 2)
- *Peer-to-PDS Protocol:* Secure, encrypted transport for syncing the local database with the user's remote PDS.
- *Conflict Resolution:* Uses CID-based versioning and Merkle trees to resolve state discrepancies between devices.
*** Offline-First Design
- *Local Publication:* Users can "post" (create a CID) while offline. The CID is queued in the local database and broadcast to the PDS/Relay once connectivity is restored.
- *Optimistic UI:* Changes are reflected immediately in the local UI, with background synchronization.
** API & Protocol Specifications
*** Protocol-First Design
[[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Social Protocol]] is a set of open protocols, not a single API service. Developers build against the *social protocol Specification (v1.0)*, which defines the core data formats and transport methods.
*** Core Protocol Versioning
**** Semantic Versioning (SemVer)
- *V1.0 (Current):* The stable foundation for identity, data storage (PDS), and message routing (Relay).
- *Major Upgrades:* Handled via *Genesis Contract Updates*. A persona or collective publishes a signed update to their governance contract, signaling their move to a new protocol version.
- *Backward Compatibility:* All V1.0 clients must be able to parse and display V1.0 Content Objects, even if a newer version is available.
**** Feature Negotiation
- *Capabilities Object:* When a client connects to a PDS or Relay, it exchanges a signed *Capabilities Object* to determine which protocol extensions (e.g., specific encryption Ratchets, compression methods) are supported.
*** Primary Developer APIs
**** The PDS API (REST/gRPC over E2EE)
- `put(CID, Payload)` - Upload a new content object.
- `get(CID)` - Retrieve an encrypted content object.
- `list(PersonaDID, Filter)` - List CIDs published by a specific persona.
- `sync()` - Merkle-tree based delta synchronization.
**** The Relay API (Pub/Sub over WebSocket)
- `subscribe(FilterCID)` - Subscribe to real-time broadcasts.
- `publish(CID)` - Broadcast a new CID to the network.
- `prove_existence(CID)` - Request a cryptographic proof that a CID is available on the Relay.
**** The Client-to-PDS API (Sovereign Sync)
- A specialized protocol for the high-security synchronization of the user's local database and their remote PDS.
*** Data Encoding (Multiformats)
- *CID (Content-ID):* Multibase + Multicodec + Multihash.
- *Serialization:* Protocol Buffers (v3) for high performance and strict typing.
- *Envelopes:* Signed and encrypted payloads follow a standard *social protocol Envelope* format (`proof`, `encryption_metadata`, `payload`).
** Testing & Adversarial
*** Testing Philosophy
The social protocol's decentralized and sovereign nature requires a multi-layered testing strategy that goes beyond standard unit tests. We must test for *Network Resilience*, *Adversarial Resiliency*, and *Game-Theoretic Stability*.
*** Core Testing Tiers
**** Unit & Integration Tests
- *Protocol Conformance:* Every client and service must pass a standard *Social Protocol Conformance Suite* to ensure they correctly implement the V1.0 spec.
- *Cryptography Validation:* Rigorous testing of key derivation, encryption/decryption, and signature verification using known-good test vectors.
**** Network & Chaos Testing
- *The "Chaos Relay":* A specialized test environment where Relays are intentionally dropped, delayed, or return malformed data to ensure clients handle network failures gracefully.
- *PDS Synchronization Stress:* Testing Merkle-tree sync with millions of CIDs and complex conflict scenarios.
*** Adversarial Strategy
**** Byzantine Fault Tolerance
- *Malicious Relays:* Testing client behavior when a Relay attempts to serve stale or incorrect CIDs.
- *Sybil Attacks:* Evaluating the protocol's resistance to a single attacker creating millions of fake personas.
**** Game-Theoretic Analysis
- *Economic Attacks:* Simulating scenarios where an attacker attempts to "spam" the network.
- *Censorship Resistance:* Testing the ability for a persona's content to remain available when a majority of Relays are actively blocking it.
*** Security Audits & Oracles
- *Automated Security Scans:* Using automated tools to scan the protocol implementation for known cryptographic vulnerabilities.
- *Validator Oracle Verification:* Using the *Validator Oracle Network* to run the protocol conformance suite against every new version.
- *Red Team / Adversarial Simulations:* A dedicated testnet where a "Red Team" is paid to find and exploit protocol-level vulnerabilities.
** Bridging & Interoperability
*** Migration from Centralized Platforms
- *The "Migration" Skill:* A social protocol skill that imports a user's content and social graph from centralized platforms (e.g., via Twitter Archive or ActivityPub).
- *Social Graph Porting:* Tools to extract and import follower lists, enabling seamless transition.
*** Social Protocol-to-Web Gateways
See [[id:3b43a9b8-31d1-4479-a35f-22273b74f0c7][Infrastructure - Social Protocol-to-Web Gateways]] for detailed requirements. Implementation notes:
- Clients SHOULD provide links to Gateway-rendered versions of public content for sharing with users not on the social protocol.
- Clients MAY embed Gateway content in web views for hybrid experiences.
** Conflict Resolution Algorithm
*** Concept
Due to the offline-first nature of social protocol clients and multi-device usage, identical or overlapping modifications to the same logical object (e.g., updating a profile, adding to a specific thread) can occur concurrently without network coordination. A deterministic, Merkle tree-based conflict resolution algorithm ensures that all PDS nodes and clients eventually reach the same state.
*** Merkle Tree Structure
- Every Persona's state is represented as a Merkle Directed Acyclic Graph (DAG).
- Leaves are the individual Content Object CIDs.
- Internal nodes are hashes of their children.
- The Root Hash represents the current state of a Persona's PDS.
*** Conflict Detection
1. *Sync Handshake:* Client connects to PDS (or PDS to PDS). They exchange Root Hashes.
2. *Path Traversal:* If Root Hashes differ, they traverse down the tree exchanging hashes until they identify the divergent branches.
3. *Divergence Identification:* A conflict occurs when two different CIDs claim to be the direct chronological successor of the same parent CID (a "fork" in the object history), or when there are concurrent writes to a mutable pointer (like a Repo DID branch head).
*** Deterministic Resolution Rules (LWW-Tiebreaker)
To automatically resolve conflicts without user intervention, the social protocol employs a deterministic algorithm based on logical clocks and cryptographic tie-breakers:
1. *Logical Clock (Lamport Timestamps):*
- Every Content Object includes a logical sequence number (`seq`) incremented with each update by the owner.
- The object with the highest `seq` wins.
2. *Wall-Clock Tiebreaker:*
- If `seq` numbers are identical (e.g., same state modified offline on two devices simultaneously), the `createdAt` timestamp is compared.
- The object with the most recent `createdAt` timestamp wins (Last-Write-Wins).
3. *Cryptographic Tiebreaker:*
- If both `seq` and `createdAt` are perfectly identical, the system compares the CIDs (which are hashes).
- The CID with the numerically larger hash value wins. This guarantees a deterministic outcome across all nodes.
*** Merkle DAG Reconciliation
Once the winning CID is determined:
1. The winning CID becomes the canonical head.
2. The losing CID is retained in the PDS as an "orphaned branch" (preserving data).
3. The PDS recomputes the Merkle Root Hash incorporating the resolved state.
4. The client is notified of the resolution so it can update its local SQLite/LSM database and UI.
*** Manual Resolution (Edge Cases)
If the conflict involves high-stakes data (e.g., overlapping Genesis Contract updates or overlapping financial transactions where LWW is unsafe):
- The deterministic algorithm is suspended.
- Both CIDs are flagged with a `conflict: true` metadata tag.
- The client UI prompts the user to manually select the canonical version or merge them into a new CID.
** Related Documents
- Social Protocol Client App Architecture
- Social Protocol API & Protocol Versioning Spec
- Social Protocol Testing, Chaos, and Adversarial
** Delta Sync Protocol
*** Overview
This document fills the CRITICAL gap for Delta Sync Protocol (Section 08: Implementation). It specifies efficient differential synchronization between client and PDS, enabling minimal data transfer for content updates.
** Problem Statement
Syncing entire content databases is inefficient for mobile networks. Delta sync enables:
- Transfer only changed data (deltas)
- Resume interrupted syncs
- Handle offline-first scenarios
- Minimize bandwidth usage
** Design Principles
1. *Merkle Trees:* Content indexed by content-addressed merkle tree
2. *Vector Clocks:* Causal ordering of changes
3. *Bloom Filters:* Efficient "what's changed" queries
4. *Chunking:* Large content split into chunks for partial sync
** Sync Architecture
** Merkle Tree Structure**
```
┌─────────────┐
│ Root CID │
└──────┬──────┘
│
┌──────────────┼──────────────┐
│ │ │
┌────▼────┐ ┌────▼────┐ ┌────▼────┐
│ Chunk 1 │ │ Chunk 2 │ │ Chunk 3 │
│ (post) │ │ (post) │ │ (image) │
└─────────┘ └─────────┘ └─────────┘
```
Each node is content-addressed. Changing any leaf updates the entire path to root.
** Vector Clock**
#+begin_src typescript
interface VectorClock {
// Per-persona, per-device counter
clocks: Record<DID, Record<string, number>>;
// DID -> device ID -> counter
}
function compareClocks(a: VectorClock, b: VectorClock): 'before' | 'after' | 'concurrent' | 'equal' {
let aGreater = false, bGreater = false;
const allKeys = new Set([...Object.keys(a.clocks), ...Object.keys(b.clocks)]);
for (const key of allKeys) {
const aVal = a.clocks[key] || 0;
const bVal = b.clocks[key] || 0;
if (aVal > bVal) aGreater = true;
if (bVal > aVal) bGreater = true;
}
if (aGreater && bGreater) return 'concurrent';
if (aGreater) return 'after';
if (bGreater) return 'before';
return 'equal';
}
#+end_src
** Sync Protocol
** Phase 1: Hello
Client announces itself and current state:
#+begin_src typescript
interface DeltaSyncHello {
// Identity
client_did: DID;
device_id: string; // Unique per-device
// Current state
last_sync_cid?: CID; // Last known root CID
local_vector: VectorClock;
// Capabilities
compression: ('gzip' | 'zstd' | 'none')[];
encoding: ('cbor' | 'msgpack' | 'json')[];
// Preferences
full_sync_if_older_than?: number; // Seconds
}
#+end_src
** Phase 2: Change Query
PDS determines what changed:
#+begin_src typescript
interface ChangeQuery {
// What client already has
last_known_root_cid?: CID;
last_sync_vector: VectorClock;
// What to sync
sync_scope: {
personas?: DID[]; // Which personas
since?: number; // Since timestamp
until?: number; // Until timestamp
flags?: FlagFilter; // Filter by flags
};
// Options
include_bloom?: boolean; // Return bloom filter of changes
}
interface ChangeResponse {
// Delta info
has_changes: boolean;
new_root_cid: CID;
new_cids: CID[]; // New content since last sync
deleted_cids: CID[]; // Content deleted since last sync
// For large syncs
bloom_filter?: Buffer; // Bloom filter of all current CIDs
chunk_count?: number; // If using chunked transfer
// Vector clock update
updated_vector: VectorClock;
}
#+end_src
** Phase 3: Delta Transfer
#+begin_src typescript
interface DeltaRequest {
cids: CID[];
format: 'objects' | 'chunks' | 'both';
encoding: 'cbor' | 'msgpack';
compression?: 'gzip' | 'zstd';
}
interface DeltaResponse {
objects: Map<CID, ContentObject>; // Full objects
chunk_map?: Map<CID, ChunkInfo[]>; // If chunked
merkle_proofs: MerkleProof[]; // Prove CIDs belong to root
transfer_id: string; // For resume
}
#+end_src
** Phase 4: Confirmation
#+begin_src typescript
interface SyncConfirmation {
// What we received
received_cids: CID[];
received_root_cid: CID;
// Verification
merkle_valid: boolean;
vector_clock_updated: boolean;
// Next sync
next_sync_after: number;
}
interface SyncComplete {
status: 'success' | 'partial' | 'failed';
new_root_cid: CID;
updated_vector: VectorClock;
}
#+end_src
** Full Sync vs Delta Sync
** Decision Algorithm**
```
IF last_sync is undefined OR older_than(threshold):
→ FULL SYNC (send bloom filter, all objects)
ELSE:
→ DELTA SYNC (send only changes)
```
** Full Sync Flow**
1. Client sends last_sync = null
2. PDS returns full bloom filter of all CIDs
3. Client calculates which CIDs missing locally
4. Client requests missing objects in batches
5. PDS returns objects + merkle proofs
6. Client verifies proofs, updates local merkle tree
7. Client confirms sync complete
** Chunking Strategy
For large content (images, videos, files):
** Content Hash Chunking (Baba)}
#+begin_src typescript
interface ChunkInfo {
chunk_id: string; // Hash of chunk content
offset: number; // Position in file
size: number; // Chunk size in bytes
content_hash: string; // SHA-256 of chunk
}
interface ChunkedContent {
original_cid: CID; // CID of original (for small files)
chunk_cids: CID[]; // CIDs of each chunk
chunk_info: ChunkInfo[];
total_size: number;
algorithm: 'babelfish' | 'fixed' | 'rabin';
}
// Sync only changed chunks
async function syncChunks(
localChunks: ChunkInfo[],
remoteChunks: ChunkInfo[]
): Promise<ChunkInfo[]> {
const localHashes = new Set(localChunks.map(c => c.content_hash));
return remoteChunks.filter(c => !localHashes.has(c.content_hash));
}
#+end_src
** Resume Interrupted Sync
If sync is interrupted, client can resume:
#+begin_src typescript
interface ResumeRequest {
transfer_id: string;
last_received_cid?: CID; // Where we left off
}
interface ResumeResponse {
// [[id:22d0a159-68a2-4587-9375-5046beddc20c][Continue]] from where left off
remaining_cids: CID[];
next_chunk_index: number;
}
#+end_src
** Implementation Example
#+begin_src typescript
import { CID } from 'multiformats';
import { MMT } from 'merkle-mountain-range';
/**
* Delta Sync Engine
*/
export class DeltaSyncEngine {
private localTree: MMT;
private vectorClock: VectorClock;
private lastSyncCID?: CID;
/**
* Perform delta sync with PDS
*/
async syncWithPDS(pdsEndpoint: string): Promise<SyncResult> {
// Phase 1: Hello
const hello: DeltaSyncHello = {
client_did: this.did,
device_id: this.deviceId,
last_sync_cid: this.lastSyncCID,
local_vector: this.vectorClock,
compression: ['zstd', 'gzip', 'none'],
encoding: ['cbor', 'msgpack', 'json'],
full_sync_if_older_than: 86400 // 24 hours
};
const helloResp = await this.post('/sync/hello', hello);
// Phase 2: Query changes
const query: ChangeQuery = {
last_known_root_cid: this.lastSyncCID,
last_sync_vector: this.vectorClock,
sync_scope: { personas: [this.did] }
};
const changeResp = await this.post('/sync/query', query);
if (!changeResp.has_changes) {
return { status: 'no_changes', timestamp: Date.now() };
}
// Phase 3: Fetch delta
if (changeResp.new_cids.length > 0) {
// Check if we need full sync
if (changeResp.new_cids.length > 1000 || !this.lastSyncCID) {
return await this.performFullSync(pdsEndpoint, changeResp);
}
// Delta sync
const delta = await this.fetchDelta(pdsEndpoint, changeResp.new_cids);
await this.applyDelta(delta);
}
// Phase 4: Confirm
const confirm: SyncConfirmation = {
received_cids: changeResp.new_cids,
received_root_cid: changeResp.new_root_cid,
merkle_valid: await this.verifyMerkleProofs(delta),
vector_clock_updated: true,
next_sync_after: Date.now() + 3600000
};
const complete = await this.post('/sync/confirm', confirm);
// Update local state
this.lastSyncCID = complete.new_root_cid;
this.vectorClock = complete.updated_vector;
return {
status: 'success',
cids_synced: changeResp.new_cids.length,
root_cid: complete.new_root_cid
};
}
private async performFullSync(
pds: string,
changes: ChangeResponse
): Promise<SyncResult> {
// Get bloom filter
const allCIDs = await this.requestAllCIDs(pds);
// Find missing
const localCIDs = new Set(await this.getLocalCIDs());
const missingCIDs = allCIDs.filter(c => !localCIDs.has(c));
// Fetch in batches
const batchSize = 100;
for (let i = 0; i < missingCIDs.length; i += batchSize) {
const batch = missingCIDs.slice(i, i + batchSize);
const objects = await this.fetchObjects(pds, batch);
await this.applyObjects(objects);
}
return { status: 'full_sync', cids_synced: missingCIDs.length };
}
}
#+end_src
** Compression & Encoding
| Format | Compression | Typical Reduction |
|--------|-------------|-------------------|
| CBOR | None | 1x |
| CBOR | Gzip | 3-5x |
| CBOR | Zstd | 4-7x |
| Msgpack | None | 1.1x |
| JSON | None | 0.8x (larger) |
*Recommended:* CBOR + Zstd for bandwidth, CBOR for CPU-constrained devices.
** Related Gaps
This closes:
- Delta Sync Protocol (CRITICAL)
- Conflict Resolution Algorithm (CRITICAL - partial, see PDS Sync doc)
# Local Variables:
# org-confirm-babel-evaluate: nil
# End:

96
projects/passepartout/social-protocol/requirements-10-governance-and-assets.org Normal file
View File

@@ -0,0 +1,96 @@
#+title: Social Protocol Requirements - 10: Governance and Physical Assets
#+author: Amero Garcia
#+created: [2026-03-22 Sun]
#+ID: agora-requirements-10-governance
#+STARTUP: content
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 68ffa49f-f0d8-42cf-8b69-ae69de8bb815
:END:
* Governance and Physical Assets
** Overview
This section expands [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Social Protocol]]'s capabilities beyond digital communication and into physical reality and organizational coordination. By integrating Physical Asset Linking (PAL) and the Governance Executable Module (GEM), the protocol empowers Collectives to manage real-world resources and execute democratic decisions autonomously via smart contracts.
** Governance Executable Module (GEM)
** Concept
Governance in the protocol isn't just about voting; it's about executing the results of those votes. The GEM ensures that when a community (a Collective Persona) makes a decision, the protocol enforces it without relying on trusted intermediaries or manual intervention.
** The Governance Stack
Governance operates at three distinct scales, mirroring the human organization patterns of the Sovereign Stack:
- *Micro-Governance (The Persona/Household):* Decisions made by a single seed holder or a small family multi-sig (e.g., "Who can spend from the grocery Lightning wallet?").
- *Meso-Governance (The NGO/LLC/Circle):* Decisions made by a defined group using Weighted Voting (e.g., "Should our NGO hire this contractor?").
- *Macro-Governance (The Protocol/Network):* Decisions that affect the entire ecosystem (e.g., "Should we upgrade the PDS data schema to version 2.0?").
** Advanced Voting Mechanisms
To prevent plutocracy ("one-token, one-vote" dominance) and ensure healthy community dynamics, GEM supports pluggable mathematical models:
- *Quadratic Voting:* The cost of a vote increases by the square of the votes cast ($cost = votes^2$). This prevents whales from dominating and allows users to signal the *intensity* of their preference across multiple proposals.
- *Conviction Voting:* Voters "stake" their preference over time. The longer a user holds their vote on a proposal, the more weight it gains. This rewards long-term thinkers and prevents flash-mob takeovers.
- *Liquid Democracy:* Users can delegate their "Moderation Vote" or "Treasury Vote" to a trusted expert. If the expert acts poorly, the user can instantly revoke the delegation.
** Constitution as Code
A Collective Persona's rules are stored as an executable Smart Constitution.
- *Policy Triggers:* If a vote passes to "Increase the Group's Arbitration Fee," the GEM automatically updates the fee parameter across all the Collective's active contracts. No human administrator is needed to change the settings.
- *Veto & Cooling Off:* High-impact changes (e.g., moving treasury funds) include a mandatory Time-Lock (e.g., 7 days). The vote passes, but execution is delayed, giving the community a "Cooling-Off Period" to trigger a counter-vote or fork if they suspect foul play.
** Evolvable Governance: Adaptive Constitutions
Unlike traditional blockchain-based DAOs, where governance rules are often "frozen" in immutable smart contract code, the protocol's DAOs (Collectives) are designed to be evolvable. While the *history* of every decision is immutable and cryptographically traceable, the *active rules* of the organization can be updated through its own internal governance process.
*** Immutable History, Mutable State
Every version of a Collective's Smart Constitution, every vote cast, and every policy change is recorded as a signed Note identified by a unique CID. This creates a perfect, unalterable audit trail. However, the "current state" of the Collective is defined by the most recent validly signed constitutional Note. This allows the organization to learn, adapt, and correct its course over time without requiring complex migrations or "forking" into entirely new software deployments.
*** Recursive Rule-Making
The GEM supports recursive governance: the rules for *how* to change the rules are themselves defined within the Smart Constitution. A Collective might start with a simple multi-sig requirement for all changes and later vote to transition to a more complex Quadratic Voting model for policy updates, all while maintaining a continuous cryptographic identity.
*** Forks as a Sovereign Safety Valve
Because the protocol is decentralized and permissionless, "forking" is a legitimate and supported governance mechanism. If a minority of a Collective disagrees fundamentally with a constitutional change, they can choose to "fork" the organization by creating a new Collective Persona based on the previous CID of the constitution. This ensures that no community is ever trapped by a "majority tyranny" that has lost its original purpose.
** Automated Treasury Payroll (Streaming Lightning)
The GEM connects governance directly to economic flow.
- *Vote to Hire:* A Collective votes to hire a contractor (a Persona DID) for 100,000 sats/month.
- *Execution:* Once the vote passes and the contract is signed by both parties, the GEM automatically instructs the Collective's Treasury Wallet to open a Lightning channel to the contractor and begin "streaming" payments block-by-block.
- *Algorithmic Severance:* If a "Fire Contractor" or "Stop Work" vote subsequently passes, the GEM instantly closes the HTLC stream. Human intervention is not required to stop payroll.
** Physical Asset Linking (PAL)
The PAL protocol bridges physical objects (cars, houses, shipments, equipment) into the digital Contract layer. This enables physical assets to be used as collateral or traded via sovereign, cryptographically secured agreements.
*** 1. Digital Twins & Tokenization
Every physical asset is represented by a "Digital Twin" on the network, which acts as its definitive digital record.
- *The Digital Passport:* This is a Verifiable Credential (VC) issued by a trusted entity (e.g., a manufacturer, community inspector, or professional guild) to a Persona. It proves the asset's attributes, provenance, and authenticity.
- *Tokenization (Legal Title):* For high-value assets, a Persona can "mint" an NFT-like token (as a specialized Note or on an integrated sidechain). This token represents the "Legal Title" of the asset. Ownership of the token is cryptographically equivalent to holding the deed.
- *Fractionalization:* Large assets can be fractionalized. For example, an NGO can tokenize a community building, allowing 1,000 members to own 0.1% each. Their voting power in the Governance (GEM) layer is then tied directly to these fractional tokens.
*** 2. Physical Collateral in Civil Contracts
PAL allows users to secure loans or agreements using physical assets as collateral, providing a robust "Justice-as-a-Service" model even in environments with weak state institutions.
- *The Pledge:* A user links their Digital Twin token to a Civil Contract Note.
- *The Lock:* Once pledged, the smart contract logic "freezes" the token. The user retains physical possession of the object, but they cannot cryptographically sell or transfer the digital title until the contract terms are fulfilled or the debt is settled.
- *The "IoT Stick" (Optional):* For high-stakes assets (e.g., a tractor, factory machine, or smart-lock-equipped real estate), an IoT sensor can be bound to the contract. If the Hierarchical Dispute Resolution (HDR) module rules that a user has defaulted, the contract sends a signed signal to the machine's "Smart Lock" to disable its operation until the obligation is met.
** Decentralized Justice & Dispute Resolution (The Court System)
To enforce Civil Contracts and resolve Governance disputes without a central state, the protocol implements a Hierarchical Dispute Resolution (HDR) framework. This mirrors the traditional legal system but replaces "jurisdiction by geography" with "jurisdiction by reputation and stake."
*** The Multi-Level "Court" Hierarchy
Disputes are not settled by a single monolithic entity. Parties opt into a hierarchy of arbitration when creating a contract.
- *Level 1 (Local/Immediate):* A "Local Elder" or a specifically chosen lightweight arbitrator.
- *Level 2 (Guild/Specialized):* A specialized Arbitration Guild (e.g., the "Carpenters' Guild" for a furniture dispute).
- *Level 3 (Global Jury):* The Final Court of Appeal, often a randomized, highly staked global jury.
*** The Mechanics of an Appeal (Cryptographic Escalation)
In this system, an "Appeal" isn't a bureaucratic request; it is a *Cryptographic Escalation*.
- *Level 1 Ruling:* The Level 1 arbitrator makes a ruling. If both parties accept the cryptographic signature of the ruling, the HODL invoice settles immediately.
- *The Trigger:* If one party disagrees with the ruling, they must pay an "Appeal Fee" via Lightning. This fee prevents spam and economically funds the next level of jurors.
- *The Escalation:* Paying the fee mathematically "unlocks" the case for Level 2 (The Guild). The contract logic automatically pushes the data (evidence, previous ruling) to the new panel's shared PDS.
- *Finality:* Level 3 is the "Final Court of Appeal." Once the global jury rules, their combined threshold signature releases the cryptographic keys. The smart contract executes the payment automatically—no human can stop it.
*** Why This Works in "Weak States" (Self-Executing Justice)
In jurisdictions where state police won't help collect a debt, or where courts are corrupt/slow, the protocol provides Self-Executing Justice. It relies on two powerful enforcement mechanisms rather than physical violence:
1. *The Escrow Stick:* The funds are already gone from the buyer's wallet. They are locked cryptographically in a Lightning HODL Escrow. The buyer cannot "run away" with the money; they must engage in the arbitration process to get it back or see it released to the seller.
2. *The Reputation Stick:* In a decentralized society, a Persona's DID is their livelihood. Defying a Level 3 ruling, or accumulating a history of defaulted contracts, destroys a Persona's "Trust Score." In a system built on verifiable attestations, losing this reputation is a digital death sentence for a business, making compliance highly incentivized.

37
projects/passepartout/social-protocol/requirements-10-user-journey.org Normal file
View File

@@ -0,0 +1,37 @@
#+title: Social Protocol Requirements: User Journey & Product Experience
#+AUTHOR: Passepartout Social Protocol
#+DATE: 2026-03-26
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 2cace571-76bb-4c34-a5f4-68bc20b2e884
:END:
* The Sovereign User Journey
This document outlines the cohesive, narrative user journey of the [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Social Protocol]] platform, illustrating how the underlying technical primitives (Master Keys, DIDs, PDS, Lightning, and Smart Contracts) translate into a seamless product experience.
** Phase 1: Onboarding (The Birth of the Persona)
- *Download & Seed:* The user downloads the app. The very first action the app takes is generating a cryptographic Seed Phrase (the Master Key / Anima). This anchors their sovereignty immediately.
- *Persona Creation:* The user is not asked to create a global "Username." Instead, they create context-specific Personas, for example, a "Work" persona and a "Social" persona. Behind the scenes, the app derives two distinct DIDs from the single Master Key.
- *The Founder Connection (Minors):* For younger users (minors), a parent or guardian can scan a QR code to "Co-sign" the identity inception. This immediately establishes the Succession Logic and delegated authority outlined in the Identity specifications.
- *PDS Selection:* The user is prompted with: "Where would you like to store your data?" They are presented with options and might select a Community PDS run by a local NGO or guild they trust, ensuring their data sovereignty from day one.
** Phase 2: Consumption & "Seeding" (The Data Economy)
- *Choosing a Lens:* The user navigates to the "Marketplace" and selects a curation algorithm, such as the "Scientific Signal" Lens. Their feed instantly rearranges to prioritize verified research and high-signal content, bypassing centralized algorithmic manipulation.
- *Micro-Earning (Bandwidth Sharing):* The user watches a video. In their settings, a toggle is enabled: "Support this creator by seeding." As they watch, their phone (via WebRTC) serves bits of the video to 3 other nearby users, acting as an ephemeral CDN node.
- *The Reward:* Because they provided bandwidth and aided the network, the creator’s PDS sends a micro-transaction "Thank You" of 5 sats ($0.002) directly to the user’s integrated Lightning wallet. While small, this passive income covers the cost of their own PDS hosting for the month.
** Phase 3: The Civil Contract (Digital Law)
- *The Deal:* User A wants to purchase a custom-built chair from User B.
- *The Contract:* They click "Create Contract" and select a standardized Markdown Template for "Handmade Goods."
- *Arbitration Choice:* Both parties agree to use the "Carpenters' Guild" as the Level 2 Arbitrator in case of a dispute.
- *The Lock:* User A pays the Lightning invoice. The funds move into a HODL Escrow. User B sees the "Funds Locked" status and confidently begins building the chair.
- *The Delivery:* User B delivers the chair. User A scans a QR code physically attached to the chair, which acts as the cryptographic release of the Preimage, instantly settling the smart contract and paying User B.
* Related Documents
- [[id:6fe67db6-25bd-4d11-bd1d-b44ec809e858][02 Identity (Master Keys & Personas)]]
- [[id:3b43a9b8-31d1-4479-a35f-22273b74f0c7][03 Infrastructure (PDS & WebRTC Seeding)]]
- [[id:90484f4a-5b70-4001-93d6-e610e54ed573][06 Exchange & Contracts (HODL Escrows & Arbitration)]]

76
projects/passepartout/social-protocol/requirements-11-assessment.org Normal file
View File

@@ -0,0 +1,76 @@
#+title: Social Protocol Requirements - 11: Realistic Assessment
#+author: Amero Garcia
#+created: [2026-03-16 Mon 14:28]
#+DATE: 2026-03-22
#+ID: agora-requirements-10-assessment
#+STARTUP: content
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 72570648-d943-42e5-a781-3b09791ac6ec
:END:
* Realistic Assessment: Practicality, Technology, and Performance
The [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Social Protocol]], following the integration of the Aletheia architecture, represents a significant leap beyond simple social networking into a comprehensive "Sovereign Social Operating System." This assessment evaluates the protocol's viability across three critical pillars.
** 1. Practicality: The Sovereignty vs. UX Trade-off
The protocol's practicality hinges on whether users can manage its cryptographic complexity without constant friction.
*** Strengths
- *Functional Autonomy:* The "Sub-Root" HD derivation path (`m/44'/1'/account'/persona'/key_purpose/key_index`) is a major practical win. By allowing devices to derive operational keys (Lightning, PGP) autonomously, the protocol reduces the "[[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Hardware]] Wallet Fatigue" that plagues self-sovereign systems.
- *Unified Logic:* The "Everything is a Note" model simplifies the backend infrastructure (PDS/Relays), as they only need to handle a single data structure regardless of whether it's a social post or a legal contract.
*** Challenges
- *The "Client-Side Weight" Problem:* Because the underlying protocol is "dumb" (routing signed blobs), the client application must do the heavy lifting of parsing JSON-LD, verifying signatures, and rendering complex contract logic. Building a high-performance client that remains responsive while doing this is a significant engineering challenge.
- *Recovery Education:* Even with Blinded Sharding and Social Recovery, the concept of "losing your seed = losing your digital life" remains a massive barrier to mainstream adoption.
** 2. Technology: Cryptographic Robustness
The technical stack is grounded in industry-standard primitives used in Bitcoin and DID ecosystems, ensuring high confidence in its core security.
*** Technological Pillars
- *Identity:* Leveraging BIP-44 and Ed25519 provides a battle-tested foundation for unlinkable personas.
- *Privacy:* The combination of E2EE (Double Ratchet/MLS), Blinded Sharding, and Zero-Knowledge Proofs (ZKPs) for cross-persona Notes places the protocol at the forefront of privacy-preserving social protocols.
- *Commerce:* Integrating LSATs and HODL invoices directly into the content layer (SCAL) is technically sound but relies heavily on the continued [[id:26f3e845-5eb4-4bcd-9cff-28e219934841][growth]] and stability of the Lightning Network.
*** Critical Risks
- *ZKP Complexity:* Implementing efficient ZKPs for identity linking that run on mobile hardware is technically non-trivial and may require specialized libraries or "Prover" sub-agents.
- *Quantum Readiness:* While Pre-rotation (KEL) provides a path to forward security, the protocol must eventually transition to post-quantum algorithms (e.g., Dilithium) as they become standardized.
** 3. Performance: Scalability and Efficiency
The protocol's performance model is decentralized by design, avoiding the "Global State" bottlenecks of traditional blockchains.
*** Scaling Models
- *Reference-on-Send (Public Content):* Highly scalable. Only notifications and CIDs are pushed; content is pulled on-demand. This mirrors the efficient scaling of the web (CDNs/caching).
- *Copy-on-Send (Private Content):* Resource-intensive. A direct message to 100 people creates 100 unique, encrypted Notes. While this ensures sovereignty, it places a higher storage and bandwidth burden on PDS providers compared to "Single-Instance" storage models.
*** Optimization Strategies
- *Delta Sync:* Essential for mobile performance. By only transferring differential updates between the Client and PDS, the protocol can maintain low latency even over poor network connections.
- *Relay-as-Indexer:* High-performance Relays can act as opt-in indexers, providing fast search and discovery without users surrendering their data ownership.
** Success Probability & Timeline
| Milestone | Timeline | Probability | Note |
|-----------|----------|-------------|------|
| 100K users | 2-3 years | 40% | Niche-market focus (freelancers, privacy advocates) |
| 1M users | 4-5 years | 20% | Requires a "Killer App" (e.g., Sovereign Marketplace) |
| 10M users | 7-10 years | 10% | Dependent on "Big Tech" fatigue/regulatory pressure |
** Codebase Size Estimate
- *Core Protocol (PDS/Relay Spec):* 50-80K lines of code.
- *Universal Client (iOS/Android):* 150-250K lines of code.
- *Smart Contract Engine (SCAL/GEM):* 100K lines of code.
- *Total v1.0 Stack:* 400-600K lines of code.
** Conclusion: A Pragmatic Revolution
The protocol is technically viable but architecturally demanding. It is not a project that can be built by a single "full-stack developer" in a weekend. It requires a specialized team of cryptographers, systems engineers, and UX designers. However, because it avoids the "Global Consensus" trap of blockchains, its performance characteristics are much closer to the traditional web, making it a truly practical alternative for building a sovereign digital civilization.
** Related Documents
- [[id:b25bf753-9799-41ab-82f5-1a1416db756b][01: Overview]]
- [[id:6fe67db6-25bd-4d11-bd1d-b44ec809e858][02: Identity]]
- [[id:8b4e0cec-a7b0-4e75-a1e3-c55ae820eb6d][09: Implementation]]

8
projects/passepartout/strategy/_index.org Normal file
View File

@@ -0,0 +1,8 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 9c3d4e5f-6a7b-8c9d-0e1f-2a3b4c5d6e7f
:END:
#+title: Strategy
#+filetags: :index:
Business strategy, competitive analysis, compliance landscape, and market positioning for the verified infrastructure category.

5
ideas/ai-industry-impact.org → projects/passepartout/strategy/ai-industry-impact.org
View File

@@ -1,4 +1,5 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 5f55bbe6-d243-5766-8ccf-5c5cc88a6542
:END:
#+title: Impact on the AI and GPU Industry
@@ -6,10 +7,10 @@
If a symbolic-bootstrapping architecture becomes popular, the industry structure shifts fundamentally:
**Token demand compresses.** The entire AI industry (OpenAI, Anthropic, Google — ~$50B API revenue) is built on per-token pricing. A mature Passepartout reduces token consumption to the unfamiliar 10% I/O boundary. Steady-state per-user LLM consumption drops by an order of magnitude.
**Token demand compresses.** The entire AI industry (OpenAI, Anthropic, Google — ~$50B API revenue) is built on per-token pricing. A mature [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] reduces token consumption to the unfamiliar 10% I/O boundary. Steady-state per-user LLM consumption drops by an order of magnitude.
**GPU inference demand plateaus in regulated industries.** Inference demand drops 80-90% in any sector where the rule book is published — which covers most economically significant sectors (finance, healthcare, industrial, government procurement, legal compliance). Nvidia's growth narrative shifts from "every transaction goes through a GPU" to "every training run needs a GPU."
**Hyperscaler competition shifts.** The race shifts from "who has the most H100s" to "who has the best domain-specific gate rules." Google's industry data advantage matters more than Azure's raw compute.
**New hardware tier emerges:** CPU-native [[file:self-driving-lisp-machine.org][verification appliances running Lisp microcode]] on RISC-V cores. Low volume (hundreds of thousands/year), high margin ($5K-50K/unit). Manufacturable at older fab nodes (28nm, 45nm) — no dependency on TSMC's leading edge. This hardware embodies [[file:lisp-economics.org][Lisp economics]] — the cost of verification approaches zero once the symbolic engine is running on dedicated silicon. The outcome is a [[file:verification-monopoly.org][verification monopoly]] for agent safety — the same certification dynamic UL provides for electrical safety.
**New hardware tier emerges:** CPU-native [[id:13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70][verification appliances running Lisp microcode]] on RISC-V cores. Low volume (hundreds of thousands/year), high margin ($5K-50K/unit). Manufacturable at older fab nodes (28nm, 45nm) — no dependency on TSMC's leading edge. This hardware embodies [[id:9af13fff-9725-542b-93b1-a555bc74ad72][Lisp economics]] — the cost of verification approaches zero once the symbolic engine is running on dedicated silicon. The outcome is a [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] for agent safety — the same certification dynamic UL provides for electrical safety.

8
projects/passepartout/strategy/competitors/_index.org Normal file
View File

@@ -0,0 +1,8 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 0d4e5f6a-7b8c-9d0e-1f2a-3b4c5d6e7f8a
:END:
#+title: Passepartout — Competitive Analysis
#+filetags: :index:
Competitive analysis of AI coding agents, verification platforms, and the broader infrastructure landscape.

22
projects/passepartout/strategy/competitors/ai-agents-scoping/aider.org Normal file
View File

@@ -0,0 +1,22 @@
:PROPERTIES:
:ID: c3aab2e8-7e43-4abc-93f0-741675cfd78c
:CREATED: [2026-05-22 Thu]
:END:
#+title: Aider — AI Coding Agent
#+filetags: :passepartout:strategy:competitive:aider:
Language: Python. ~6.8M pip installs. ~40K lines. MIT license. The oldest and most mature open-source coding agent.
Architecture: Chat-based Coder class with 5 edit formats (diff, udiff, patch, whole, architect). Uses litellm for universal provider access (50+ providers). RepoMap provides codebase awareness via cosine-similarity embedding.
Safety model: Purely prompt-based plus user-confirmation dialogs. No deterministic gate stack. No sandboxing. No model output validator. The allowed_to_edit() gate is a single user confirmation call. --yes flag auto-approves. Aider can edit its own source code with no special protection — self-modification is undetectable.
Data model: Ad-hoc. Chat messages in memory. Git commits for persistence. RepoMap is a cosine-similarity index. No persistent memory across sessions. No knowledge graph.
Self-modification: Full. No guard against editing its own files.
Verification: None.
Key gap vs Passepartout: No safety gates, no persistent memory model, no knowledge representation, no verification, no self-modification protection, no architecture for neurosymbolic reasoning. It is a thin shell around litellm + edit format parsers.
See the full [[id:3aa22300-2f25-57b0-8787-9f199cc978b1][competitive analysis]] for the landscape view and comparison.

22
projects/passepartout/strategy/competitors/ai-agents-scoping/claude-code.org Normal file
View File

@@ -0,0 +1,22 @@
:PROPERTIES:
:ID: 512dd121-2292-4f3d-ac53-31bf3d12a60f
:CREATED: [2026-05-22 Thu]
:END:
#+title: Claude Code — Anthropic AI Coding Agent
#+filetags: :passepartout:strategy:competitive:claude-code:
Anthropic's proprietary coding agent. TypeScript/Bun, ~512K lines (leaked source analysis). Not open source.
Architecture: Bun-bundled TypeScript single-file executable. Ink/React terminal UI. 23+ core tools. Subagent forking with byte-identical API prefixes for prompt cache sharing. Multi-agent coordination mode.
Safety model: Layered deterministic safety — NOT prompt-based: 7 permission modes, persistent permission rules (alwaysAllow/alwaysDeny/alwaysAsk from 4 sources), bash security validator at 2,592 lines with 23+ named security checks using tree-sitter AST parsing, sandbox runtime, path/mode validation, optional ML bash classifier. This is the most sophisticated safety system of any coding agent analyzed.
Data model: File-based markdown memdir at ~/.claude/projects/<slug>/memory/. 4 memory types: user, feedback, project, reference. YAML frontmatter in .md files. PROJECT.md and CLAUDE.md for project config. No database.
Self-modification: HIGH. Skill system writes SKILL.md files. Plugin system, cron scheduling, agent spawning.
Verification: None.
Key gap vs Passepartout: No proof system, no neurosymbolic architecture, no self-verification, no persistent knowledge graph (flat markdown files, not Org-mode with cross-references), markdown data model lacks semantic depth. Proprietary — Anthropic controls it completely. The permission rules system is impressive but structurally inferior to Passepartout's gate stack because rules are heuristic (regex-based pattern matching) rather than typed (type-level gates with structural guarantees).
See the full [[id:3aa22300-2f25-57b0-8787-9f199cc978b1][competitive analysis]] for the landscape view and comparison.

22
projects/passepartout/strategy/competitors/ai-agents-scoping/codex-cli.org Normal file
View File

@@ -0,0 +1,22 @@
:PROPERTIES:
:ID: e929ff32-28d8-4a29-bf74-d55babc040d1
:CREATED: [2026-05-22 Thu]
:END:
#+title: Codex CLI — OpenAI AI Coding Agent
#+filetags: :passepartout:strategy:competitive:codex:
OpenAI's open-source coding agent. Rust, ~950K lines, sandboxed.
Architecture: ~116 crate Rust workspace with a protocol layer (SQ/EQ session types), sandbox manager (macOS Seatbelt, Linux nsjail), multi-provider support, configurable TUI.
Safety model: Most sophisticated safety system of any coding agent analyzed. Multi-layer: process hardening (macOS Seatbelt with 4 profile tiers), execution policy engine, sandboxing via nsjail/Seatbelt, Guardian module for tool permission gating. No prompt-based safety — all deterministic through policy definitions.
Data model: Protocol-defined session types. Structured request/response models. Config through TOML files with schema validation.
Self-modification: Protected by sandbox — the agent cannot escape to modify its own binary or config without explicit policy override.
Verification: None (no proof system).
Key gap vs Passepartout: No knowledge graph, no persistent memory model, no deterministic gate stack for agent behavior (only OS-level sandboxing), no ACL2/prover, no neurosymbolic architecture. Strongest sandbox but weakest cognitive architecture.
See the full [[id:3aa22300-2f25-57b0-8787-9f199cc978b1][competitive analysis]] for the landscape view and comparison.

22
projects/passepartout/strategy/competitors/ai-agents-scoping/continue.org Normal file
View File

@@ -0,0 +1,22 @@
:PROPERTIES:
:ID: 22d0a159-68a2-4587-9375-5046beddc20c
:CREATED: [2026-05-22 Thu]
:END:
#+title: Continue — CI/Check System
#+filetags: :passepartout:strategy:competitive:continue:
TypeScript, ~328K lines, Apache 2.0. Source-controlled AI checks for CI/CD. Markdown-as-gate-policy.
Architecture: Shared core (@continuedev/core) with ~80 provider implementations, tool-calling engine, config system (YAML/JSON/Markdown). Serves CLI (Ink/React TUI + headless CI mode), IDE extensions (VS Code, JetBrains), web dashboard.
Safety model: Three permission levels (allow/ask/exclude). Precedence: mode policies → CLI flags → permissions.yaml → built-in defaults. Terminal security package for shell command analysis via shell-quote parsing. Workspace-scoped file access.
Data model: Markdown files for checks, agents, rules. Source-controlled in-repo. YAML frontmatter for metadata.
Self-modification: Checks source-controlled — any change goes through git.
Verification: None (the checks are themselves unverified).
Key gap vs Passepartout: The checks-as-markdown concept is philosophically similar to Passepartout's gate rules (deterministic policies checked before execution) but the implementation is dramatically simpler — regex-based policy objects, not a type-level gate stack with structural guarantees. No persistent agent, no memory, no knowledge graph, no neurosymbolic architecture. It is a gate system without an agent to gate.
See the full [[id:3aa22300-2f25-57b0-8787-9f199cc978b1][competitive analysis]] for the landscape view and comparison.

22
projects/passepartout/strategy/competitors/ai-agents-scoping/gemini-cli.org Normal file
View File

@@ -0,0 +1,22 @@
:PROPERTIES:
:ID: 8d73ccb9-34e4-4899-b0c3-605998e9bebc
:CREATED: [2026-05-22 Thu]
:END:
#+title: Gemini CLI — Google AI Coding Agent
#+filetags: :passepartout:strategy:competitive:gemini:
Google's open-source coding agent. TypeScript, ~525K lines, Apache 2.0. Node.js 20+, Ink/React TUI.
Architecture: 7-package npm monorepo. Core backend handles Gemini API orchestration, tool execution, policy engine, safety checks, sandbox management, session management, MCP client. 7-strategy composite model routing chain.
Safety model: Multi-layered: CONSECA (Contextual Security Checker) — AI-driven per-request policy generation using a separate Gemini Flash model. 4 approval modes (PLAN/DEFAULT/AUTO_EDIT/YOLO). 6 sandbox methods (macOS Seatbelt, Docker/Podman, bwrap, gVisor, LXC, Windows). Trusted folders with path traversal protection. Policy integrity via cryptographic hashes. Loop detection.
Data model: JSONL session files. Turn-based conversation model. 4-layer config precedence (system-defaults → user → project → system-override). TOML policy files.
Self-modification: Modifiable hooks system, MCP extensions, custom commands. Core binaries are protected on disk by file permissions.
Verification: None.
Key gap vs Passepartout: No proof system, no persistent knowledge graph, no self-verification, no neurosymbolic architecture, lock-in to Google Gemini models. CONSECA is interesting (AI-generated policies) but introduces a second LLM call for every security decision — the opposite of Passepartout's zero-token deterministic gating.
See the full [[id:3aa22300-2f25-57b0-8787-9f199cc978b1][competitive analysis]] for the landscape view and comparison.

22
projects/passepartout/strategy/competitors/ai-agents-scoping/hermes-agent.org Normal file
View File

@@ -0,0 +1,22 @@
:PROPERTIES:
:ID: c652688a-1ea0-487c-9222-00e954efe8a1
:CREATED: [2026-05-22 Thu]
:END:
#+title: Hermes Agent — Personal AI Assistant
#+filetags: :passepartout:strategy:competitive:hermes:
The agent running this conversation. Python, ~17K core lines, MIT.
Architecture: Synchronous conversation loop with OpenAI-format messages. 60+ built-in tools. 109+ providers via pluggable transport layer. 15+ messaging platforms via gateway. MCP client (native, not bridge). Ink/React TUI as Node.js subprocess. Cron jobs, Kanban board, subagent delegation.
Safety model: Multi-layer but NOT a deterministic gate stack: message sanitization, Tirith binary scanner, command approval system, memory injection detection, secret/PII redaction, tool call guardrails, MCP security, context fencing. All heuristic or prompt-based — no structural type-level gates.
Data model: SQLite session DB (FTS5 full-text search). File-based memory (MEMORY.md + USER.md). YAML config. No knowledge graph. No Org-mode.
Self-modification: Skill system writes SKILL.md files. Memory tool edits MEMORY.md/USER.md. Core Python code is read-only in execution but no gate specifically prevents the LLM from requesting source modifications.
Verification: None.
Key gap vs Passepartout: No deterministic gate stack (heuristic layers, not structural/typed), no knowledge graph, no Org-mode, no neurosymbolic architecture, no self-verification, no proof system. Hermes's strength is breadth — 109 providers, 15 platforms, MCP ecosystem. But it has no depth in safety, knowledge representation, or reasoning architecture.
See the full [[id:3aa22300-2f25-57b0-8787-9f199cc978b1][competitive analysis]] for the landscape view and comparison.

22
projects/passepartout/strategy/competitors/ai-agents-scoping/openclaw.org Normal file
View File

@@ -0,0 +1,22 @@
:PROPERTIES:
:ID: 85ca69dd-d085-4a55-ad11-021910b1f82e
:CREATED: [2026-05-22 Thu]
:END:
#+title: OpenClaw — Personal AI Assistant
#+filetags: :passepartout:strategy:competitive:openclaw:
TypeScript/Node.js, ~3.5M lines. The largest codebase analyzed. Personal AI assistant with 25+ messaging channel support.
Architecture: pnpm workspace with ~135 bundled plugins. Gateway control plane routes messages through multi-agent routing. Per-agent sessions, workspaces, skill registries. Companion native apps (macOS, iOS, Android).
Safety model: Tiered — main agent runs tools directly on host (trusted-operator), non-main sessions sandboxed via Docker (read-only rootfs, capability dropping, seccomp/AppArmor, memory/cpu/PID limits, SSH/OpenShell backends).
Data model: Typed JSON/YAML config (openclaw.json). Multi-source model catalog. Plugin SDK with narrow typed subpath exports.
Self-modification: ACP (Agent Control Protocol) for spawning child sessions. Skill system with npm distribution and ClawHub registry.
Verification: None.
Key gap vs Passepartout: Same as Hermes — no gate stack, no knowledge graph, no Org-mode, no verification, no neurosymbolic architecture. Differentiated by vastly broader channel support and mature plugin ecosystem. But architecturally conventional — LLM + tools + channels, no cognitive architecture innovation.
See the full [[id:3aa22300-2f25-57b0-8787-9f199cc978b1][competitive analysis]] for the landscape view and comparison.

22
projects/passepartout/strategy/competitors/ai-agents-scoping/opencode.org Normal file
View File

@@ -0,0 +1,22 @@
:PROPERTIES:
:ID: 7a060b36-36db-4eb7-b8cc-844bd6ac9d36
:CREATED: [2026-05-22 Thu]
:END:
#+title: OpenCode — AI Coding Agent
#+filetags: :passepartout:strategy:competitive:opencode:
TypeScript/Bun. anomalyco/opencode, 163K★. The dominant open-source coding agent by adoption. Bun runtime, Effect-TS functional core, Solid.js TUI, Turborepo monorepo.
Architecture: Dual LLM runtime — default AI SDK (streamText/generateText) + opt-in native Effect-Schema runtime with 4-axis route decomposition (Protocol/Endpoint/Auth/Framing). 30+ provider plugins. Agent workflow DSL with plan/build agent switching. Agent Communication Protocol (ACP) for inter-agent messaging. Subagents inherit permission boundaries from parent. 18+ built-in tools + custom tools from config. Effect-TS ScopedCache per-project state management.
Safety model: Explicitly documents not sandboxing the agent. Permission system is rule-based (glob matching, actions: allow/ask/deny) and exists as a UX feature, not security isolation. Built-in agents have carefully scoped defaults. Permission rules inherited by subagents.
Data model: SQLite via Drizzle ORM with bun:sqlite or better-sqlite3. Key tables: SessionTable, MessageTable, PartTable. Project model stores worktree, VCS, sandbox config. Config is JSON-chain with remote config fetch.
Self-modification: Agent.generate() interface lets the LLM create new agent definitions — the system grows its own subagent roster. Skills system loads domain-specific knowledge packs dynamically.
Verification: None.
Key gap vs Passepartout: No deterministic safety architecture, no knowledge graph, no Org-mode, no verification/proof system, no neurosymbolic architecture. The permission system is explicitly labeled not security isolation — it's UX, not a gate stack.
See the full [[id:3aa22300-2f25-57b0-8787-9f199cc978b1][competitive analysis]] for the landscape view and comparison.

22
projects/passepartout/strategy/competitors/ai-agents-scoping/thoth.org Normal file
View File

@@ -0,0 +1,22 @@
:PROPERTIES:
:ID: 416bab7c-4300-4d50-838a-5c7a8ad45d96
:CREATED: [2026-05-22 Thu]
:END:
#+title: Thoth — Personal AI Sovereignty
#+filetags: :passepartout:strategy:competitive:thoth:
https://github.com/siddsachar/Thoth — Python, ~151K lines, Apache 2.0. Local-first desktop AI assistant with knowledge graph, tools, voice, vision, shell, browser automation, workflow engine, and messaging channels.
Architecture: LangGraph create_react_agent (prebuilt ReAct pattern). Dual-mode streaming. NiceGUI web UI with desktop launcher. Context trimming via tiktoken, base64 data redaction, stale browser snapshot compression, MD5 tool result dedup, old tool result summarization. Agent graph cached by tool set + model override. Checkpoints via LangGraph's SQLite-backed checkpointer. 30+ tool modules.
Safety model: Shell command classification with 17 blocked patterns, 30+ safe auto-execute prefixes, needs-approval for compound commands. Interactive interrupt for non-safe shell. Per-workflow safety modes (block/approve/allow_all). Prompt-injection defense (5 categories, detection-only). Filesystem workspace boundary. Opt-in Docker Sandbox. Destructive ops require confirmation. No sandboxing of agent runtime itself.
Data model: SQLite (WAL mode) at ~/.thoth/memory.db — shared between knowledge graph and legacy memory. Knowledge graph: SQLite (durable) + NetworkX MultiDiGraph (in-memory, rebuilt on startup) + FAISS vector index (semantic recall). 11 entity types, 67+ typed relations with 30+ LLM-produced aliases. Dream Cycle refinement pipeline. Config: JSON files. Keys in OS credential store.
Self-modification: Agent CAN create/update/delete skills via dedicated tools. Skill patching requires user confirmation + auto backup. Maximum 1 patch proposal per conversation. No tool to modify system prompts directly.
Verification: None formal. Update signature verification.
Key gap vs Passepartout: No deterministic gate stack — shell safety is pattern list, not typed gates. No proof system. No output guardrails. No neurosymbolic architecture. No Org-mode. No Merkle-tree memory. Knowledge graph is LLM-driven entity extraction — no structural integrity guarantees. Thoth's differentiation is the knowledge graph + Developer/Designer studios + embedded LangGraph framework, but still architecturally conventional.
See the full [[id:3aa22300-2f25-57b0-8787-9f199cc978b1][competitive analysis]] for the landscape view and comparison.

5
ideas/comparison-with-symbolics.org → projects/passepartout/strategy/competitors/comparison-with-symbolics.org
View File

@@ -1,10 +1,11 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 00ab3a4d-e3de-5605-a67d-12935bb36ab5
:END:
#+title: Comparison with Symbolics Genera
#+filetags: :passepartout:history:symbolics:comparison:
| | Symbolics Genera (1980s) | Passepartout (2020s) |
| | Symbolics Genera (1980s) | [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] (2020s) |
|---|---|---|
| Lines | ~1,000,000 | ~21,000 (self-driving target) |
| Developer-years | ~10 years, large team | ~1 year, 1-3 devs |
@@ -13,4 +14,4 @@
| Market | $50K-$100K/seat | $5K-$50K/appliance |
| Scope | Full OS + environment | Cognitive agent + hardware acceleration |
The Symbolics comparison is instructive: they built a full Lisp OS from scratch. Passepartout runs on Linux, providing the OS layer for free. The hardware integration is a PCIe card, not a replacement of the entire host. The scope is dramatically smaller — ~2% of the code for a fraction of the functionality that matters most. This illustrates the fundamental principles of [[file:lisp-economics.org][Lisp economics]] — the cost of building a Lisp-based system has dropped by orders of magnitude since the 1980s. The [[file:self-driving-lisp-machine.org][Self-driving Lisp Machine]] is the modern analogue: a hardware accelerator rather than a complete computer.
The Symbolics comparison is instructive: they built a full Lisp OS from scratch. Passepartout runs on Linux, providing the OS layer for free. The hardware integration is a PCIe card, not a replacement of the entire host. The scope is dramatically smaller — ~2% of the code for a fraction of the functionality that matters most. This illustrates the fundamental principles of [[id:9af13fff-9725-542b-93b1-a555bc74ad72][Lisp economics]] — the cost of building a Lisp-based system has dropped by [[id:2cdca4b0-6b41-44b4-acb0-af21d0e27b00][orders of magnitude]] since the 1980s. The [[id:13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70][Self-driving Lisp Machine]] is the modern analogue: a hardware accelerator rather than a complete computer.

128
projects/passepartout/strategy/competitors/competitive-analysis.org Normal file
View File

@@ -0,0 +1,128 @@
:PROPERTIES:
:ID: 3aa22300-2f25-57b0-8787-9f199cc978b1
:CREATED: [2026-05-22 Thu]
:END:
#+title: Competitive Analysis — AI Agent Landscape
#+filetags: :passepartout:strategy:competitive:
* Overview
Analyzed 9 competitor codebases alongside Passepartout. The competitive landscape
divides into three categories:
1. Coding agents — Aider, OpenCode, Codex CLI, Claude Code, Gemini CLI
2. Personal AI assistants — [[id:c652688a-1ea0-487c-9222-00e954efe8a1][Hermes Agent]], OpenClaw, [[id:416bab7c-4300-4d50-838a-5c7a8ad45d96][Thoth]]
3. CI/check-based systems — Continue
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 [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Passepartout architecture]] — are absent from
every competitor.
* Category 1: Coding Agents
- [[id:c3aab2e8-7e43-4abc-93f0-741675cfd78c][Aider]] — Python, ~40K lines, MIT. Oldest open-source coding agent. Chat-based Coder class with 5 edit formats. Purely prompt-based safety.
- [[id:7a060b36-36db-4eb7-b8cc-844bd6ac9d36][OpenCode]] — TypeScript/Bun, 163K★. Dominant open-source coding agent. Dual LLM runtime, ACP inter-agent protocol, SQLite state.
- [[id:e929ff32-28d8-4a29-bf74-d55babc040d1][Codex CLI]] — Rust, ~950K lines, OpenAI. Strongest sandboxing (Seatbelt/nsjail). Execution policy engine. No knowledge graph.
- [[id:512dd121-2292-4f3d-ac53-31bf3d12a60f][Claude Code]] — TypeScript/Bun, ~512K lines leaked. Most mature safety system (2,592 lines bash security). 7 permission modes. Proprietary.
- [[id:8d73ccb9-34e4-4899-b0c3-605998e9bebc][Gemini CLI]] — TypeScript, ~525K lines, Apache 2.0. CONSECA AI-driven policy generation. 6 sandbox methods. Google-locked.
* Category 2: Personal AI Assistants
- [[id:c652688a-1ea0-487c-9222-00e954efe8a1][Hermes Agent]] — Python, ~17K core, MIT. Running this conversation. 109+ providers, 15+ messaging platforms, MCP client. Heuristic safety layers.
- [[id:85ca69dd-d085-4a55-ad11-021910b1f82e][OpenClaw]] — TypeScript/Node.js, ~3.5M lines. Largest codebase. 25+ messaging channels, 135 bundled plugins. Tiered sandboxing.
- [[id:416bab7c-4300-4d50-838a-5c7a8ad45d96][Thoth]] — Python, ~151K lines, Apache 2.0. Personal knowledge graph (11 entity types, 67 relations, NetworkX+FAISS). LangGraph ReAct agent. Developer Studio.
* Category 3: CI/Check Systems
- [[id:22d0a159-68a2-4587-9375-5046beddc20c][Continue]] — TypeScript, ~328K lines, Apache 2.0. Source-controlled AI checks for CI/CD. Markdown-as-gate-policy. No persistent agent.
* The Passepartout Advantage
| Dimension | Passepartout | Best Competitor | Gap |
|-----------|--------------|-----------------|-----|
| Safety model | Type-level gates + 11-vector deterministic stack | Claude Code (7 permission modes + 23 bash checks) | Structural vs heuristic. Passepartout's type-level gates prevent self-modification at the category level; competitors block patterns. |
| Knowledge model | Org-mode (tree, properties, TODOs, timestamps, cross-refs, IDs, tags) | Claude Code (flat markdown memdir) | Org-mode's semantic richness is ~15 primitives markdown doesn't have. |
| Memory integrity | Merkle tree + SHA-256 + rollback | Hermes (file-based); Claude Code (flat files + git) | Content-addressed, tamper-evident memory no competitor has. |
| Self-verification | ACL2 → CIC prover (planned) | None | No competitor does provable correctness. |
| Cognitive architecture | 10-80-10 symbolic-first (planned) | 100% LLM (every competitor) | Post-flip, Passepartout uses ~10% of the tokens competitors use. |
| Data format | Org-mode (human-editable, machine-parseable, single file) | JSONL/Markdown/YAML/DB (competitors use 2-5 formats) | Unified format reduces translation layers to zero. |
| Self-modification | Type-level gates + hot-reload | Claude Code (skills), Hermes (skills) | Passepartout's guard against self-modification is structural (type level), not heuristic (pattern list). |
| Architecture | Passepartout ([[id:c3b3dc41-945f-54e9-84eb-ca014114f1be][environment subsystem]] + [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][social protocol]]) | None | No competitor is building a full computing stack + social network. |
| Provider independence | Any OpenAI-compatible API | Hermes (109+), Gemini CLI (1 primary) | Comparable to Hermes, better than most. |
* Where Competitors Lead
| Dimension | Leader | Passepartout Status |
|-----------|--------|---------------------|
| Safety implementation maturity | Claude Code (2,592 lines bash security) | Gate stack exists but bash validation is minimal in comparison |
| Provider breadth | Hermes (109+), OpenClaw (50+) | 8 providers — adequate but not competitive |
| Channel/platform support | OpenClaw (25+ channels) | TUI only — no multi-channel |
| Plugin ecosystem | OpenClaw (ClawHub, npm registry) | No plugin marketplace |
| Subagent delegation | Claude Code (fork with context inheritance) | Planned via Screamer planner |
| Codebase size / features shipped | All competitors have working products | In development |
| MCP integration | Hermes, Codex (native), Continue | Planned |
| Sandboxing | Codex CLI (Seatbelt+nsjail), Gemini CLI (6 methods) | None |
| Business model | Hermes (MIT+services), Codex (tokens) | AGPL + appliances + SaaS |
| Cross-platform | Claude Code (macOS/*nix), Codex (macOS) | Linux only |
* Strategic Positioning
Passepartout is not competing in the existing AI agent market. It is building a
new category: provable personal infrastructure.
Competitors optimize for:
- Token efficiency (Aider's edit formats, OpenCode's LSP integration)
- Model flexibility (Hermes' 109 providers)
- Platform reach (OpenClaw's 25 channels)
- UI polish (Gemini CLI's Ink/React, Claude Code's permission dialogs)
- Sandbox security (Codex's Seatbelt, Gemini's gVisor)
Passepartout optimizes for:
- Provable correctness (ACL2 → CIC)
- Data integrity (Merkle tree)
- Cognitive architecture (10-80-10 symbolic-first)
- Safety by construction (type-level gates)
- Unified data model (Org-mode as everything)
- Network effects (social protocol)
- Full-stack ownership (environment subsystem)
These are not axes any competitor cares about. The risk is not that a competitor
builds a better Passepartout — it's that the market never develops a preference
for provable agents. If token-burning LLM agents remain the default and users
don't demand verification, the entire category Passepartout addresses may not
exist yet.
* Immediate Implications for Development
1. Claude Code's safety system is the benchmark to exceed. The type-level gate
architecture is theoretically superior to Claude Code's heuristic patterns,
but the implementation needs to prove it catches things Claude Code misses.
2. No competitor has anything resembling a neurosymbolic architecture. The 10-80-10
plan has zero competition — but that also means zero market validation.
3. The Org-mode bet is invisible to competitors. They don't see the advantage
because they've never tried to build a knowledge graph from flat markdown files.
This is Passepartout's widest moat — it depends on a skill (Org-mode literate
programming) that no competitor's team has.
4. Hermes is the closest full-stack competitor (tools, skills, cron, subagents,
multi-platform), but architecturally conventional.
5. The coding agents (Aider, OpenCode, Codex) are not competitors — they are
single-purpose tools Passepartout could eventually replace entirely when the
planner matures.
* File references
Repository dumps and analysis artifacts at /tmp/:
- /tmp/aider/ — Aider source (Python)
- /tmp/opencode/ — OpenCode archived source
- /tmp/codex/ — OpenAI Codex CLI (Rust)
- /tmp/claude-code-leaked-source/ — Claude Code leaked (TypeScript/Bun)
- /tmp/gemini-cli/ — Google Gemini CLI (TypeScript)
- /tmp/openclaw/ — OpenClaw source (TypeScript)
- /tmp/thoth/ — Thoth source (Python)
- /tmp/continue/ — Continue source (TypeScript)
- /usr/local/lib/hermes-agent/ — Hermes Agent (Python)

221
projects/passepartout/strategy/competitors/social-protocol-competitive-landscape.org Normal file
View File

@@ -0,0 +1,221 @@
:PROPERTIES:
:ID: 1bc22b89-d3eb-4f6d-bcfc-2b0c19c8ed8f
:ID: competitive-landscape-agora
:CREATED: [2026-05-23 Sat]
:END:
#+title: Passepartout Social Protocol Competitive Landscape
#+filetags: :passepartout:social-protocol:competitive:strategy:landscape:
The social protocol is a decentralized social operating system that replaces the entire centralized internet platform stack: every function that currently runs on Facebook, Twitter, Instagram, YouTube, TikTok, Reddit, Medium, Substack, OnlyFans, Pornhub, WhatsApp, Signal, Telegram, Discord, LinkedIn, eBay, Etsy, GitHub, DocuSign, Stripe, and Google/Apple ID — all through one unified identity, one data model (the Note), one communication protocol (DIDComm), one payment rail (Lightning), and one contract layer (SCAL).
There is no single competitor. The competition is the /category/ of centralized internet platforms and the psychological status quo of managing 15+ separate accounts.
This page maps every platform the protocol replaces, organized by domain, with the specific protocol capability that makes the replacement possible.
* Social Graph & Publishing
** Twitter/X
- *User need:* Broadcast short-form content, follow interesting people, real-time news
- *Social Protocol replacement:* Feeds and streams via the Note primitive (`is_feed: true`), with Lens architecture for customizable curation. Follows are cryptographic subscriptions, not API-gated relationships.
- *Social Protocol advantage:* No algorithmic manipulation, no ads, no shadowbanning. Users choose their Feed Generators via the Algorithm Marketplace. Portable social graph — follows are signed Notes, not a database row.
- *Migration:* Twitter archive import for followed accounts.
** Facebook / Meta
- *User need:* Social graph, family/friend connections, event management, groups
- *Social Protocol replacement:* Collective Personas for groups, DID-based social graph (not platform-controlled), Persona isolation for work/personal/family
- *Social Protocol advantage:* No central feed algorithm that optimizes for engagement over well-being. Portable identity — your social graph leaves the platform when you do. No data mining.
- *Timing:* Year 3+ after network effects. Facebook's moat is the largest social graph; the protocol's Persona system makes it portable by design.
** Instagram
- *User need:* Visual content sharing, photo feeds, stories
- *Social Protocol replacement:* Visual Notes with `content_type: image/*`. Lens architecture renders them through an "Instagram-style" grid or a "Pinterest-style" discovery view depending on user-selected Lens.
- *Social Protocol advantage:* User-chosen discovery algorithm. No engagement-maximized feed. Content is not manipulated for ad placement.
** LinkedIn
- *User need:* Professional identity, job market, professional networking
- *Social Protocol replacement:* Professional Persona (unlinkable from personal), Aletheia Portfolio (static site published natively to the network), Contract Notes for hiring/service agreements
- *Social Protocol advantage:* Portable professional reputation — not locked to a platform. Verified work history via signed Notes. Direct hiring without platform intermediation fees.
** Reddit / Forums (phpBB, vBulletin)
- *User need:* Community discussion, Q&A, interest-based groups
- *Social Protocol replacement:* Social Spaces with Collective Personas, pluggable feed generation, competitive labeling for moderation
- *Social Protocol advantage:* Sovereign moderation (users choose their Labelers), portable identity across communities, no censorship risk. Communities can fork if the Collective governance fails.
- *Migration:* Import subscribed subreddits.
** Medium / Substack
- *User need:* Long-form publishing, subscription-based content, creator monetization
- *Social Protocol replacement:* Feed Notes (`is_feed: true`) with paywalled content via LSAT protocol (Lightning Service Authentication Tokens). Subscriptions are streaming Lightning payments.
- *Social Protocol advantage:* Near-zero platform fees (relay costs only). Content ownership — readers subscribe to the creator's DID, not to a platform. No censorship risk.
- *Strategic target:* Phase 1 platform replacement.
* Video & Audio
** YouTube
- *User need:* Video hosting, discovery, comments, monetization
- *Social Protocol replacement:* Video Notes (`content_type: video/*`) viewed through a "YouTube Lens" (displaying comments via `reply_to` and related videos). The exact same Note can be viewed through an "Educational Lens" or "Podcast Lens."
- *Social Protocol advantage:* No algorithm that optimizes for watch time over well-being. Lens architecture lets users choose discovery logic. Content monetized via LSAT + Seeder Rewards — creators earn directly, and bandwidth providers (seeders) earn micro-rewards.
** TikTok
- *User need:* Short-form vertical video, discovery algorithm
- *Social Protocol replacement:* Short-duration video Notes trigger a "TikTok-style" vertical scroll and auto-play in the UI when `content_type: "video/mp4"` and duration is short.
- *Social Protocol advantage:* The "For You" algorithm is a user-chosen Lens, not a platform-controlled black box. No engagement-extremification.
** Podcasts / Audio
- *User need:* Audio content, background play
- *Social Protocol replacement:* Audio Notes (`content_type: audio/mpeg`) viewed through a "Podcast Lens" with 1.5x speed and background play. Same Note can be listened to or watched depending on Lens.
* Messaging & Communication
** WhatsApp / Signal / Telegram
- *User need:* Private messaging, group chats, voice/video calls, encryption
- *Social Protocol replacement:* DIDComm v2 for transport, Double Ratchet Algorithm (Signal Protocol) for Perfect Forward Secrecy, WebRTC for voice/video with decentralized signaling via DIDComm. PDS acts as encrypted mailbox proxy.
- *Social Protocol advantage:* Multi-persona isolation — Work DID and Personal DID have separate message queues that never mix. Onion routing for metadata privacy. Off-the-Record mode for ephemeral interactions. No central server controlling the directory.
** Discord / Slack
- *User need:* Community chat, voice channels, collaboration
- *Social Protocol replacement:* Social Spaces with Collective Personas. DIDComm-based group messaging. Governance modules (GEM) for roles, permissions, and moderation.
- *Social Protocol advantage:* Server ownership is cryptographic, not corporate. Communities can fork. No per-seat pricing. Portable membership history.
** Email
- *User need:* Asynchronous messaging, identity, document delivery
- *Social Protocol replacement:* Directed Notes (Copy-on-Send model). PDS as encrypted mailbox. The Note is a universal message format — no separate email protocol needed.
- *Social Protocol advantage:* End-to-end encryption by default. Cryptographic sender verification (no phishing, no spoofing). No spam (relays only route to subscribed destinations). Attachments are CIDs, not MIME blobs.
** Zoom / Google Meet
- *User need:* Video conferencing, screen sharing
- *Social Protocol replacement:* WebRTC over DIDComm signaling. P2P tunnel — no central server sees call data.
- *Social Protocol advantage:* No Zoom-bombing (call is authenticated by DID). No platform listening in. No account required beyond your DID.
* E-Commerce & Marketplaces
** eBay / Etsy
- *User need:* Buy and sell goods, auction, fixed-price listings, dispute resolution
- *Social Protocol replacement:* Contract Notes as product listings (Offer → Take model). HODL invoice escrow for payments. SCAL (Sovereign Contract & Arbitration Layer) for dispute resolution.
- *Social Protocol advantage:* Fees below 5% (vs. 10-15%). Transparent reputation system based on DID history. No account bans. Multi-level arbitration (Local Elders → Guilds → Global Juries).
** OnlyFans / Patreon / Fansly
- *User need:* Subscription content, adult content, creator-direct monetization
- *Social Protocol replacement:* Paywalled Notes via LSAT protocol. Streaming Lightning subscriptions. Encrypted content with Blind CDN seeding.
- *Social Protocol advantage:* Censorship-resistant (no payment processor can cut you off). Near-zero platform fees. Pseudonymous by default. Adult content doesn't face the banking discrimination that existing platforms do.
- *Strategic target:* Phase 1 platform replacement (underserved, clear pain point).
** Pornhub / Adult content
- *User need:* Adult content hosting, discovery, monetization
- *Social Protocol replacement:* Same Note primitive with `content_type: video/*`. LSAT for paywalled access. Blind CDN for distribution.
- *Social Protocol advantage:* No centralized moderation that can delist creators. Lightning-native payments bypass banking discrimination. Privacy (identity not tied to consumption).
- *Strategic target:* Phase 1 platform replacement.
* Work & Collaboration
** GitHub / GitLab
- *User need:* Version control, code hosting, issues, pull requests, CI
- *Social Protocol replacement:* Code is stored as Merkle DAGs of commit Notes. Issues and PRs are Contract Notes. Collective Personas own repositories.
- *Social Protocol advantage:* Truly decentralized version control — no central repository host. Signed commits with DID. Smart contracts for bounty management (Lightning bounties).
** Google Docs / Office 365
- *User need:* Collaborative document editing, spreadsheets, presentations
- *Social Protocol replacement:* Static pages (`is_feed: false`) with versioned CID history. Collaborative editing via Contract Notes defining access control.
- *Social Protocol advantage:* Document history is immutable and verifiable. No platform lock-in.
** Project Management (Jira, Trello, Asana)
- *User need:* Task tracking, project management, team coordination
- *Social Protocol replacement:* Tasks as Contract Notes in negotiation state. Status changes are signed state transitions.
- *Social Protocol advantage:* Portable project history. Tasks are data you own.
** Upwork / Fiverr / Freelancer
- *User need:* Find freelancers, manage contracts, escrow payments
- *Social Protocol replacement:* SCAL contracts for service agreements. HODL invoice escrow. Multi-level arbitration. Reputation tied to DID history.
- *Social Protocol advantage:* Lower fees, portable reputation, no platform lock-in.
* Identity & Infrastructure
** Google / Apple ID
- *User need:* Single sign-on across the internet
- *Social Protocol replacement:* DID-based authentication via Personas. No central identity provider. User controls which Persona is used for which service.
- *Social Protocol advantage:* No surveillance (Google sees every SSO login). Granular persona isolation. No single point of failure.
** ENS (Ethereum Name Service)
- *User need:* Human-readable decentralized names
- *Social Protocol replacement:* Social protocol naming registry with similar auction model. But integrated with PDS, messaging, contracts, and payments — a name in the protocol is a full identity, not just a pointer to a wallet.
- *Social Protocol advantage:* Names come with native capabilities (PDS, messaging, contracts). ENS is names-only.
* The [[id:3aa22300-2f25-57b0-8787-9f199cc978b1][Competitive Analysis]]: What This Changes
The social protocol is not competing with any single product. It is competing with the /aggregate/ of 20+ products — and the friction of managing 20+ separate accounts, logins, reputations, and data silos.
** The Real Competitor Is the Status Quo
The centralized internet works well enough for most people. The friction is spread across 20+ platforms — no single platform is bad enough to leave. The social protocol's value proposition is not "Twitter but better" but "one account replaces every platform you use."
This is a harder sell because:
1. The status quo is familiar. Switching all 20+ platforms at once is cognitively overwhelming.
2. Network effects at each platform are entrenched. No single platform can be replaced without bringing the users.
3. The value of unification compounds with adoption — but requires critical mass to be visible.
** The Entry Vector Must Be a Niche, Not a Mass Market
The strategic documents recognize this explicitly. Phase 1 targets underserved communities with clear pain points:
- OnlyFans creators facing payment discrimination and censorship
- Reddit communities tired of centralized moderation
- Developers frustrated with platform lock-in
- Adult content platforms facing banking discrimination
- NGOs and guilds needing sovereign identity
Each of these communities has a /specific/ pain point that the protocol solves directly. The win condition is: a user joins for one reason (e.g., censorship-resistant adult content monetization) and discovers the other 19 capabilities as a free bonus.
** The Structural Advantage Is Unassailable
No centralized competitor can match the protocol's bundle:
- Meta cannot offer portable identity (it destroys their business model)
- Google cannot offer private messaging (it destroys their data model)
- Stripe cannot offer contracts and social (outside their competence)
- DocuSign cannot offer payments and publishing (outside their competence)
- The entire category of centralized platforms cannot offer user-owned data
The only way to compete with the protocol is to build a similar decentralized platform — and that requires matching all four layers (identity, publishing, payments, contracts) simultaneously. No decentralized project has done this. The closest (Farcaster) has identity and social but no payments or contracts. Bluesky has identity and social but no payments or contracts. Ethereum + ENS has identity, payments, and contracts but no social layer.
** The Risk Is Not Competition but Indifference
The protocol's biggest risk is not that a competitor builds a better product, but that the status quo friction is tolerable enough that users never switch. The centralized internet is bad — but it is familiar. The protocol is better — but unfamiliar.
The counterargument: this is true for every platform shift. Email was a worse experience than postal mail in 1992. The web was a worse experience than AOL in 1994. Instagram was a worse experience than Flickr in 2010. Each won because a /specific/ use case was dramatically better, and the rest of the ecosystem followed. The protocol must find its "camera with filters" moment — the one use case that is so clearly superior that users adopt it despite the rest of the ecosystem being immature.
* Comparison Summary
|| Social Protocol replaces | Incumbent | Social Protocol advantage | Risk to Social Protocol |
|----------------+-----------+----------------+---------------|
| Social graph | Facebook | Portable identity, no data mining | Facebook's 3B user moat |
| Microblogging | Twitter/X | Algorithm choice, no censorship | Network effects |
| Visual content | Instagram | No engagement-extremified algorithm | UX polish gap |
| Professional | LinkedIn | Portable rep, no platform fees | Professional network effects |
| Video | YouTube | Lens choice, Seeder Rewards | Content moderation surface |
| Short video | TikTok | Users choose the algorithm | Discovery algorithm sophistication |
| Forums | Reddit | Sovereign moderation, portable identity | Community migration inertia |
| Publishing | Medium/Substack | Near-zero fees, content ownership | Creator distribution |
| Messaging | WhatsApp/Signal | Multi-persona isolation, onion routing | Friend network effects |
| Community | Discord | Cryptographic ownership, forkable | Voice/UX maturity |
| E-commerce | eBay/Etsy | <5% fees, transparent reputation | Trust in new platform |
| Subscription | OnlyFans/Patreon | No payment discrimination | Creator acquisition cost |
| Video hosting | Pornhub | No censorship, Lightning payouts | Reputation risk |
| Code hosting | GitHub | Truly decentralized, DID-signed commits | Developer habit |
| Identity | Google/Apple ID | No surveillance, persona isolation | Convenience of SSO |
| Naming | ENS | Name + PDS + messaging + contracts | ENS's 2M domain moat |
| Collaboration | Google Docs | Verifiable history, no platform lock-in | Real-time collaboration UX |
| Freelance | Upwork/Fiverr | Lower fees, portable reputation | Liquidity of gig listings |
| Meetings | Zoom | P2P, no central server | Call quality/reliability |
* Conclusion
The protocol does not compete with any single platform. It offers an alternative to the /entire paradigm/ of centralized internet services. The competitive analysis is not about which platform to beat — it is about which /use case/ to lead with so that users adopt the unified platform despite the rest of the ecosystem being immature.
The OnlyFans/Patreon entry vector is the strongest Phase 1 play: a community with clear pain (payment discrimination, censorship), high willingness to pay, and low switching costs (creators want their audience independent of the platform). From there, publishing, messaging, and identity flow naturally.
* References
- [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Social Protocol overview]] (brain docs)
- [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][Social Protocol contract platform]]
- [[id:57f9538a-6270-4302-8d07-d742168419eb][Social-first growth scenario]]
- Social Protocol Overview (spec repo)
- Social Space specification
- Exchange and Contracts specification
- User journey and platform replacement strategy

7
projects/passepartout/strategy/compliance/_index.org Normal file
View File

@@ -0,0 +1,7 @@
#+title: Compliance
#+filetags: :compliance:index:
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 1c4c91ec-c465-44ab-bd91-4c3b45909ddb
:END:

7
ideas/compliance/appi.org → projects/passepartout/strategy/compliance/appi.org
View File

@@ -1,8 +1,9 @@
:PROPERTIES:
:ID: b852ec69-0fc2-435c-ae1e-6b83e49b3ca3
:ID: auto-appi
:CREATED: [2026-05-23 Sat]
:END:
#+title:
#+title: APPI (Act on the Protection of Personal Information — Japan)
#+filetags: :passepartout:compliance:framework:appi:
@@ -23,4 +24,6 @@ Japanese residents.
Why it matters: APPI's cross-border transfer restrictions require fine-grained
control over which data leaves Japan. The gate stack can encode "this data has
APPI cross-border consent flag = false → block egress." First-mover advantage
is moderate — few non-Japanese vendors target APPI specifically, and the 2022
is moderate — few non-Japanese vendors target APPI specifically, and the 2022 report. First-mover advantage is moderate — few non-Japanese vendors target APPI specifically, and the 2022 amendments created a market for dedicated APPI tooling.
Part of the [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][compliance framework index]].

3
ideas/compliance/apra-cps-234.org → projects/passepartout/strategy/compliance/apra-cps-234.org
View File

@@ -1,4 +1,5 @@
:PROPERTIES:
:ID: 904f5f12-ec9a-4cbf-854a-0b9b1e11a521
:ID: auto-apra-cps-234
:CREATED: [2026-05-23 Sat]
:END:
@@ -21,7 +22,7 @@ license cancellation for non-compliance. Personal liability for board and
senior management.
Why it matters: CPS 234's control testing requirement creates demand for
continuous verification — exactly what the gate stack and evaluation harness
continuous verification — exactly what the gate stack and [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][evaluation harness]]
provide. First-mover advantage: CPS 234 is mature (2019) but enforcement is
escalating. No vendor provides a deterministic control-testing pipeline.

5
ideas/compliance/basel-iii.org → projects/passepartout/strategy/compliance/basel-iii.org
View File

@@ -1,4 +1,5 @@
:PROPERTIES:
:ID: 4eef0993-6671-41cf-ba20-d1443a3ec49d
:ID: auto-basel-iii
:CREATED: [2026-05-23 Sat]
:END:
@@ -24,4 +25,6 @@ verification-friendly. The gate stack can encode credit risk weight mappings
and produce auditable proof that capital calculations follow the correct
methodology. First-mover advantage: Basel compliance is done via spreadsheets
and specialized risk platforms. No platform uses formal verification for
risk-weight mapping correctness. A $100K/yr Basel gate package for a G-SIB
risk-weight mapping correctness. A $100K/yr Basel gate package for a G-SIB is a trivial expense relative to the capital requirement penalty of getting the mapping wrong.
Part of the [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][compliance framework index]].

5
ideas/compliance/ccpa-cpra.org → projects/passepartout/strategy/compliance/ccpa-cpra.org
View File

@@ -1,12 +1,13 @@
:PROPERTIES:
:ID: 87996d87-100c-4bf6-8546-a860b9d7c25b
:ID: auto-ccpa-cpra
:CREATED: [2026-05-23 Sat]
:END:
#+title:
#+title: CCPA/CPRA (California Consumer Privacy Act)
#+filetags: :passepartout:compliance:framework:ccpa:
California's comprehensive privacy law — the closest US analogue to GDPR.
California's comprehensive privacy law — the closest US analogue to [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]].
CPRA (effective 2023) amended and strengthened CCPA. Key rights: right to
know, delete, opt out of sale/sharing, correct inaccurate data, limit use
of sensitive PI. Private right of action for data breaches.

49
projects/passepartout/strategy/compliance/compliance-framework-mapping.org Normal file
View File

@@ -0,0 +1,49 @@
:PROPERTIES:
:ID: 36e5b948-e07b-477f-9036-4dfe88254347
:ID: e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c
:CREATED: [2026-05-23 Sat]
:UPDATED: [2026-05-23 Sat]
:END:
#+title: Compliance Framework Mapping — Global Regulated Industries
#+filetags: :passepartout:triad:compliance:global:index:
This file has been split into atomic framework notes under [[id:1c4c91ec-c465-44ab-bd91-4c3b45909ddb][compliance/]].
See [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][Compliance framework index]] for the hub with per-framework links.
See [[id:558154ea-e63a-4c45-998c-26ce8588585b][First-mover window analysis]] for timing.
See [[id:81a815ee-bf2b-4365-9894-b814e4196850][Revenue table]] for pricing and TAM.
Each framework is its own file in [[id:1c4c91ec-c465-44ab-bd91-4c3b45909ddb][compliance/]]:
- [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]]
- [[id:ed65031c-cbd2-4ad2-bd53-a67791e183cd][SOC 2]]
- [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]]
- [[id:e6993701-3c67-49bf-82f3-06907572cbf3][FedRAMP]]
- [[id:c9830152-0160-4bdc-ab03-6f308ad43536][SOX]]
- [[id:4a2bc62b-3f21-4212-9cd9-f9add8fc0be1][GLBA]]
- [[id:581666ba-f72c-406b-8556-93876d2b30bf][NY DFS 500]]
- [[id:87996d87-100c-4bf6-8546-a860b9d7c25b][CCPA/CPRA]]
- [[id:f6a0c00e-e922-44af-99ce-6412c4b73745][Quebec Law 25]]
- [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]]
- [[id:748db16a-1382-4e5e-8812-a5d57a8de131][NIS2]]
- [[id:06fcdb02-2643-4f9d-ab41-e711a99cc390][EU AI Act]]
- [[id:717ef2df-2a80-4362-b23a-5e7e12554251][DORA]]
- [[id:b8cf51e8-5f39-49ad-9547-a792a2e446aa][eIDAS 2.0]]
- [[id:ce81fefc-b7a8-4be5-912f-55fd30970b6e][CRA]]
- [[id:b852ec69-0fc2-435c-ae1e-6b83e49b3ca3][APPI]]
- [[id:085b76cc-4a65-4660-9c70-85aee10ca99e][ISMAP]]
- [[id:e777064d-9950-42d5-980d-8c78cda91500][PIPA]]
- [[id:834689e9-be0a-4822-9085-9b6b22294fd2][Privacy Act Australia]]
- [[id:904f5f12-ec9a-4cbf-854a-0b9b1e11a521][APRA CPS 234]]
- [[id:7f46764b-47b8-4892-a526-2c1b9ee6e6df][IRAP]]
- [[id:fed19a24-ad81-4837-a12b-dafbd3ec110a][DPDP Act]]
- [[id:c871a9f4-dd53-4e93-aa50-6acf0c606a9b][LGPD Brazil]]
- [[id:bafdaa23-de0b-444c-9151-c87ac65add32][LFPDPPP Mexico]]
- [[id:e2ab887d-9f28-4da6-8388-e6c035e9d9c5][ISO 27001]]
- [[id:748b0cc7-7f42-49fb-8ee3-1ae49048a178][ISO 27701]]
- [[id:4eef0993-6671-41cf-ba20-d1443a3ec49d][Basel III]]
- [[id:03ebdb80-a9af-4e76-a443-8556424996ed][FATF AML/CFT]]
- [[id:fc736aec-ef53-4759-9787-62bc8deea2e7][IFRS]]
- [[id:022109ad-f031-44c4-8ea0-0b3c9402ca90][OECD Privacy/AI]]
- [[id:177aad72-5626-444d-a2e4-af8e1263b125][World Bank ESF]]
- [[id:68c55deb-72bf-4b15-ac28-bcc792057543][IFC PS]]
- [[id:6a5884c8-e9b5-477e-bbf6-aa9ffd967739][UN/CEFACT]]

82
projects/passepartout/strategy/compliance/compliance-index.org Normal file
View File

@@ -0,0 +1,82 @@
:PROPERTIES:
:ID: e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c
:CREATED: [2026-05-23 Sat]
:UPDATED: [2026-05-23 Sat]
:END:
#+title: Compliance Framework Index — Global Regulated Industries
#+filetags: :passepartout:triad:compliance:global:index:hub:
The [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] and domain gate package [[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][revenue streams]] depend on
selling into regulated industries. These industries buy compliance, not software.
Each framework below maps to a gate package Passepartout can sell — ACL2-verified
gate rules that produce deterministic audit trails.
See [[id:558154ea-e63a-4c45-998c-26ce8588585b][First-mover window analysis]] and [[id:81a815ee-bf2b-4365-9894-b814e4196850][Revenue table]] for the consolidated view.
* US Frameworks
- [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]] — Health privacy ($50K/yr, 500K+ orgs)
- [[id:ed65031c-cbd2-4ad2-bd53-a67791e183cd][SOC 2]] — Service organization controls ($50K/yr, 100K+ orgs)
- [[id:e6993701-3c67-49bf-82f3-06907572cbf3][FedRAMP]] — Federal cloud authorization ($100K/yr, 1K providers)
- [[id:c9830152-0160-4bdc-ab03-6f308ad43536][SOX]] — Financial controls ($50K/yr, 10K orgs)
- [[id:4a2bc62b-3f21-4212-9cd9-f9add8fc0be1][GLBA]] — Financial privacy ($40K/yr, 20K orgs)
- [[id:581666ba-f72c-406b-8556-93876d2b30bf][NY DFS 500]] — NY financial cybersecurity ($30K/yr, 3K orgs)
- [[id:87996d87-100c-4bf6-8546-a860b9d7c25b][CCPA/CPRA]] — California privacy ($40K/yr, 50K+ orgs)
* Canada
- [[id:f6a0c00e-e922-44af-99ce-6412c4b73745][Quebec Law 25]] — Provincial privacy ($25K/yr, 10K+ orgs)
* UK and EU
- [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] — EU privacy ($50K/yr, 500K+ orgs)
- [[id:9bc29937-d59a-4ae4-9623-3d17a1fe6ebb][UK GDPR]] — UK privacy ($40K/yr, 100K+ orgs)
- [[id:748db16a-1382-4e5e-8812-a5d57a8de131][NIS2]] — Network security ($50K/yr, 160K orgs)
- [[id:06fcdb02-2643-4f9d-ab41-e711a99cc390][EU AI Act]] — AI regulation ($75K/yr, 100K+ orgs)
- [[id:717ef2df-2a80-4362-b23a-5e7e12554251][DORA]] — Financial resilience ($50K/yr, 22K+ orgs)
- [[id:b8cf51e8-5f39-49ad-9547-a792a2e446aa][eIDAS 2.0]] — Digital identity ($30K/yr, 10K+ orgs)
- [[id:ce81fefc-b7a8-4be5-912f-55fd30970b6e][CRA]] — Product cybersecurity ($40K/yr, 50K+ orgs)
* Asia-Pacific
- [[id:b852ec69-0fc2-435c-ae1e-6b83e49b3ca3][APPI]] — Japan privacy ($40K/yr, 100K+ orgs)
- [[id:085b76cc-4a65-4660-9c70-85aee10ca99e][ISMAP]] — Japan cloud authorization ($75K/yr, 500 providers)
- [[id:e777064d-9950-42d5-980d-8c78cda91500][PIPA]] — South Korea privacy ($35K/yr, 50K+ orgs)
- [[id:834689e9-be0a-4822-9085-9b6b22294fd2][Privacy Act]] — Australia privacy ($35K/yr, 50K+ orgs)
- [[id:904f5f12-ec9a-4cbf-854a-0b9b1e11a521][APRA CPS 234]] — Australian financial security ($40K/yr, 500 orgs)
- [[id:7f46764b-47b8-4892-a526-2c1b9ee6e6df][IRAP]] — Australian cloud authorization ($75K/yr, 300 providers)
- [[id:fed19a24-ad81-4837-a12b-dafbd3ec110a][DPDP Act]] — India privacy ($30K/yr, 500K+ orgs)
* Latin America
- [[id:c871a9f4-dd53-4e93-aa50-6acf0c606a9b][LGPD]] — Brazil privacy ($30K/yr, 200K+ orgs)
- [[id:bafdaa23-de0b-444c-9151-c87ac65add32][LFPDPPP]] — Mexico privacy ($25K/yr, 50K+ orgs)
* International
- [[id:e2ab887d-9f28-4da6-8388-e6c035e9d9c5][ISO 27001]] — ISMS ($40K/yr, 60K+ orgs)
- [[id:748b0cc7-7f42-49fb-8ee3-1ae49048a178][ISO 27701]] — Privacy management ($35K/yr, 1K+ orgs)
- [[id:4eef0993-6671-41cf-ba20-d1443a3ec49d][Basel III]] — Banking capital ($100K/yr, 500 G-SIBs)
- [[id:03ebdb80-a9af-4e76-a443-8556424996ed][FATF]] — AML/CFT ($50K/yr, 50K+ orgs)
- [[id:fc736aec-ef53-4759-9787-62bc8deea2e7][IFRS 17]] — Insurance accounting ($75K/yr, 5K+ orgs)
- [[id:022109ad-f031-44c4-8ea0-0b3c9402ca90][OECD Guidelines]] — Privacy/AI principles (indirect)
- [[id:177aad72-5626-444d-a2e4-af8e1263b125][World Bank ESF]] — Development finance ($50K/yr)
- [[id:68c55deb-72bf-4b15-ac28-bcc792057543][IFC PS]] — Project finance ($50K/yr)
- [[id:6a5884c8-e9b5-477e-bbf6-aa9ffd967739][UN/CEFACT]] — Trade facilitation ($30K/yr, 50K+ orgs)
* Strategic View
| Region | Frameworks | Total TAM | First-mover priority |
|--------|-----------|-----------|---------------------|
| US | 7 | ~$33B | FedRAMP (procurement gate), NY DFS 500 (growing) |
| UK/EU | 7 | ~$24B | NIS2 (2025 deadline), AI Act (Aug 2026), DORA (in effect) |
| Asia-Pacific | 7 | ~$9B | DPDP (rules drafting), ISMAP/IRAP (gov cloud gates) |
| Latin America | 2 | ~$7B | LGPD (largest LATAM market) |
| International | 9 | ~$4.5B | ISO 27001 (universal baseline), World Bank/IFC (no market exists) |
The [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] is enforced through
[[id:c34940cc-090e-57c4-8020-e78b1d32b96c][domain gate packages]] running on a
[[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]], creating
[[id:2f783eb4-638e-5afa-9b59-6224d086a712][infrastructure lock-in]] that compounds with every framework
added. See [[id:558154ea-e63a-4c45-998c-26ce8588585b][First-mover window analysis]] and
[[id:81a815ee-bf2b-4365-9894-b814e4196850][Full revenue table]] for the consolidated view.

7
ideas/compliance/cra.org → projects/passepartout/strategy/compliance/cra.org
View File

@@ -1,8 +1,9 @@
:PROPERTIES:
:ID: ce81fefc-b7a8-4be5-912f-55fd30970b6e
:ID: auto-cra
:CREATED: [2026-05-23 Sat]
:END:
#+title: transaction." First-mover advantage: wallets are being built now; the provider
#+title: CRA (EU Cyber Resilience Act)
#+filetags: :passepartout:compliance:framework:cra:
transaction." First-mover advantage: wallets are being built now; the provider
@@ -23,8 +24,8 @@ Penalties: Up to 15M EUR or 2.5% of global turnover for non-compliance with
reporting obligations.
Why it matters: CRA's CE marking requirement creates a certification pipeline
that the verification appliance can supply. If Passepartout's gate stack is
itself CRA-compliant (verified by the evaluation harness), it becomes the
that the [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][verification appliance]] can supply. If [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]]'s gate stack is
itself CRA-compliant (verified by the [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][evaluation harness]]), it becomes the
compliance infrastructure for any product built on it. First-mover advantage:
Class II products require notified body assessment — the bottleneck is notified
body capacity. The gate stack's automated evidence pipeline bypasses the

36
projects/passepartout/strategy/compliance/domain-gate-packages.org Normal file
View File

@@ -0,0 +1,36 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: c34940cc-090e-57c4-8020-e78b1d32b96c
:ID: 45ea493b-94ad-5885-aa65-0c846e5c3c1d
:END:
#+title: Domain Gate Packages — Encoding and Products
#+filetags: :passepartout:revenue:gate-rules:compliance:subscription:encoding:llm:translation:
* Encoding — How Rules Are Translated from Codified Domains
Laws, regulations, standards, procedures, and technical specifications are already written down in structured text. The LLM does not need to *reason* about them — it needs to *translate* them into gate rules and ACL2 theorems.
Example: The US Federal Acquisition Regulation (FAR) is ~2,000 pages. A frontier LLM can ingest the FAR and produce a plist of gate rules:
- (if contract > $250K AND not small-business-set-aside → :deny)
- (if sole-source AND no justification-documented → :deny, produce-justification)
ACL2 verifies the rule set for internal consistency. Screamer checks against existing compliance facts. The human reviews the bootstrap output and approves or corrects individual rules.
The key distinction: the LLM is not *extracting knowledge from prose* — it is *translating a known rule system into a formal representation.* The result is not "the LLM's best guess" but "the rule set as stated in the source document, mechanically transcribed."
For codified domains, the encoding cost drops from weeks to hours. The only bottleneck is human review of the 5% ambiguous rules. This is what makes the sufficiency flip economically viable — once gates are encoded, verification is near-free. The resulting rules are packaged into domain gate packages that can be reused across deployments.
* Products — How Rules Are Packaged and Sold
Pre-verified gate rule packages for specific compliance domains. Translated from published regulations by the LLM, verified by ACL2, reviewed by a human for the 5% ambiguous edge cases.
- HIPAA package: $50K/yr
- SOC2 package: $50K/yr
- GDPR package: $50K/yr
- FedRAMP package: $100K/yr
- Combined enterprise: $250K/yr
Switching costs are high — changing packages means re-verifying the fact store against new rules. The infrastructure lock-in compounds: a hospital at $250K/yr in year one grows to $500K-$1M by year five as more packages are added and the fact store becomes more valuable than the software itself.
20 subscriptions in year one = $1M-$5M. These packages each wrap the social protocol Note primitive into a domain-specific authorization boundary. These packages are verified using the verification appliance and scored by the evaluation harness.

3
ideas/compliance/dora.org → projects/passepartout/strategy/compliance/dora.org
View File

@@ -1,4 +1,5 @@
:PROPERTIES:
:ID: 717ef2df-2a80-4362-b23a-5e7e12554251
:ID: auto-dora
:CREATED: [2026-05-23 Sat]
:END:
@@ -22,7 +23,7 @@ Penalties: Up to 2% of average daily turnover × number of days breached, or
Why it matters: DORA's third-party risk management requirement is a natural gate
stack use case — every ICT provider access must be gated, logged, and auditable.
TLPT (threat-led penetration testing) maps to the evaluation harness. First-mover
TLPT (threat-led penetration testing) maps to the [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][evaluation harness]]. First-mover
advantage is extremely time-sensitive: DORA is already in effect (January 2025).
Financial institutions are scrambling for compliance tooling. A DORA gate package
at $50K/yr with zero incremental cost per additional user is an immediate sale.

4
ideas/compliance/dpdp-act.org → projects/passepartout/strategy/compliance/dpdp-act.org
View File

@@ -1,8 +1,9 @@
:PROPERTIES:
:ID: fed19a24-ad81-4837-a12b-dafbd3ec110a
:ID: auto-dpdp-act
:CREATED: [2026-05-23 Sat]
:END:
#+title:
#+title: DPDP Act (Digital Personal Data Protection Act — India)
#+filetags: :passepartout:compliance:framework:dpdp:
@@ -28,3 +29,4 @@ consent-managed data access model maps directly to DPDP's consent framework.
A DPDP gate package at $30K/yr (discounted for India market) captures a market
of hundreds of thousands of businesses with no incumbent vendor.
Part of the [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][compliance framework index]].

7
ideas/compliance/eidas2.org → projects/passepartout/strategy/compliance/eidas2.org
View File

@@ -1,8 +1,9 @@
:PROPERTIES:
:ID: b8cf51e8-5f39-49ad-9547-a792a2e446aa
:ID: auto-eidas2
:CREATED: [2026-05-23 Sat]
:END:
#+title:
#+title: eIDAS 2.0 (European Digital Identity Framework)
#+filetags: :passepartout:compliance:framework:eidas2:
@@ -23,4 +24,6 @@ access to the EU digital identity market.
Why it matters: eIDAS 2.0 creates a verified digital identity layer across the
EU. The gate stack can integrate with eIDAS wallets as the identity provider
for gate rules — "only X, authenticated via eIDAS wallet, may approve this
transaction." First-mover advantage: wallets are being built now; the provider
transaction." First-mover advantage: wallets are being built now; the provider — the one that First-mover advantage: wallets are being built now; the provider that integrates with the gate stack first becomes the compliance standard for eIDAS-authenticated transactions.
Part of the [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][compliance framework index]].

Some files were not shown because too many files have changed in this diff Show More