amr/memex
1
0
Fork 0
Code Issues 12 Pull Requests Actions Packages Projects 1 Releases Wiki Activity

refactor: moved org-agent to its own repository as a submodule

Browse Source
This commit is contained in:
Amr Gharbeia
2026-03-27 15:46:53 -04:00
parent 01f76a4570
commit b7e082c403
176 changed files with 19686 additions and 9665 deletions
Download Patch File Download Diff File Expand all files Collapse all files

554
org-inbox.org
View File

@@ -8513,11 +8513,11 @@ Instead of relying on SKILL.md or OpenCode's AGENTS.md, all capabilities are def
* Progressive Disclosure: To save token context, the agent only loads the #+DESCRIPTION of a skill initially. It must explicitly request the full #+BEGIN_SRC implementation if it decides to use it.
3. LLMs and Coding Agents as "Effectors"
org-agent treats AI models and external SDKs exactly like it treats a Proxmox server—as a downstream tool to be managed.
| External Tool | How org-agent Uses It | Trade-off |
|---|---|---|
| Local Inference (vLLM) | A base skill (llm-local.org) containing an HTTP POST request to your RTX 6000 cluster for fast, cheap, private reasoning. | Requires manual mapping of Lisp s-expressions to the local model's API. |
| OpenCode | A wrapper skill (skill-opencode.org) that triggers the opencode CLI to execute a massive refactoring job, returning the git diff to org-agent. | Abandons OpenCode's native TUI in favor of headless execution. |
| Claude Agent SDK | A wrapper skill that triggers a Python script leveraging Anthropic's SDK to spin up a multi-agent "Team" for deep architectural planning. | Costs external API tokens; requires Python alongside Lisp. |
| External Tool | How org-agent Uses It | Trade-off |
|------------------------+-----------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------|
| Local Inference (vLLM) | A base skill (llm-local.org) containing an HTTP POST request to your RTX 6000 cluster for fast, cheap, private reasoning. | Requires manual mapping of Lisp s-expressions to the local model's API. |
| OpenCode | A wrapper skill (skill-opencode.org) that triggers the opencode CLI to execute a massive refactoring job, returning the git diff to org-agent. | Abandons OpenCode's native TUI in favor of headless execution. |
| Claude Agent SDK | A wrapper skill that triggers a Python script leveraging Anthropic's SDK to spin up a multi-agent "Team" for deep architectural planning. | Costs external API tokens; requires Python alongside Lisp. |
4. Security & Isolation
Because org-agent runs directly on the host machine to manage Proxmox and GitOps, security is handled via strict allow-lists within the Lisp kernel.
* The LLM backend is instructed to output strictly formatted Lisp s-expressions (e.g., (invoke-skill "proxmox" "restart-staging")).
@@ -8534,555 +8534,11 @@ PROPERTIES:
Make money by using the first mover advantage in everything. Be the market maker, the best reputation, the top arbitrator...
*** Technical Specifications: Sovereign Identity & Data Protocol (SIDP)
:PROPERTIES:
:CREATED: [2026-03-21 Sat 03:09]
:END:
Objective: To build a decentralized social infrastructure that decouples identity, data, and finance from platform operators, enabling user-led governance and mutual-aid hosting.
1. Identity Architecture (The Root)
The system shall utilize a Hierarchical Sovereign Identity (HSI) model based on the W3C DID (Decentralized Identifier) standard.
Master Root (Level 0): A BIP-32/44 Seed Phrase or Master Key.
Natural Person: Controlled via Priority Weights (Owner = 100).
Legal Person (LLC/NGO): Controlled via M-of-N Thresholds (Quorum consensus).
Derivation Paths (Personas & Profiles):
Personas (Level 1): Cryptographically separated identities (e.g., m/purpose'/persona_index'/).
Profiles (Level 2): Context-specific metadata (Social, Professional, Dating) tied to a Persona.
Functional Keys (Level 3):
Bitcoin/Lightning: BIP-44/84/1017 paths for on-chain and LN Node IDs.
Encryption: PGP/NACL keys for End-to-End Encryption (E2EE).
Authentication: SSH/WebAuthn keys.
2. Governance & Lifecycle Management
The identity must remain persistent regardless of key rotations, managed via KERI (Key Event Receipt Infrastructure).
Key Event Log (KEL): An append-only, verifiable history of all key rotations and membership changes.
Founder/Parent Logic:
Genesis: Identities can be initialized by "Founders" (Parents for minors, Board for LLCs) using a threshold signature.
Succession: Automated or manual transfer of control (e.g., 2-of-3 Parent/Child moves to 1-of-1 Adult).
Legal Override & Escrow:
Implementation of Time-Locked Recovery.
Veto Window: A mandatory 72-hour delay on recovery events, allowing the primary owner to invalidate unauthorized rotations.
3. Data Layer: Personal Data Servers (PDS)
Data must be portable, content-addressed, and decoupled from the application UI.
PDS Architecture: Multi-tenant-ready Dockerized environments.
Storage: * Metadata/Social Graph: JSON-LD signed events (Nostr/ActivityPub hybrid).
Blobs (Video/Audio): Content-addressable hashes (IPFS/S3) with WebRTC-based P2P mirroring for high-bandwidth delivery.
Mutual-Aid Hosting (Social Cloud):
Encrypted Peer-Backups: Automated, encrypted state snapshots synced between trusted "Friend PDSs."
History Regeneration: Automated reconstruction of the social graph by querying Relays for all events signed by the Master DID.
4. Infrastructure & Scaling
Relays: High-availability indexers that ingest the PDS "Firehose."
Economic Model: Support for NIP-05/Lightning payments for relay access fees to prevent spam/surveillance incentives.
Relay Resilience: Multi-homed posting (Client pushes to N relays simultaneously).
Metadata Protection: PDS-to-Relay transport layer should support VPN/Tor tunneling to obfuscate IP addresses.
5. P2P Replication & Social Seeding
The system must support altruistic data mirroring to ensure high availability and censorship resistance.
Mirroring Policy (Follower-Side):
Apps must include a "Seeding" toggle.
Users can designate a Storage Quota (e.g., "Seed up to 1GB for my Top 5 followed profiles").
Content Addressing (CID): * All data (posts, images, video) must be hashed using IPFS-style CIDs. This ensures that even if a follower provides a replica, the receiver can verify it was signed by the original Master Key and hasn't been tampered with.
Gossip Dissemination: * Implementation of Epidemic Broadcast Trees (EBT) or Nostr-style relay discovery to let followers know when a "Pinned" profile has published new content.
Bandwidth Delegation (WebRTC): * For high-bandwidth "Blobs" (Video), the client should utilize a P2P streaming library (like WebTorrent or HLS over WebRTC). This allows the "Swarm" of active viewers to serve as a distributed Content Delivery Network (CDN).
6. The "Identity-Data" Linkage
Verification: The replica is only valid if the follower can provide the Proof of Provenance (the signature of the Persona that created the data).
Privacy: Followers replicate Public Data by default. Private/Encrypted Data can be replicated as "Encrypted Blobs"—followers host the data but cannot see the contents, providing a "Blind Backup" service for the creator.
7. Content Monetization & LSAT Integration
The system shall implement a Pay-per-Access model using the LSAT (Lightning Service Authentication Token) standard.
Encryption at Rest: * All premium content must be encrypted using AES-256 (or equivalent) before being published to the PDS/Relay.
The encrypted blob is identified by a unique CID (Content Identifier).
The LSAT Workflow:
Request: Client requests a CID.
Challenge: Server issues an LSAT Macaroon + Lightning Invoice.
Payment: Client pays via LN and receives a Preimage.
Redemption: Client submits {Macaroon + Preimage} to the Key-server/PDS.
Key Release: Server returns the symmetric decryption key.
Incentivized Swarms (Seeder Rewards):
Proof of Delivery: Seeders can provide "signed receipts" of bits delivered to a peer.
Attestation: The creator's PDS can include a Split Invoice logic where the viewer's payment is distributed among the top N seeders identified in the metadata.
8. The "Key-Server" Module
The PDS must include a Key-Management Module that handles the automated sale and distribution of decryption keys.
Privacy Note: The Key-server must be separate from the Data-server so that the entity holding the "keys" is not necessarily the same entity hosting the "blobs."
9. Ricardian Contract Schema
The PDS must support a standard ContractEvent type:
Participants: Array of DIDs (Buyer, Seller, Arbitrator).
Legal_Text_CID: IPFS hash of the human-readable terms.
Condition_Logic: Boolean triggers for payment release (e.g., "Require 2-of-3 signatures to settle").
Arbitration_Clause: Defines the Escalation_Path (Circle -> Guild -> Jury).
10. Multi-Sig / HODL Management
Escrow Service: The client app must interface with the PDS to manage Lightning HODL Invoices.
Timeout Logic: Contracts must include a CLTV-expiry (CheckLockTimeVerify). If the arbitrator doesn't rule within 30 days, the funds are automatically returned to the Buyer to prevent "Forever-Locks."
11. Proof-of-Delivery (Oracles)
Physical Goods: Support for "Scanning a QR code" on delivery, which automatically releases the payment.
Digital Goods: Support for Zero-Knowledge Proofs (ZKP) where the payment is released automatically once the file hash is verified as correct.
12. Hierarchical Dispute Resolution (HDR) Protocol
The system shall implement a tiered arbitration framework to settle ContractEvents.
Web of Trust (WoT) Integration:
Arbitrators at Level 1 are selected based on Transitive Trust (e.g., "Find a person trusted by both parties within 3 degrees of separation").
The UI must show an "Elder Badge" for accounts that have successfully resolved >50 disputes with a high "Fairness Score."
Escalation path logic
{
"arbitration_policy": {
"tier_1": { "type": "social_circle", "quorum": 1, "fee": "0" },
"tier_2": { "type": "expert_guild", "quorum": 3, "fee": "5000_sats" },
"tier_3": { "type": "global_jury", "quorum": "sqrt(n)", "fee": "25000_sats" }
}
}
Reputation Slashing (Social Collateral):
Each DID shall have a public "Justice Ledger" attached to its profile.
If a user refuses to follow a final (Tier 3) ruling, the system issues a "Negative Attestation." * This attestation is mirrored across all Relays. Other apps will see this "Red Flag" and automatically block that user from entering into future high-value contracts.
13. Ricardian Evidence Vault
​Evidence Submission: Parties upload encrypted "Evidence Blobs" to their PDS.
​Selective Disclosure: Using Zero-Knowledge Proofs (ZKPs) or Shared Keys, the parties grant the current level of arbitrators temporary read-access to the evidence without making it public.
​Audit Trail: Every ruling, appeal, and evidence hash is stored in the Key Event Log (KEL) for that contract, creating a verifiable record of the "trial."
14. Governance Executable Module (GEM)
The PDS must support a GovernanceEngine that processes ProposalEvents.
Proposal Schema:
Proposer_DID: The identity initiating the change.
Action_Payload: The specific code/parameter change to be executed (e.g., Update_Fee_Schedule).
Voting_Logic: Defined algorithm (Simple Majority, Quadratic, Conviction).
Quorum_Threshold: Minimum DID participation required for validity.
Reputation-Weighted Voting:
Integrates with the HDR (Judicial) layer.
DIDs with higher "Fairness Scores" or longer "Network Tenure" may be granted higher voting weights in specific "Expert" categories (e.g., Technical Upgrades).
15. The Community Treasury (Multi-Sig Vault)
Wallet Integration: Governance logic must be able to trigger Lightning/On-chain multisig transactions.
Automated Payroll: Support for "Streaming Payments" (e.g., X sats per block) that are automatically paused if a "Stop Work" governance vote reaches a threshold.
16. Moderation & "The Algorithm" (Social Governance)
Community Filters: Communities can vote on "Global Blocklists". If 70% of an NGO's members flag a specific DID as a "Spam Bot," that DID is automatically hidden from all members' feeds.
Curated Feeds: A community can vote to "Pin" certain content creators to a shared "Featured" feed, creating a decentralized editorial board.
17. Pluggable Feed Generation (PFG) API
The system must support an Open Feed Protocol where the Client App is decoupled from the Sorting Logic.
Feed Discovery:
Algorithms are identified by their own DID (Decentralized Identifier).
Users "Subscribe" to an algorithm by adding its DID to their PDS metadata.
The getFeedSkeleton Workflow:
Request: Client → AppView (proxied to Feed Generator DID).
Auth: Request is signed by the User's Persona key (to allow for personalized results).
Return: A JSON list of post_CIDs and reason metadata (e.g., "Reason: Your friend liked this").
Display: The Client hydrates the CIDs from the local cache or Relay.
Algorithm Privacy: * Support for Private Feed Generators. An NGO can run a feed that is only accessible to DIDs on their "Member List," preventing outsiders from seeing internal community highlights.
18. Decentralized Moderation (Labelers)
Moderation is treated as "Competitive Labeling" rather than "Censorship."
Labeler DIDs: Independent services that "tag" content (e.g., "Spam," "Graphic," "High-Quality").
Client-Side Filtering: The user's app pulls these 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 (e.g., a "Fact Checker" labeler + a "Church Group" labeler).
19. UX/UI Requirements (The "Abstraction" Layer)
The engineer must ensure that the complexity of DIDs and CIDs is hidden behind a familiar interface.
Key Management: The app must use Biometric Unlock (FaceID/Fingerprint) to sign transactions. The user should never see a raw private key during daily use.
Status Indicators: * "Seeding Now": A subtle icon showing the user is currently providing P2P bandwidth.
"Protected by [NGO Name]": Verification of which PDS/Relay is currently handling their data.
20. The "Action-Trigger" API
The app must handle Asynchronous Events for the Judicial and Governance layers.
Notification scheme
.{
"event_type": "CONTRACT_DISPUTE_INITIATED",
"action_required": "SUBMIT_EVIDENCE",
"deadline": "2026-01-20T12:00:00Z",
"current_tier": 1
}
Auto-Execution: The PDS must be capable of "listening" for finalized Jury results and automatically releasing keys/funds without the user being online.
18. Persona Derivation Path
The software must implement a standard derivation path to ensure interoperability between different wallet apps.
Path: m/purpose' / persona_index' / profile_index / key_type
Hardened Personas: The persona_index MUST be hardened to prevent correlation attacks.
19. Cross-Persona Interaction (The "Bridge")
The system shall allow a user to "Attest" that two personas belong to the same human without revealing the master seed.
Use Case: Your "Pseudonymous Developer" persona can prove it has the "Verified Citizen" badge from your "Legal Persona" via a Zero-Knowledge Proof (ZKP). You prove you are a citizen without revealing which citizen you are.
20. Profile Metadata (JSON-LD)
Profiles are non-cryptographic "wrappers" around the Persona's DID.
{
"context": "https://www.w3.org/ns/did/v1",
"id": "did:key:persona_1_id",
"profiles": [
{
"type": "Professional",
"data": { "title": "Lead Architect", "skills": ["Solidity", "Rust"] }
},
{
"type": "Commerce",
"data": { "currency": "BTC", "shipping_region": "EU" }
}
]
}
21. Secure Communication Module (SCM)
The system shall implement the DIDComm v2 specification for all non-public interactions.
Message Format: JWM (JSON Web Messages) wrapped in a JWE (JSON Web Encryption) envelope.
Encryption Suite: X25519 for key agreement, AES-256-GCM for content encryption.
Asynchronous Forwarding: PDS must support the Forward message type, acting as an encrypted relay for offline delivery.
22. Real-Time Adjudication (VoIP/Video)
Signaling: Handshakes for WebRTC MUST be conducted over an authenticated DIDComm channel.
Relay (TURN): If a direct P2P connection fails (due to strict firewalls), the system shall utilize Community TURN Servers where the traffic is encrypted with the same keys used for the call, ensuring the relay is "blind."
23. Physical-to-Digital Asset Bridging (The "Vault")
NFC/QR Binding: The app must support "Binding" a physical object to a Digital Persona.
Verifiable Credentials (VC): When a user buys a physical asset (like the chair in our journey), the Seller issues a Verifiable Credential to the Buyer's Persona. This VC is the "Digital Deed."
Hardware Security: High-value keys (the Master Seed) should be stored in the device's Secure Enclave or a hardware wallet, never in the app's general memory.
24. Physical Asset Linking (PAL) Protocol
The system must support the mapping of physical objects to DIDs using Tamper-Evident Identifiers.
Hardware Binding: Use of NFC tags or specialized QR codes that, when scanned, provide a Proof of Authenticity signed by the original issuer's DID.
Digital Deeds (VCs): Asset ownership must be stored as a W3C Verifiable Credential within the user's Persona-specific data vault.
25. The Hardware Security Module (HSM)
To protect these assets, the "Master Seed" must be treated with bank-grade security.
Cold Storage Integration: The app must allow "Deep Cold" Personas where the keys never touch an internet-connected device (e.g., using a hardware wallet like Ledger or Keystone).
Multi-Sig Assets: High-value community assets (like a shared warehouse) should require a 3-of-5 signature from different community members to be moved or used as collateral.
26. Final System Map for the Engineer
Component Function Technology
Persona Tree Identity & Privacy BIP-32/44 + DID
PDS Data Sovereignty Docker + IPFS/NoSQL
DIDComm Private Communication JWE + Double Ratchet
HODL Invoices Financial Escrow Lightning Network
Digital Twins Physical Assets Verifiable Credentials
HDR Engine Justice/Courts Ricardian Smart Contracts
GEM Engine Community Rules Quadratic
27. Universal Event Schema (UES)
The PDS must support a polymorphic event structure based on ActivityStreams 2.0.
{
"id": "did:key:abc#event_123",
"actor": "did:key:persona_legal",
"type": "Create",
"object": {
"type": "Video",
"mimeType": "video/mp4",
"url": "cid:bafy...",
"metadata": {
"aspectRatio": "9:16",
"duration": 60,
"price": "500_sats"
}
},
"signature": "..."
}
28. "View" Discovery & Rendering
​MIME-Type Dispatcher: The client app must include a rendering engine that dispatches the UI based on the object.type and metadata.
​Metadata Extensions: Apps can define "Custom Namespaces" for specific services (e.g., an Etsy-like view looks for an ext:ecommerce namespace to handle inventory and shipping).
29. Decoupled Key Provisioning
The app shall support Subkey Injection rather than requiring a Master Seed.
Persona Import: The client must allow importing a standalone xpriv or privKey for a specific derivation index.
Key Scoping: The app must restrict its operations to the scope of the imported key. It shall not attempt to derive "sibling" personas.
Multi-Device Sync: Users can "Invite" a second device (like a tablet) by sharing a Persona-level subkey, ensuring the Master Seed stays in a physical safe.
30. Watch-Only Master (Optional)
Master XPUB: The phone can optionally store the Master Public Key (xpub).
Function: This allows the phone to see all Personas and their balances/activities for monitoring, but it lacks the private keys to authorize any actions. This is the "Auditor View."
31. Mandatory Envelope Encryption
All data marked as "Private" or "Paid" must utilize the Envelope Encryption pattern.
Cipher: AES-256-GCM for Content; X25519 for Key Wrapping.
Metadata: The Wrapped DEK must be stored in a separate KeyHeader object, indexed by the Persona DID.
32. Automated Re-Keying Service
The PDS shall include a background worker that triggers upon a KEY_ROTATION_EVENT.
Action: Iterate through all KeyHeader objects belonging to the revoked DID.
Migration: Re-encrypt headers using the new KeyWrappingKey.
Security: The PDS must never see the raw Master Seed. Re-keying is performed by the User's New Device (which has the old and new Persona keys) or via a Proxy Re-Encryption (PRE) scheme if the user wants the PDS to do it without seeing the content.
33. Shamir’s Secret Sharing (SSS) Integration
​The Vault device software must support the SLIP-0039 standard (the industry standard for Shamir backups).
​Thresholding: Mandatory "M-of-N" setup during master seed creation.
​Share Verification: Guardians must be able to verify their share is still valid without revealing the secret (using a VSS - Verifiable Secret Sharing scheme).
​34. The "Dead Man's Switch" (Protocol Level)
​To prevent assets from being "lost forever" if you disappear, the engineer shall implement a Time-Locked Recovery.
​The Watcher: A smart contract or a "Guardian Persona" monitors your activity.
​The Trigger: If your Master DID has zero "Key Activity" for 12 months, a pre-designated Inheritance Key is authorized to initiate a recovery.
​The Safety: You receive a "Warning Notification" every month leading up to the trigger. A single "Heartbeat" signature from your phone resets the 12-month clock.
35. Public Gateway API
The PDS/Relay shall implement a Public HTTP Resolver.
Pathing: Support for /ipfs/{cid} and /at/{did}/{collection}/{rkey}.
CORS Policy: Must allow cross-origin requests to enable decentralized apps (dApps) to fetch media directly from any PDS.
MIME-Type Sniffing: The gateway must correctly serve headers (e.g., Content-Type: video/mp4) based on the UES (Universal Event Schema) metadata.
36. DNSLink & Well-Known Support
/.well-known/atproto-did: The PDS must serve the user's DID at this endpoint to allow standard domain names to be verified as identities.
Automatic SSL: The gateway should automatically provision Let's Encrypt certificates for any mapped custom domains.
37. AI Agent Personas (AAP)
The system shall treat AI Agents as first-class citizens with their own DIDs.
Parent-Child Linking: AI Agent DIDs must include a controller field pointing to the Human Persona that owns them.
Restricted Capabilities: The app must allow "Capabilities-based Security," where an agent is cryptographically barred from signing Civil Contracts or moving assets unless a multi-sig threshold with the human is met.
38. Plug-and-Play Inference (Ollama/Local Integration)
The PDS shall include a standard Inference Proxy API.
Workflow: When the user selects a "Smart Filter," the PDS routes the data through a local Ollama instance or a community-run vLLM node.
Prompt Transparency: The "System Prompt" for every algorithm must be public and verifiable. If an NGO claims their algorithm is "unbiased," the community can inspect the actual weights and prompt instructions.
39. Distributed Reputation Oracles
AI can be used as a Tier 0 Arbitrator.
The "Sanity Check": Before a human enters the HDR (Judicial) process, a local AI analyzes the evidence and provides a "Likely Outcome" report.
Automated Labeling: AI agents can act as "Labelers" (as described in v1.6), tagging millions of posts for quality, spam, or sentiment, which users can then choose to "Listen to" or ignore.
40. Static Asset Resolver (SAR)
The PDS must include a module that can interpret a directory CID as a web root.
Index Resolution: If a request hits a folder CID without a filename, the PDS must automatically serve index.html.
Relative Pathing: All assets (images, scripts) must be referenced using Relative URLs to ensure the site functions correctly regardless of which gateway or local node is serving it.
41. Automated Deployment Pipeline
Git Integration: The Vault or a CLI tool should support "Push-to-Publish." When the engineer pushes code to a repo, a GitHub Action (or local script) builds the site, signs the result with the Persona key, and updates the PDS.
Versioning: Every "Publish Event" is recorded in the Persona's signed history. This allows for Instant Rollbacks—to revert the website, the Persona simply signs a new event pointing to a previous CID.
42. Handle Resolution Protocol
The system shall support two methods for resolving a handle (e.g., alice.aletheia.social) to a DID.
Method A: DNS TXT: The client queries the DNS for a record at _atproto.alice.aletheia.social.
Method B: HTTPS Well-Known: The client fetches https://alice.aletheia.social/.well-known/atproto-did.
Validation: To prevent "spoofing," the DID document returned by the PDS must contain a back-link to the handle.
43. Automated Subdomain Issuance
The PDS software must include a "Registrar Service."
Request: User signs up with a desired username.
Availability Check: PDS checks its internal database.
Creation: If available, the PDS automatically updates its Virtual Host configuration and internal DNS to route traffic for newuser.pds-domain.com.
44. The Aggregator API (Search Provider)
The system must support a SearchService endpoint that the Client App can query.
Query Format: GET /xrpc/org.aletheia.search.query?q=keyword
Response Schema: Returns a list of DIDs + Handles + Profile_Snaps.
Ranking Transparency: The provider must publish its Ranking Logic (e.g., "We prioritize accounts with 3+ Web-of-Trust endorsements").
45. Cross-Namespace Resolution
The Search Indexer must implement a "Resolver Bridge":
Handle Lookup: If a search matches a .eth name, the indexer queries the ENS Smart Contract on Ethereum to find the associated DID.
DNS Lookup: If it matches a .com, it checks the _atproto DNS record.
Local Index: If it matches a PDS subdomain, it checks its local cache of the PDS "User Directory."
***** Master Architecture Document: Project Aletheia
:PROPERTIES:
:CREATED: [2026-03-21 Sat 04:05]
:END:
Version: 1.0 (January 2026)
Status: Design Baseline
Concept: A Sovereign Social Operating System (S-SOS)
1. System Philosophy & Objectives
Aletheia is designed to solve "Digital Feudalism" by decoupling Identity, Data, and Logic from central platforms.
Sovereignty: Users own their keys (DIDs) and data (PDS).
Privacy: Multi-persona architecture prevents context collapse and mass surveillance.
Commerce: Built-in Lightning Network payments for services and data seeding.
Justice: Cryptographic civil law contracts with decentralized arbitration.
2. Core Architectural Pillars
2.1 Identity: Hierarchical Multi-Persona Model
The Root: A Master Seed (BIP-39) kept offline on a "Vault Device."
Personas: Hardened child keys (BIP-44) derived from the root. Each Persona is a distinct DID (did:key or did:plc).
Profiles: Contextual metadata views (Social, Work, Dating) signed by a Persona.
Security: If a phone is stolen, the Vault Device issues a Key Rotation Event to revoke the compromised Persona key without exposing the Master Seed.
2.2 Data: Personal Data Servers (PDS) & Relays
PDS: A user’s personal "Social Cloud." It stores signed events (posts, likes) and encrypted blobs (media).
Relays (The Firehose): Aggregators that crawl PDS nodes to create a global, searchable stream of public data.
Mirroring: Community nodes provide encrypted backups for one another, ensuring data remains unbannable and resilient.
2.3 Economy: The Lightning Layer
Incentivized Seeding: Users earn micro-sats for providing P2P bandwidth (WebRTC) for media delivery.
Pay-to-View: Creators can wrap content in HODL Invoices, requiring a payment preimage to unlock the decryption key.
Direct Support: Integrated tipping and subscription logic at the protocol level.
2.4 Justice: Sovereign Contract & Arbitration (SCAL)
Ricardian Contracts: Human-readable terms hashed with machine-executable logic.
Multi-Level Arbitration:
Tier 1: Social Circle (Web of Trust).
Tier 2: Professional Guilds (Verified Experts).
Tier 3: Global Jury (Staked Random Crowds).
Enforcement: Cryptographic escrow (HODL) and reputation "slashing" attestations.
3. Communication & Privacy
Messaging (Asynchronous): DIDComm v2 for secure, metadata-masked routing between Personas.
Calls (Synchronous): WebRTC with decentralized signaling via DIDComm.
Encryption: Envelope Encryption for all private data. Content is encrypted with a Data Key (DEK), which is wrapped by the Persona Public Key. This allows for instant re-keying if a device is stolen.
4. Discovery & AI
Pluggable Algorithms: Users subscribe to "Feed Generators" (DIDs). The algorithm provides a "Skeleton" of CIDs; the client app hydrates the content.
AI Agents: AI has its own DID, controlled by a human. It can perform tasks (summarization, moderation) using authorized sub-wallets.
Open Web Bridge: Public gateways translate P2P CIDs into standard HTTP URLs, making content searchable by Google and accessible via standard browsers.
5. Technical Implementation Stack (The "Engineer's Toolbox")
Layer Recommended Technology
Identity W3C DIDs, BIP-39/44, SLIP-0039 (Shamir)
Networking AT Protocol (Scaffolding), Libp2p
Communication DIDComm v2, WebRTC
Payments Lightning Network (LND/CLN), HODL Invoices
Database SQLite (Local), NoSQL/IPFS (PDS Storage)
AI/Logic Local Inference (Ollama), vLLM
6. Disaster Recovery: The "Broken Root" Protocol
In the event of a lost Master Seed, Aletheia utilizes Social Recovery:
Shamir Secret Sharing (SSS): Master Seed is split into a 3-of-5 threshold during setup.
Guardians: Trusted DIDs (friends/lawyers) hold fragments.
Reconstruction: Fragments are combined on a new Vault Device to rebuild the root and regain authority over all Personas.
***** Growth
:PROPERTIES:
:CREATED: [2026-03-21 Sat 04:10]
:END:
Scaling a decentralized network requires shifting from "Hand-holding" to "Protocol Incentives."
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 Agora 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.
*** Expand on default profile types and those chosen for v.1
:PROPERTIES:
:CREATED: [2026-03-20 Fri 08:10]
:END:
*** Contacts
:PROPERTIES:
:CREATED: [2026-03-21 Sat 03:16]
:END:
Technical Specifications: Sovereign Contract & Arbitration Layer (SCAL)
Objective: To enable personas to execute binding Ricardian contracts (Human + Machine readable) with multi-tiered, decentralized dispute resolution.
1. The Ricardian Contract Module
A contract in this system is not a PDF; it is a Cryptographic Object composed of:
Natural Language (The Markdown): The human-readable terms (e.g., "Person A delivers 100 bricks to Person B by Friday").
Machine Logic (The JSON-LD): The executable parameters (e.g., due_date: 2026-01-16, price_sats: 50000, arbitrator_did: did:key:xyz).
The Merkle Link: Both parts are hashed together. If you change a comma in the text, the digital contract breaks. This ensures the "Code" and the "Law" are the same thing.
2. Payment & Escrow: The "HODL Invoice"
For service delivery, we use Lightning HODL Invoices. This is a trustless escrow that doesn't require a middleman to hold the money.
Commitment: The Buyer "pays" the invoice. The money leaves their wallet but is locked in the network.
The Proof: The Seller sees the money is locked and delivers the goods.
Settlement: Once the Buyer confirms receipt, they release the Preimage (the key), and the money instantly moves to the Seller.
Dispute: If there is a problem, the funds stay locked until an Arbitrator provides the key to either the Buyer (Refund) or Seller (Payout).
3. Multi-Level Arbitration (The "Circles" Model)
To address the "Weak Rule of Law," we use a tiered system of human judgment:
4. Enforcement: Social vs. Financial
​In a weak rule-of-law environment, we use two "sticks" to ensure the contract is followed:
​Financial Collateral: Both parties can be required to lock "Safety Deposits" in a 2-of-3 multisig before the contract begins.
​Reputation Slashing (Social Enforcement): If a persona loses an arbitration and refuses to comply, their DID is "Flagged" across the entire network. Because their identity is persistent, they can't just delete their account. Their "Credit Score" in the community drops to zero, and they can no longer find work or trade.
*** Relay economics bootstrapping
:PROPERTIES:
:CREATED: [2026-03-21 Sat 03:05]
:END:
Yes, they absolutely can, and in the early stages of a decentralized network, this is actually a significant risk. We call these "Honeypot Relays."
Because a relay is just a server that sees your traffic, it is technically possible for an operator to offer a "free" service while secretly harvesting your metadata to sell to advertisers or analytics firms.
1. The "Metadata Harvesting" Trap
Even if your messages are encrypted, a relay sees a wealth of information that is highly valuable for "Surveillance Capitalism":
IP Addresses: They know exactly where you are and what device you're using.
Social Graph: They see who you talk to, how often, and who is in your inner circle.
Activity Patterns: They know when you wake up, when you’re most active, and what topics (tags) you interact with most.
Unencrypted Content: Unless you use end-to-end encryption (E2EE) for every single post, the relay can read your public posts and "read-only" data to build an interest profile on you.
2. Why "Decentralized Surveillance" is Weaker
While a relay can act like a mini-Facebook, it is fundamentally less powerful for three reasons:
No Walled Garden: On Facebook, if you leave, you lose your friends and your history. In this model, if you find out a relay is selling your data, you simply uncheck a box in your settings. You move to a new relay, and your followers find you instantly because your identity (DID) hasn't changed.
Fragmented Data: Most users connect to multiple relays simultaneously (e.g., one for home, one for work, one global). No single relay has the "whole picture" of your life unless you only ever use that one relay.
The "Tor" Option: Advanced users and LLCs can run their PDS through a VPN or Tor. This makes it impossible for the relay to see your true IP address, stripping away the most valuable piece of surveillance data.
3. The "Bootstrap Phase" Economics
Early in the network’s life, "Surveillance Relays" might be the only ones that are free and fast. This creates a "Bootstrap Trap":
The Lure: A big tech company might launch a massive, free, high-speed relay to capture the early market.
The Defense: As the network grows, "Privacy-First" relays (funded by the NGO dues or micro-tips we discussed) will emerge.
The Switch: Because your data is portable, the moment a better, more ethical relay exists, the entire community can migrate in a single day. In the old world, a migration takes a decade; in the decentralized world, it takes a click.
4. How an LLC or NGO Protects Itself
If you are running an organization, you shouldn't trust a "free" public relay for sensitive operations. Instead, you use a Tiered Relay Strategy:
Internal Relay: Your NGO runs its own private relay for internal board communications. This relay is "dark" to the public and collects zero data.
Public Gateway: You use the big "Surveillance" relays only for public PR and marketing posts. You treat these relays like "billboards"—you expect people to look at them, but you don't do your private business there.
*** Governance
:PROPERTIES:
:CREATED: [2026-03-21 Sat 03:23]
:END:
1. The Governance "Stack"
Governance in this system operates at three distinct scales, mirroring the human organization patterns we've built:
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 everyone (e.g., "Should we upgrade the PDS data schema to version 2.0?").
2. Voting Mechanisms
Traditional "One-token, One-vote" often leads to plutocracy (the rich rule). To build a healthy social network, the engineer must implement more nuanced math:
Quadratic Voting: The cost of a vote increases by the square of the votes cast (cost = votes^2). This prevents a single whale from drowning out 1,000 small voices. It prioritizes the intensity of preference across the community.
Conviction Voting: Voters don't just "click a button." They "stake" their preference over time. The longer you hold your vote on a proposal, the more weight it gains. This rewards long-term thinkers and prevents "flash-mob" takeovers of community policy.
Liquid Democracy: You can delegate your "Moderation Vote" to a friend you trust. If that friend stops being trustworthy, you instantly pull your delegation back.
3. The "Constitution as Code" (Executable Policies)
An NGO in this system doesn't just have a "handbook." It has a Smart Constitution stored on its PDS.
Policy Triggers: If a vote passes to "Change the Arbitration Fee," the system doesn't wait for a human to update the website. The Contract Module (from our previous spec) automatically updates the fee parameter across all the NGO's active contracts.
The "Veto" Safety: High-impact changes (like moving the Treasury) can have a Time-Lock. The vote passes, but execution is delayed by 7 days. This gives the community a "Cooling-Off Period" to trigger a counter-vote if they suspect foul play.
*** Courts
:PROPERTIES:
:CREATED: [2026-03-21 Sat 03:18]
:END:
1. The Multi-Level "Court" Hierarchy
We mirror the traditional legal system but replace "jurisdiction by geography" with "jurisdiction by reputation and stake."
2. The Mechanics of an Appeal
​In this system, an "Appeal" isn't a request to a boss; it's a Cryptographic Escalation:
​Level 1 Ruling: The "Local Elder" rules. If both parties accept, the HODL invoice settles.
​The Trigger: If one party disagrees, they pay an "Appeal Fee" (to prevent spam). This fee funds the next level of jurors.
​The Escalation: The contract logic automatically "unlocks" the case for Level 2 (The Guild). The data (evidence, previous ruling) is pushed to the new panel.
​Finality: Level 3 is the "Final Court of Appeal." Once the Global Jury rules, the cryptographic keys are released, and the smart contract executes the payment automatically—no human can stop it.
3. Why this works in "Weak States"
In a country where the police won't help you collect a debt, this system provides Self-Executing Justice:
The "Escrow Stick": The money is already gone from the buyer's wallet (locked in Lightning).
The "Reputation Stick": In a decentralized society, your DID is your livelihood. Losing your "Trust Score" is a digital death sentence for your business
*** User journey
:PROPERTIES:
:CREATED: [2026-03-21 Sat 03:28]
:END:
Phase 1: Onboarding (The Birth of the Persona)
Download & Seed: The user downloads the app. The first thing it does is generate a Seed Phrase (the Master Key).
Persona Creation: The user doesn't create a "Username." They create two Personas: "Work" and "Social." Behind the scenes, the app derives two different DIDs from the same Master Key.
The Founder Connection: For a minor, the parent scans a QR code to "Co-sign" the identity, setting up the Succession Logic we discussed.
PDS Selection: The user is asked: "Where would you like to store your data?" They select a Community PDS run by a local NGO they trust.
Phase 2: Consumption & "Seeding" (The Data Economy)
Choosing a Lens: The user goes to the "Marketplace" and selects the "Scientific Signal" Algorithm. Their feed instantly rearranges to show verified research.
Micro-Earning: The user watches a video. A toggle in their settings is on: "Support this creator by seeding." While they watch, their phone serves bits of the video to 3 other nearby users via WebRTC.
The Reward: Because they provided bandwidth, the creator’s PDS sends a "Thank You" of 5 sats ($0.002) directly to the user’s Lightning wallet. It’s small, but it covers the cost of their PDS hosting for the month.
Phase 3: The Civil Contract (Digital Law)
The Deal: User A wants to buy a custom chair from User B.
The Contract: They click "Create Contract." They select a Markdown Template for "Handmade Goods."
Arbitration Choice: They both agree to use the "Carpenters' Guild" as the Level 2 Arbitrator.
The Lock: User A pays the invoice. The funds move into a HODL Escrow. User B sees the "Funds Locked" status and starts building.
The Delivery: User B delivers the chair. User A scans a QR code on the chair, which releases the Preimage, instantly paying User B.
*** AI integration
:PROPERTIES:
:CREATED: [2026-03-21 Sat 03:53]
:END:
Integrating AI into the "Sovereign Stack" transforms it from a static database into an active, intelligent ecosystem. In this architecture, AI isn't a central "God-eye" controlling you; it is a Personal Assistant or a Community Curator that you own and direct.
1. The Decentralized AI Architecture
To keep AI sovereign, we distribute the three pillars of machine learning: Compute, Data, and Models.
Local Inference (On-Device): Your phone or PDS runs small, optimized models (like Llama-3-8B or Mistral) for privacy-sensitive tasks.
Decentralized Compute Swarms: For heavy tasks (like 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, creating a P2P AI Marketplace.
Privacy-Preserving Training: Using Federated Learning, an NGO can train a custom algorithm on its members' data without ever seeing that data. The members' devices compute "updates," which are then combined into a new model version.
2. AI Personas as "Digital Agents"
In our system, AI doesn't just "chat"—it has its own DID (Decentralized Identifier).
Delegated Authority: You can spawn an "AI Agent Persona" from your Master Seed. You delegate specific rights to it: "You are authorized to spend 1,000 sats/month to buy research papers and summarize them for me."
Verifiable Origins: Because every AI post is signed by its Agent-DID, you can instantly distinguish between "Human-Signed" and "AI-Signed" content in your feed.
** Are our meetings and discussions being summarized in the dailies? There are some gems there that really should make their way to the daily then to atomic notes eventually