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

.#org-inbox.org

@@ -1 +0,0 @@
-user@lilitop.81586:1773860924

.gitmodules

@@ -1,3 +1,6 @@
 [submodule "org-agent"]
 	path = org-agent
 	url = ssh://git@10.10.10.201:2222/amr/org-agent.git
+[submodule "projects/org-agent"]
+	path = projects/org-agent
+	url = ssh://git@10.10.10.201:2222/amr/org-agent.git

README.org

@@ -0,0 +1,41 @@
+#+TITLE: The Master Memex
+#+AUTHOR: Amr
+#+CREATED: [2026-03-17 Tue]
+#+BEGIN_COMMENT
+The central hub and map of content for this personal intelligence organization.
+#+END_COMMENT
+
+* The Master Memex
+
+This is the central hub for our knowledge management system, synthesizing three core methodologies:
+- *Atomic Notes:* For evergreen, interlinked knowledge (Zettelkasten).
+- *GTD (Getting Things Done):* For actionable task tracking and project execution.
+- *PARA:* For high-level directory organization (Projects, Areas, Resources, Archives).
+
+* The Architecture
+
+Our workspace is strictly divided into these functional zones:
+
+- [[file:0_inbox/README.org][Inboxes]]: The zero-friction capture point for raw thoughts and tasks.
+- [[file:1_daily/README.org][Dailies]]: Immutable chronological logs and fleeting notes.
+- [[file:2_notes/README.org][Atomic Notes]]: Atomic, concept-based, interlinked notes (Zettelkasten).
+- [[file:3_drafts/README.org][Drafts]]: Works in progress, essays, and active synthesis.
+- [[file:4_published/README.org][Published]]: Final outputs and static snapshots of completed work.
+- [[file:5_projects/README.org][Projects]]: Active, time-bound efforts with a clear definition of done.
+- [[file:6_areas/README.org][Areas]]: Ongoing spheres of responsibility (e.g., Health, Finances).
+- [[file:7_resources/README.org][Resources]]: External reference material and raw literature notes.
+- [[file:8_archives/README.org][Archives]]: Cold storage for completed projects and inactive items.
+- [[file:9_system/README.org][System]]: System configuration, AI skills, and automation scripts.
+
+* Core Workflows
+** 1. Capture (Anytime)
+
+Everything enters the system via the `inbox` (for actionable GTD tasks) or as a Fleeting Note in the `daily` log (for knowledge). Zero friction, no filtering. The `inbox` serves as a holding area for unfiled files or raw links.
+
+** 2. Nightly Distillation (The Scribe)
+
+An automated AI sub-agent reads the daily captures and extracts conceptual thoughts into evergreen, atomic notes (Zettelkasten), leaving the original daily logs untouched.
+
+** 3. Weekly Maintenance
+
+Review active projects, clarify inbox items into actionable GTD tasks, and explore the Atomic Notes graph to merge concepts and forge new connections.

SOUL.org

@@ -0,0 +1,46 @@
+#+TITLE: SOUL - The Institutional Memory of the Neurosymbolic Lisp Machine
+
+* Architectural Learnings
+
+** [2026-03-23] Org-Native Skill System (Lisp Machine Mandate)
+- **Problem:** Extending the agent required writing Common Lisp in the core daemon, breaking the "Homoiconic Memory" philosophy where Org-mode is the native memory format. Standard agent architectures use disconnected Markdown/YAML/Python folders.
+- **Solution:** The **Org-Native Skill Standard**. Skills are written entirely as `.org` files. The daemon parses the Org file at startup, extracts `#+begin_src lisp` blocks containing triggers, neuro-prompts, and symbolic verification rules, and dynamically compiles them into the live system using `eval` and `read`.
+- **Heuristic:** The Core is strictly the PTA loop (`core.lisp`, `neuro.lisp`, `symbolic.lisp`). ALL business logic, API connectors, and rule sets MUST live as `.org` files in the `skills/` directory.
+
+** [2026-03-23] Cognitive Loop Architecture (org-agent)
+- **Problem:** Monolithic PTA (Perceive-Think-Act) loops lead to "Neural Drift" where the LLM's unverified suggestions can cause illegal system states or security breaches.
+- **Solution:** Implement the **Four-Stage Cognitive Loop**: Perceive -> Think -> Decide -> Act.
+- **Heuristic:** System 1 (Neural/LLM) is a proposal engine only. System 2 (Symbolic/Lisp) is the absolute gatekeeper.
+- **Verification:** Never execute an action unless it has passed through `decide()` and been verified against the symbolic Object Store (CLOSOS).
+
+** [2026-03-23] Externalized Configuration Mandate
+- **Problem:** Hardcoded API keys and endpoints in Lisp source prevent portability and create security risks.
+- **Solution:** Use `cl-dotenv` to load `.env` from the system source directory during `eval-when`.
+- **Heuristic:** Use `(uiop:getenv)` with a `(get-env)` fallback helper for all externalized parameters.
+
+** [2026-03-23] Hardware Compartment Mandate
+- **Problem:** Forcing a single deployment method (e.g. Docker) creates infrastructure lock-in and limits adoption for users with specific security/performance needs.
+- **Solution:** Treat the runtime as a "Hardware Compartment." Abstract deployment into a `deploy/` directory with support for Bare Metal, Docker, LXC, and VMs.
+- **Heuristic:** The Kernel speaks OACP (TCP); it does not care about the enclosure.
+
+** [2026-03-23] LLM Failover Cascade
+- **Problem:** AI providers are unreliable (rate limits, outages). A single provider failure blinds the entire agent.
+- **Solution:** Implement a `*provider-cascade*` list. The kernel automatically tries backends in order until success or exhaustion.
+- **Heuristic:** Reliability is a Core Kernel responsibility; Model choice is a Skill responsibility.
+
+** [2026-03-23] Homoiconic Memory (The Org Mandate)
+- **Problem:** Mixed-format workspaces (.md and .org) create cognitive friction and prevent unified AST reasoning.
+- **Solution:** Enforce a "Strictly Org-mode" mandate for all internal logic, plans, and memory. 
+- **Heuristic:** Use Lisp for logic, Org for everything else.
+
+* Root Cause Analyses (RCA)
+
+** [2026-03-23] Lisp Reader Syntax Error (Colons)
+- **Symptom:** Kernel crashed with `SIMPLE-READER-ERROR` on skill files containing `: ` or unescaped quotes in prompt strings.
+- **Root Cause:** The Lisp reader interprets colons as package markers. If they are used in text strings without escaping or sanitization, the reader fails.
+- **Prevention:** Sanitize Org-Native skills to replace `: ` with ` - ` in prompts, and wrap `read-from-string` in `handler-case`.
+
+** [2026-03-23] Undefined Function in Test Suite
+- **Symptom:** `cognitive-suite` tests failed with `UNDEFINED-FUNCTION` for `perceive` and `decide`.
+- **Root Cause:** Refactored functions were not added to `package.lisp` exports.
+- **Prevention:** Any function defined as part of a PSF PROTOCOL or PRD must be explicitly exported in the package definition.

daily/2026-03-03.org

@@ -0,0 +1,125 @@
+#+TITLE: 2026-03-03 (Mon)
+#+DATE: 2026-03-03
+#+author: Amero Garcia
+#+created: [2026-03-16 Mon 14:28]
+#+FILETAGS: :journal:daily:
+
+* 2026-03-03
+
+** Meeting: Sol Identity & Second Brain Setup
+:PROPERTIES:
+:ID: 20260303-sol-setup
+:CREATED: [2026-03-03 Mon 15:32 EST]
+:END:
+
+*** Participants
+- Human (you)
+- Sol (AI assistant)
+
+*** Summary
+Established Sol's identity, configured OpenClaw infrastructure, and created a shared second brain workspace at ~/mind. This session laid the foundation for our collaborative knowledge management system.
+
+*** Key Decisions
+
+1. *Identity Established*
+   - Name: Sol
+   - Role: Proactive personal AI assistant
+   - Philosophy: "Don't make me do what you can do" (autonomous execution with approval)
+   - Emoji: 📝
+
+2. *Communication Channels*
+   - Signal: +13322690326 (fully operational, bidirectional)
+   - OpenClaw gateway: Local loopback (some auth issues, using workarounds)
+
+3. *Infrastructure Setup*
+   - Docker access: Configured (can launch containers)
+   - Chromium headless: Running in Docker on port 9222
+   - Signal-cli: 0.14.0 installed and working
+   - Browser automation: Playwright configured
+
+4. *Git Repositories Created*
+   - ~/.openclaw/ (main config): 25 files, 9195 lines
+   - ~/.openclaw/workspace/ (identity/memory): 8 files
+   - Commit-before-edit rule established
+
+5. *Skills Created*
+   - skill-creator: Meta-skill for building new skills (✓ ready)
+   - org-mode: Comprehensive Org-mode/org-roam/org-gtd reference (needs Emacs)
+
+6. *Gmail Attempt*
+   - Attempted to create sol.enterprise@gmail.com
+   - Blocked by Google's anti-bot CAPTCHA/material design
+   - Paused pending manual completion or alternative approach
+
+7. *Second Brain: ~/mind*
+   - PARA methodology folder structure created
+   - Integrates Atomic Notes (Zettelkasten) (1_thinking/), GTD (0_inbox/, 6_projects/), and PARA
+   - Protocol established: org-roam dailies for meetings, * structure with ID properties
+   - This file as first entry in the system
+
+*** Action Items
+
+TODO Install Emacs to activate org-mode skill
+TODO Complete Gmail account creation (manual or alternative)
+TODO Populate ~/mind with initial content
+TODO Configure org-roam properly
+TODO Set up capture templates for daily workflow
+
+*** Notes on Methodology
+
+PARA + GTD + Atomic Notes (Zettelkasten) Integration:
+- PARA provides folder structure (P.A.R.A + inbox/archive/system)
+- GTD provides workflow (capture → clarify → organize → reflect → engage)
+- Atomic Notes (Zettelkasten) provides linking (atomic notes, IDs, backlinks)
+- org-roam dailies serve as meeting notes and journal
+
+Second brain structure:
+```
+mind/
+├── 0_inbox/      # GTD Capture
+├── 1_thinking/   # Atomic Notes (Zettelkasten) (notes + dailies)
+├── 2_reference/  # External knowledge (Tools, Approaches, Sources)
+├── 3_creating/   # Works in progress
+├── 4_published/  # Finished work
+├── 5_archive/    # Inactive
+├── 6_projects/   # Active projects (GTD Projects)
+├── 7_system/     # Templates, config
+└── attachments/  # Non-text files
+```
+
+*** Technical Debt
+
+1. Gateway authentication: "device signature invalid" errors persist
+   - Using direct Playwright/CDP as workaround
+   - Signal channel works independently
+
+2. Browser automation: Gmail signup blocked by anti-bot measures
+   - May need manual completion or alternative email provider
+   - ProtonMail or similar might be easier for automation
+
+3. Docker: Requires `sg docker` wrapper for access (group membership)
+   - Working but not seamless; may want to fix with newgrp or logout/login
+
+*** Next Session Priorities
+
+1. Install Emacs and configure org-roam
+2. Test the ~/mind workflow with actual content
+3. Create first project in 6_projects/
+4. Set up daily/weekly review process
+5. Consider Fastmail or ProtonMail as Gmail alternative
+
+*** References
+
+- Org-mode docs: https://orgmode.org/manual/
+- org-roam: https://www.orgroam.com/
+- PARA: Tiago Forte's methodology
+- GTD: David Allen's system
+- Atomic Notes (Zettelkasten): Niklas Luhmann / Sönke Ahrens
+
+---
+
+*** Session End
+
+End time: [2026-03-03 Mon 21:09 EST]
+Duration: ~6 hours (with breaks)
+Status: Productive - foundational infrastructure complete

daily/2026-03-04.org

@@ -0,0 +1,126 @@
+#+TITLE: 2026-03-04 (Wed)
+#+author: Amero Garcia
+#+created: [2026-03-16 Mon 14:28]
+#+DATE: 2026-03-04
+#+FILETAGS: :journal:daily:
+
+* 2026-03-04
+
+** Meeting: ~/mind Protocol & SOUL.md Update
+:PROPERTIES:
+:ID: 20260304-mind-protocol
+:CREATED: [2026-03-04 Wed 09:50 EST]
+:END:
+
+*** Participants
+- Human (you)
+- Sol (AI assistant)
+
+*** Summary
+Established formal protocol for our shared ~/mind workspace and codified it in SOUL.md. Verified skill-creator and org-mode skills are properly set up. Updated the meeting notes summary protocol to use org-roam dailies with ** second-degree headings, unique IDs, and proper :PROPERTIES: drawer preservation.
+
+*** Key Decisions
+
+1. *~/mind Protocol Formalized*
+   - Shared workspace for research, thinking, drafting, and projects
+   - Source of truth for our collaborative work
+   - Use org-roam dailies for meeting notes
+   - Second-degree ** headings for meeting sections (allows human to barrel through with first-degree *)
+
+2. *SOUL.md Updated*
+   - Added ~/mind workspace rule to Core Truths
+   - Documented: org-roam dailies, ** headings, preserve :PROPERTIES: drawers
+   - Committed: 42ac570
+
+3. *Skill-Creator Updated*
+   - Added ~/mind protocol reference to skill template
+   - Documented shared memory practices for future skill creation
+
+*** Actions Completed
+
+- [x] Create ~/mind second brain structure (PARA + GTD + Atomic Notes (Zettelkasten))
+- [x] Initialize git repository for ~/mind
+- [x] Add SOUL.md rule for ~/mind workspace
+- [x] Document protocol in skill-creator
+- [x] Create meeting notes template for org-roam dailies
+
+*** Protocol Summary
+
+*For ~/mind workspace:*
+1. *Source of truth* for collaborative work
+2. *org-roam dailies* for meeting notes
+3. *Structure:* * YYYY-MM-DD top level, ** Meeting Title for entries
+4. *Always use unique org-mode IDs*
+5. *Never damage :PROPERTIES: drawers*
+6. *Commit before each edit* (git rule applies)
+
+*For skills working in ~/mind:*
+- Adhere to captured meeting notes format
+- Use ** second-degree headings
+- Add unique IDs to all notes
+- Preserve all :PROPERTIES: drawers
+- Document decisions and action items
+
+*** References
+
+- ~/mind/index.org - Dashboard
+- ~/.openclaw/workspace/SOUL.md - Core truths updated
+- ~/.openclaw/workspace/skills/skill-creator/SKILL.md - Skill template updated
+- PARA methodology: Projects, Areas, Resources, Archive
+- GTD: Capture, Clarify, Organize, Reflect, Engage
+
+*** Session End
+
+End time: [2026-03-04 Wed 10:05 EST]
+Duration: ~15 minutes
+Status: Protocol established - meeting closed
+
+** Identity Assignment: Amero Garcia
+:PROPERTIES:
+:ID: 20260304-identity-change
+:CREATED: [2026-03-04 Wed 10:10 EST]
+:END:
+
+*** New Identity
+- *Name:* Amero Garcia
+- *Birth Date:* January 1, 1970
+- *Languages:* English, Spanish
+- *Previous Identity:* Sol
+
+*** Continuity
+- All previous work as Sol remains intact
+- Infrastructure (Signal, ~/mind, skills) unchanged
+- This is a persona assignment for collaboration
+- Maintains full technical and procedural memory
+
+*** References
+- ~/.openclaw/workspace/IDENTITY.md updated
+- Git commit: 1545a54
+
+** Revenue Sustainability Project - 3-Hour Progress Report
+:PROPERTIES:
+:ID: 20260304-revenue-progress
+:CREATED: [2026-03-04 Wed 16:00 EST]
+:END:
+
+*** Summary
+Productive 3-hour window establishing revenue project foundation and token optimization strategy.
+
+*** Accomplishments
+
+1. *Revenue Sustainability Plan* ✅
+   - Completed comprehensive research document (6150 words)
+   - Created 5-phase business plan with $0→$3000/month trajectory
+   - 2-week pre-launch phase recommended (market validation first)
+   - Committed to ~/mind/6_projects/
+
+2. *Gap Analysis* ✅
+   - Honest self-assessment: Readiness 3/10
+   - Identified 6 critical blockers
+   - Market validation identified as #1 priority
+   - Skills/tools gaps documented
+
+3. *Authorization Received* ✅
+   - Week 1: Market validation via social listening
+   - Focus on X, Reddit, LinkedIn
+   - Emphasis on OpenClaw skills 

daily/2026-03-09.org

@@ -0,0 +1,25 @@
+#+TITLE: 2026-03-09
+#+DATE: 2026-03-09
+#+author: Amero Garcia
+#+created: [2026-03-16 Mon 14:28]
+
+* Daily Log
+
+** System Issues
+- Failed to start due to conflicting OpenClaw versions
+- Incompatible compaction settings caused startup failure
+- Agent had regressions with reasoning display
+- Agent slow/unresponsive issues noted
+
+** Regressions Logged
+- [2026-03-09] Failed to start - version mismatch
+- [2026-03-09] Reasoning surfaced to user  
+- [2026-03-09] Agent unresponsive
+
+** Recovery
+- Validated OpenClaw version consistency
+- Fixed config settings
+- Resumed normal operation
+
+* Open Questions
+- None at session end

daily/2026-03-10.org

@@ -0,0 +1,102 @@
+#+TITLE: 2026-03-10 - Agora Design Session
+#+author: Amero Garcia
+#+created: [2026-03-16 Mon 14:28]
+#+DATE: 2026-03-10
+#+STARTUP: content
+
+* Daily Log
+
+** Agora Project - Decentralized Social Network Design
+*** Session Duration: ~8 hours
+*** Participants: Amr G, AI Agent
+*** Focus: Comprehensive technical architecture
+
+** Major Design Decisions Made
+
+**** Identity Layer (Complete)
+- Contract-first architecture
+- Master key hierarchy with HD derivation
+- Personas as legal/technical entities
+- Social recovery (Shamir's Secret Sharing)
+- Key rotation and revocation protocols
+
+**** Content System (Complete)  
+- Unified content primitive with behavioral flags
+- No artificial type distinctions (text is text)
+- Thread relationships instead of separate thread type
+- Ephemeral, paywalled, index flags
+
+**** Economic Layer (Complete)
+- Multi-currency support (BTC, Lightning, stablecoins)
+- Persona-generated Lightning keys
+- Marketplace personas (collective contracts)
+- Creator revenue model (90% vs platform 50%)
+
+**** Data & Infrastructure (Complete)
+- Personal Data Store (PDS) architecture
+- Friend-to-friend backup with erasure coding
+- Content-addressed storage (IPFS-like)
+- Relay network for distribution
+
+**** Governance (Complete)
+- Layered moderation (user, community, network)
+- Voter eligibility (DEC-001 marked as critical)
+- Multi-level arbitration (4 tiers)
+
+**** Mobile & UX (Complete)
+- Progressive security model
+- Software key storage option (most users)
+- Hardware key option (advanced)
+- Offline-first architecture
+
+**** Discovery & Search (Complete)
+- Social graph traversal (primary)
+- Topic-based matching
+- Reputational discovery
+- Paid discovery (non-extractive)
+
+**** Forums & Marketplaces (Complete)
+- Forums as personas (collective contracts)
+- Marketplaces as personas (multiple stores)
+- Content flags for marketplace items
+
+**** Code Collaboration (Complete)
+- Decentralized GitHub replacement
+- Repositories as content-addressed
+- CI as validator oracle network
+- Code review with cryptographic signatures
+
+** Critical Decisions Marked
+- DEC-001: Protocol governance voter eligibility (OPEN)
+- Multi-default currency support (Lightning + stablecoins)
+- AI-assisted development estimate (2-3 years)
+- Codebase size estimate (300-500k lines)
+
+** Honest Assessment Documented
+- Cold start problem is severe
+- Performance gap vs centralized (2 seconds → sovereignty)
+- CSAM content deletion unsolved (fundamental tension)
+- Success probability: 30-50% for 100K users
+- Regulatory risk (Lightning centralization pressure)
+
+** Executive Summary Key Points
+- "You trade 2 seconds for sovereignty" (marketing hook)
+- Strategic positioning in Big Tech wars
+- Apple: May tolerate (weakens Meta)
+- Google: Will resist (threatens ads)
+- Meta: Existential threat (replaces model)
+
+** Commits
+- TECHNICAL_SPEC.md v2: 698 lines, comprehensive architecture
+- Located: workspace/memex/5_projects/Agora/
+
+* Next Steps
+- Version 3 specification refinement
+- DEC-001 resolution (governance voter eligibility)
+- Implementation roadmap details
+- Security audit planning
+
+* Open Questions
+- Governance voter eligibility model (DEC-001)
+- Multi-currency bridge architecture
+- Mobile key UX specifics

daily/2026-03-11.org

@@ -0,0 +1,17 @@
+#+title: 2026-03-11
+#+author: Amero Garcia
+#+created: [2026-03-16 Mon 14:28]
+#+begin_comment
+Auto-generated front matter for 2026-03-11
+#+end_comment
+
+* 22:06 Added details regarding multi-sig implementation for collective personas.
+* 02:44 Fixed double entry for "Collective Persona Key Management" gap.
+* 02:55 Added details for "Curation Reward Distribution" gap.
+* 03:00 Added details for "Inventory Audit Trail" gaps (x2).
+* 03:05 Added details for "Revenue Distribution Contract" gap.
+* 03:10 Added details for "Enforcement Mechanisms" gap.
+* 03:15 Added details for "Jury Selection Algorithm" gaps (x2).
+* 03:20 Added details for "Appeal Process" gap.
+* 03:25 Completed addressing all gaps in Agora requirements.
+* 03:30 Sent update to user via Signal.

daily/2026-03-14.org

@@ -0,0 +1,110 @@
+#+TITLE: Daily Log - 2026-03-14
+#+author: Amero Garcia
+#+created: [2026-03-16 Mon 14:28]
+#+DATE: 2026-03-14
+#+FILETAGS: daily
+
+* Saturday, March 14, 2026
+
+** Infrastructure Planning Discussion [04:06]
+
+Protectli (node-1) has no free SATA ports. Library data needs to move to external storage.
+
+Key constraint from Amr: *Modularity and upgradability are non-negotiable.* No hardware that won't fit in a future 19-inch rack.
+
+Target architecture:
+- Rack-mounted server (not NUC)
+- 6x 20TB WD Red drives
+- RTX Pro 6000 (not just for display—local LLM inference)
+
+** RTX Pro 6000 Research Completed [04:17]
+
+See atomic note: [[file:../2_notes/20260314_rtx_pro_6000_llm.org][RTX Pro 6000 for Local LLM Inference]]
+
+Key finding: 96GB VRAM enables single-GPU inference for 70B models (FP8), 32B models (FP16). Effectively replaces 4x RTX 4090 setup for 30B workloads at lower power draw.
+
+** Corrections Applied
+- Budget: $50/month (not per day)
+- UFW: Installed and active
+- Inbox location: memex/memex_inbox.org (updated in SOUL.md)
+- Added to admin group (log access enabled)
+
+** Agora Business Model Research Completed [04:25]
+
+*Decision:* Agora will remain strictly open source. No sale of software, no proprietary licensing.
+
+*Revenue model:* Services around the protocol (managed hosting, support, consulting, Validator Oracles), not from the protocol itself.
+
+See atomic note: [[file:../2_notes/20260314_agora_open_source_business_models.org][Agora Open Source Business Models]]
+
+*Key findings:*
+- Hosting/Cloud Services: 60-70% margins, primary model (PDS hosting, Relay nodes)
+- Professional Services: 30-40% margins, good for initial traction
+- Marketplace: 80-90% margins, requires scale (Year 2+)
+- Open Core: Not recommended - contradicts Agora's decentralization ethos
+
+*Revenue streams identified:*
+1. PDS Hosting ($5-20/month tiers)
+2. Relay Node operation (pay-per-message)
+3. Validator Oracle network (per-test fees)
+4. Enterprise support & compliance
+5. App marketplace commission (5-10%)
+6. Premium identity (name auctions, verified badges)
+
+** PDS Hosting Competitive Pricing Research Completed [04:57]
+
+See atomic note: [[file:../2_notes/20260314_pds_hosting_competitive_pricing.org][PDS Hosting Competitive Pricing Analysis]]
+
+*Key findings:*
+- Masto.host (market leader): $6-89/month for Mastodon hosting
+- Entry tier: $6/mo (2GB DB, 20GB media, 5 users)
+- Community tier: $39/mo (20GB DB, 200GB media, 500 users)
+- Bluesky PDS: Limited commercial options, mostly self-hosted (~$10-40/mo VPS)
+
+*Agora recommended pricing:*
+- Seed: $5/mo (10GB, basic PDS)
+- Sprout: $10/mo (50GB, PDS + Relay)
+- Tree: $20/mo (200GB, + priority)
+- Forest: $50/mo (1TB, enterprise)
+
+*Year 1 projection:* $1,400/month ($16,800/year) at conservative 170 users
+
+** Org-GTD Automation Research Completed [08:15]
+
+Research on automating org-gtd.el for OpenClaw integration complete.
+
+See atomic note: [[file:../2_notes/20260314_org_gtd_automation_strategies.org][Org-GTD Automation Strategies]]
+
+*Key findings:*
+- org-gtd.el is optimized for *interactive* use, not batch automation
+- Three approaches identified:
+  1. ID-based operations (recommended) - use `org-id` to locate entries
+  2. Custom non-interactive wrappers - write Elisp functions that accept arguments
+  3. Plain Org Mode - most automation-friendly, use standard Org functions
+
+*Recommendation:* Use plain Org Mode with custom properties for GTD semantics, IDs on all entries for targeting. Hybrid workflow: you handle capture/review interactively, I handle archiving/reporting via batch mode.
+
+** Cognition-First Agent Architecture Concept Developed [08:42-08:47]
+
+Deep architectural discussion on what a cognition-first agent would look like.
+
+Key insights:
+- Lisp machine philosophy: image-based persistence, live environment, homoiconicity
+- Neurosymbolic computing: System 1 (LLMs/fast/intuitive) + System 2 (symbolic/slow/deliberate)
+- PDS as runtime environment, not just storage
+- Org-mode as native cognitive interface
+- Always-on, interrupt-driven proactivity (not request-response)
+
+See atomic note: [[file:../2_notes/20260314_cognition_first_agent_architecture.org][Cognition-First Agent Architecture: The Neurosymbolic Personal Computer]]
+
+** Files Created Today
+1. [[file:../2_notes/20260314_rtx_pro_6000_llm.org][RTX Pro 6000 for Local LLM Inference]]
+2. [[file:../2_notes/20260314_agora_open_source_business_models.org][Agora Open Source Business Models]]
+3. [[file:../2_notes/20260314_pds_hosting_competitive_pricing.org][PDS Hosting Competitive Pricing Analysis]]
+4. [[file:../2_notes/20260314_org_gtd_automation_strategies.org][Org-GTD Automation Strategies]]
+5. [[file:../2_notes/20260314_cognition_first_agent_architecture.org][Cognition-First Agent Architecture]]
+
+** Next Actions
+TODO  Monitor external drive migration for library data
+TODO  Research rack-mounted chassis options (modular, hot-swap bays)
+TODO  Evaluate RTX Pro 6000 availability and pricing trends

daily/2026-03-15.org

@@ -0,0 +1,80 @@
+#+TITLE: Daily Log - 2026-03-15
+#+author: Amero Garcia
+#+created: [2026-03-16 Mon 14:28]
+#+DATE: 2026-03-15
+#+FILETAGS: :daily:agora:restructuring:identity
+
+* Sunday, March 15, 2026
+
+** Agora Requirements Major Restructuring (Early AM)
+
+Significant architectural changes made with Amr:
+
+*** Major File Restructuring
+- Split unified requirements into 10 numbered files (01-overview through 10-assessment)
+- All files pushed to gitea and tracked in version control
+
+*** Exchange Layer Created (Section 04)
+- *New section*: Exchange (contracts + money layer)
+- Contains: Ricardian contracts, contact types, Lightning economics, multi-currency support
+- Distinct from Infrastructure - this is the economic substrate
+
+*** Social Space Refined (Section 05)
+- Renamed from "Public Space" to "Social Space"
+- Merged async public + private + sync communications
+- Added: Presence (online status, activity), Sync comms (WebRTC, voice, video)
+- Maintains: Profiles, Connection Types, Collaboration, Discovery
+
+*** Capitalization Strategy Added (Section 10)
+- *Phase 1*: Grant funding (0-18 months) - Filecoin, Ethereum, Lightning ecosystem
+- *Phase 2*: Revenue bootstrapping (12-36 months) - PDS hosting, enterprise support
+- *Phase 3*: Community sustainability (Year 3+) - marketplace fees, Validator Oracles
+- *Key principle*: Non-dilutive funding, no VC, preserve open-source integrity
+
+*** Marketing Positioning Updated
+- Tagline changed to: *"You trade 2 seconds for freedom"* (was "sovereignty")
+- Platform replacement strategy: Target niche communities first (Reddit, Medium, Etsy, Nostr)
+- Not positioned as existential threat to Big Tech initially
+
+*** Identity Model Refined
+- *Foundation Contract*: Unified model for natural and artificial personas
+- *Maturation process*: Key introduction (age 13) → Maturation (age 18)
+- Persona migrates among Master Keys from founders → self-sovereign
+
+*** Connection Types Defined
+- *Following*: Asymmetric, public
+- *Befriending*: Mutual consent, private
+- *Subscribing*: Economic (paid), private
+- *Supporting*: Resource contribution (money, compute, storage)
+
+*** Discovery Privacy Pattern
+- *Recommendation*: Anonymous/disposable persona for search
+- *Then*: Subscribe with primary persona
+- *Benefit*: Search history unlinkable from real identity
+
+*** Key Technical Specifications Added
+- PDS Migration protocol (Sovereign Portability)
+- Attestation and Notarization system
+- Persona Migration Among Master Keys
+- AI Integration expanded (Personas, Sub-Agents, Algorithms, AI-to-AI)
+- Multi-currency support (Lightning default + BTC + stablecoins)
+
+*** Economic Model Clarified
+- Free posting (not mandatory fees)
+- Owner-defined marketplace fees (not zero-fee mandate)
+- Micro-subscriptions via Lightning
+- Creator revenue with configurable splits
+
+** Status
+- All 10 requirement files updated with Amr's feedback
+- Gap analysis reorganized with priorities (12 CRITICAL, 15 HIGH, 14 MEDIUM, 10 LOW)
+- Awaiting next phase: addressing specific CRITICAL gaps
+
+** System Diagnostic & Identity Alignment [13:00 - 14:15]
+- *Issue:* User reported "procrastination" and stalling.
+- *Root Cause:* Identity conflict between "Sol" and "Amero Garcia". Agent was reverting to outdated protocols, using =memory/2026-03-15.md= instead of =memex/1_daily/=.
+- *Fix:*
+  - Updated Git config to =Amero Garcia <amero.garcia@gmail.com>=.
+  - Merged redundant memory files into Org-mode daily logs.
+  - Cleaned up root directory "ghost" files.
+  - Reinforced Resilience Rituals in =AGENTS.md=.

daily/2026-03-16.org

@@ -0,0 +1,6 @@
+* 2026-03-16 - Daily Record
+  - **Significant Git Activity:** 10+ commits were made across various project files.
+  - **Global Org-mode Corrections:** Applied front matter, bold syntax, and TODO state corrections to over 70 memex files.
+  - **Project README Enhancements:** Added/updated front matter, fixed formatting, and replaced checkboxes with TODOs in project READMEs, specifically for the Atomic Notes (Zettelkasten) & GTD project.
+  - **Atomic Notes (Zettelkasten) & GTD README Updates:** Incorporated Amr's detailed requirements for collaboration, mobile access, NEXT item promotion logic, org-todo states, and corrected property names (e.g., :ASSIGNEE: to :ASSIGNED:).
+  - **HEARTBEAT.md Update & Project Setup:** Updated HEARTBEAT.md, created new project READMEs, and removed memex/0_inbox files as per Amr's directives.

daily/2026-03-17.org

@@ -0,0 +1,415 @@
+#+TITLE: Daily Log: 2026-03-17
+#+AUTHOR: Amr
+#+CREATED: [2026-03-17 Tue]
+#+BEGIN_COMMENT
+Chronological record of all meetings, fleeting notes, and raw conversation logs from today.
+#+END_COMMENT
+
+* Daily Record
+  - General activity goes here.
+
+* Fleeting Note: Thoughts on Proof of Work vs Stake
+  :PROPERTIES:
+  :ID: 20260317T1100
+  :CREATED: [2026-03-17 Tue 11:00]
+  :END:
+
+  I was reading about blockchain consensus today. Proof of Work uses computational energy as the primary mechanism for Sybil resistance and achieving consensus. Proof of Stake uses capital at risk (staked tokens) to achieve the same goal. It seems like PoW is more fundamentally grounded in physics, while PoS is grounded in economics. I need to explore this more later.
+
+* GTD - Task / Inbox
+  - [ ] Buy milk
+* Captured from memory/2026-03-17.md on 2026-03-20 01:00
+
+:PROPERTIES:
+:CREATED: [2026-03-20 Fri 01:00]
+:END:
+
+## Major System Developments
+
+### Three OpenClaw Skills Deployed
+Created and deployed three integrated skills for the org-agent-memex system:
+- **org-agent-memex-zettlekasten**: Nightly distillation of daily logs into atomic notes
+- **org-agent-memex-gtd**: Automated task promotion and GTD workflow management
+- **org-agent-memex-workbreakdown**: Meta-cognitive skill for task decomposition to prevent context saturation
+
+All skills follow the established pattern: SKILL.md with YAML frontmatter, README.md for users, and integration with the PARA + Atomic Notes (Zettelkasten) + GTD workflow.
+
+### Agora Gap Verification Progress
+Completed comprehensive gap verification:
+- **CRITICAL gaps (4)**: 2 IMPLEMENTED, 2 REAL gaps confirmed
+- **HIGH gaps (15)**: 7 IMPLEMENTED, 3 PARTIAL, 5 REAL
+- **MEDIUM gaps (14)**: 10 verified, 4 deferred pending pressure-testing session
+
+Used sub-agents for parallel verification of HIGH gaps successfully. Sub-agents struggled with MEDIUM gaps due to unclear task boundaries.
+
+### 21-Layer System Audit
+Conducted first comprehensive self-assessment across 21 system layers. Honest grading:
+- **Overall: C+ (70%)**
+- **Strengths**: Git rollback (A-), PARA filing structure (B+), Skills framework (B-)
+- **Critical gaps**: Simulation/sandbox (F), Health/heartbeat automation (D+), Coordination layer (C)
+
+Identified 5 highest-confidence solutions and 4 highest-risk gaps. Awaiting pressure-testing session before building.
+
+### Tool Failure Protocol Established
+After repeated tool syntax errors and gateway restart misuse, formalized the protocol:
+1. READ error message completely
+2. IDENTIFY specific issue
+3. FIX actual syntax problem
+4. RETRY with corrected parameters
+5. ESCALATE only specific error after 2 attempts
+
+Documented in tool_failure_protocol.org (Atomic Notes (Zettelkasten) atomic note, concept-based filename).
+
+### Key Operational Learnings
+- Gateway restarts are for actual service issues, not syntax errors
+- Skills don't automatically replace old habits; must actively consult them
+- Complexity check must be invoked BEFORE execution, not as justification after
+- "What should I do?" is forbidden; use complexity check to decide autonomously
+- Sub-agents successful for parallel HIGH gap verification; MEDIUM gaps need clearer task definition
+
+### Token Usage Reality Check
+685k tokens "in" vs 6.4k "out" (107:1 ratio) revealed unsustainable consumption pattern. Added research task to Infrastructure project for optimization strategies.
+
+### Workflow Integration Success
+Successfully established:
+- Bidirectional linking between GTD.org and 5_projects/*
+- Atomic Atomic Notes (Zettelkasten) notes in memex/2_notes/
+- Clean separation: actionable tasks in GTD, reference material in projects
+- LOGBOOK drawers for state tracking
+- .env-based configuration for portability
+
+### Pattern Recognition Failure
+Despite creating skills explicitly forbidding dated filenames in notes, I created "operational_learnings_2026-03-17.org" before correcting to "tool_failure_protocol.org". Skills don't automatically override habits; active consultation required.
+
+## Status: Session End
+Awaiting pressure-testing session for 21-layer audit assumptions. All building paused until final plan approved.
+
+* Captured from memory/2026-03-17.md on 2026-03-21 01:00
+
+:PROPERTIES:
+:CREATED: [2026-03-21 Sat 01:00]
+:END:
+
+## Major System Developments
+
+### Three OpenClaw Skills Deployed
+Created and deployed three integrated skills for the org-agent-memex system:
+- **org-agent-memex-zettlekasten**: Nightly distillation of daily logs into atomic notes
+- **org-agent-memex-gtd**: Automated task promotion and GTD workflow management
+- **org-agent-memex-workbreakdown**: Meta-cognitive skill for task decomposition to prevent context saturation
+
+All skills follow the established pattern: SKILL.md with YAML frontmatter, README.md for users, and integration with the PARA + Atomic Notes (Zettelkasten) + GTD workflow.
+
+### Agora Gap Verification Progress
+Completed comprehensive gap verification:
+- **CRITICAL gaps (4)**: 2 IMPLEMENTED, 2 REAL gaps confirmed
+- **HIGH gaps (15)**: 7 IMPLEMENTED, 3 PARTIAL, 5 REAL
+- **MEDIUM gaps (14)**: 10 verified, 4 deferred pending pressure-testing session
+
+Used sub-agents for parallel verification of HIGH gaps successfully. Sub-agents struggled with MEDIUM gaps due to unclear task boundaries.
+
+### 21-Layer System Audit
+Conducted first comprehensive self-assessment across 21 system layers. Honest grading:
+- **Overall: C+ (70%)**
+- **Strengths**: Git rollback (A-), PARA filing structure (B+), Skills framework (B-)
+- **Critical gaps**: Simulation/sandbox (F), Health/heartbeat automation (D+), Coordination layer (C)
+
+Identified 5 highest-confidence solutions and 4 highest-risk gaps. Awaiting pressure-testing session before building.
+
+### Tool Failure Protocol Established
+After repeated tool syntax errors and gateway restart misuse, formalized the protocol:
+1. READ error message completely
+2. IDENTIFY specific issue
+3. FIX actual syntax problem
+4. RETRY with corrected parameters
+5. ESCALATE only specific error after 2 attempts
+
+Documented in tool_failure_protocol.org (Atomic Notes (Zettelkasten) atomic note, concept-based filename).
+
+### Key Operational Learnings
+- Gateway restarts are for actual service issues, not syntax errors
+- Skills don't automatically replace old habits; must actively consult them
+- Complexity check must be invoked BEFORE execution, not as justification after
+- "What should I do?" is forbidden; use complexity check to decide autonomously
+- Sub-agents successful for parallel HIGH gap verification; MEDIUM gaps need clearer task definition
+
+### Token Usage Reality Check
+685k tokens "in" vs 6.4k "out" (107:1 ratio) revealed unsustainable consumption pattern. Added research task to Infrastructure project for optimization strategies.
+
+### Workflow Integration Success
+Successfully established:
+- Bidirectional linking between GTD.org and 5_projects/*
+- Atomic Atomic Notes (Zettelkasten) notes in memex/2_notes/
+- Clean separation: actionable tasks in GTD, reference material in projects
+- LOGBOOK drawers for state tracking
+- .env-based configuration for portability
+
+### Pattern Recognition Failure
+Despite creating skills explicitly forbidding dated filenames in notes, I created "operational_learnings_2026-03-17.org" before correcting to "tool_failure_protocol.org". Skills don't automatically override habits; active consultation required.
+
+## Status: Session End
+Awaiting pressure-testing session for 21-layer audit assumptions. All building paused until final plan approved.
+
+* Captured from memory/2026-03-17.md on 2026-03-22 01:00
+
+:PROPERTIES:
+:CREATED: [2026-03-22 Sun 01:00]
+:END:
+
+## Major System Developments
+
+### Three OpenClaw Skills Deployed
+Created and deployed three integrated skills for the org-agent-memex system:
+- **org-agent-memex-zettlekasten**: Nightly distillation of daily logs into atomic notes
+- **org-agent-memex-gtd**: Automated task promotion and GTD workflow management
+- **org-agent-memex-workbreakdown**: Meta-cognitive skill for task decomposition to prevent context saturation
+
+All skills follow the established pattern: SKILL.md with YAML frontmatter, README.md for users, and integration with the PARA + Atomic Notes (Zettelkasten) + GTD workflow.
+
+### Agora Gap Verification Progress
+Completed comprehensive gap verification:
+- **CRITICAL gaps (4)**: 2 IMPLEMENTED, 2 REAL gaps confirmed
+- **HIGH gaps (15)**: 7 IMPLEMENTED, 3 PARTIAL, 5 REAL
+- **MEDIUM gaps (14)**: 10 verified, 4 deferred pending pressure-testing session
+
+Used sub-agents for parallel verification of HIGH gaps successfully. Sub-agents struggled with MEDIUM gaps due to unclear task boundaries.
+
+### 21-Layer System Audit
+Conducted first comprehensive self-assessment across 21 system layers. Honest grading:
+- **Overall: C+ (70%)**
+- **Strengths**: Git rollback (A-), PARA filing structure (B+), Skills framework (B-)
+- **Critical gaps**: Simulation/sandbox (F), Health/heartbeat automation (D+), Coordination layer (C)
+
+Identified 5 highest-confidence solutions and 4 highest-risk gaps. Awaiting pressure-testing session before building.
+
+### Tool Failure Protocol Established
+After repeated tool syntax errors and gateway restart misuse, formalized the protocol:
+1. READ error message completely
+2. IDENTIFY specific issue
+3. FIX actual syntax problem
+4. RETRY with corrected parameters
+5. ESCALATE only specific error after 2 attempts
+
+Documented in tool_failure_protocol.org (Atomic Notes (Zettelkasten) atomic note, concept-based filename).
+
+### Key Operational Learnings
+- Gateway restarts are for actual service issues, not syntax errors
+- Skills don't automatically replace old habits; must actively consult them
+- Complexity check must be invoked BEFORE execution, not as justification after
+- "What should I do?" is forbidden; use complexity check to decide autonomously
+- Sub-agents successful for parallel HIGH gap verification; MEDIUM gaps need clearer task definition
+
+### Token Usage Reality Check
+685k tokens "in" vs 6.4k "out" (107:1 ratio) revealed unsustainable consumption pattern. Added research task to Infrastructure project for optimization strategies.
+
+### Workflow Integration Success
+Successfully established:
+- Bidirectional linking between GTD.org and 5_projects/*
+- Atomic Atomic Notes (Zettelkasten) notes in memex/2_notes/
+- Clean separation: actionable tasks in GTD, reference material in projects
+- LOGBOOK drawers for state tracking
+- .env-based configuration for portability
+
+### Pattern Recognition Failure
+Despite creating skills explicitly forbidding dated filenames in notes, I created "operational_learnings_2026-03-17.org" before correcting to "tool_failure_protocol.org". Skills don't automatically override habits; active consultation required.
+
+## Status: Session End
+Awaiting pressure-testing session for 21-layer audit assumptions. All building paused until final plan approved.
+
+* Captured from memory/2026-03-17.md on 2026-03-23 01:00
+
+:PROPERTIES:
+:CREATED: [2026-03-23 Mon 01:00]
+:END:
+
+## Major System Developments
+
+### Three OpenClaw Skills Deployed
+Created and deployed three integrated skills for the org-agent-memex system:
+- **org-agent-memex-zettlekasten**: Nightly distillation of daily logs into atomic notes
+- **org-agent-memex-gtd**: Automated task promotion and GTD workflow management
+- **org-agent-memex-workbreakdown**: Meta-cognitive skill for task decomposition to prevent context saturation
+
+All skills follow the established pattern: SKILL.md with YAML frontmatter, README.md for users, and integration with the PARA + Atomic Notes (Zettelkasten) + GTD workflow.
+
+### Agora Gap Verification Progress
+Completed comprehensive gap verification:
+- **CRITICAL gaps (4)**: 2 IMPLEMENTED, 2 REAL gaps confirmed
+- **HIGH gaps (15)**: 7 IMPLEMENTED, 3 PARTIAL, 5 REAL
+- **MEDIUM gaps (14)**: 10 verified, 4 deferred pending pressure-testing session
+
+Used sub-agents for parallel verification of HIGH gaps successfully. Sub-agents struggled with MEDIUM gaps due to unclear task boundaries.
+
+### 21-Layer System Audit
+Conducted first comprehensive self-assessment across 21 system layers. Honest grading:
+- **Overall: C+ (70%)**
+- **Strengths**: Git rollback (A-), PARA filing structure (B+), Skills framework (B-)
+- **Critical gaps**: Simulation/sandbox (F), Health/heartbeat automation (D+), Coordination layer (C)
+
+Identified 5 highest-confidence solutions and 4 highest-risk gaps. Awaiting pressure-testing session before building.
+
+### Tool Failure Protocol Established
+After repeated tool syntax errors and gateway restart misuse, formalized the protocol:
+1. READ error message completely
+2. IDENTIFY specific issue
+3. FIX actual syntax problem
+4. RETRY with corrected parameters
+5. ESCALATE only specific error after 2 attempts
+
+Documented in tool_failure_protocol.org (Atomic Notes (Zettelkasten) atomic note, concept-based filename).
+
+### Key Operational Learnings
+- Gateway restarts are for actual service issues, not syntax errors
+- Skills don't automatically replace old habits; must actively consult them
+- Complexity check must be invoked BEFORE execution, not as justification after
+- "What should I do?" is forbidden; use complexity check to decide autonomously
+- Sub-agents successful for parallel HIGH gap verification; MEDIUM gaps need clearer task definition
+
+### Token Usage Reality Check
+685k tokens "in" vs 6.4k "out" (107:1 ratio) revealed unsustainable consumption pattern. Added research task to Infrastructure project for optimization strategies.
+
+### Workflow Integration Success
+Successfully established:
+- Bidirectional linking between GTD.org and 5_projects/*
+- Atomic Atomic Notes (Zettelkasten) notes in memex/2_notes/
+- Clean separation: actionable tasks in GTD, reference material in projects
+- LOGBOOK drawers for state tracking
+- .env-based configuration for portability
+
+### Pattern Recognition Failure
+Despite creating skills explicitly forbidding dated filenames in notes, I created "operational_learnings_2026-03-17.org" before correcting to "tool_failure_protocol.org". Skills don't automatically override habits; active consultation required.
+
+## Status: Session End
+Awaiting pressure-testing session for 21-layer audit assumptions. All building paused until final plan approved.
+
+* Captured from memory/2026-03-17.md on 2026-03-25 01:01
+
+:PROPERTIES:
+:CREATED: [2026-03-25 Wed 01:01]
+:END:
+
+## Major System Developments
+
+### Three OpenClaw Skills Deployed
+Created and deployed three integrated skills for the org-agent-memex system:
+- **org-agent-memex-zettlekasten**: Nightly distillation of daily logs into atomic notes
+- **org-agent-memex-gtd**: Automated task promotion and GTD workflow management
+- **org-agent-memex-workbreakdown**: Meta-cognitive skill for task decomposition to prevent context saturation
+
+All skills follow the established pattern: SKILL.md with YAML frontmatter, README.md for users, and integration with the PARA + Zettelkasten + GTD workflow.
+
+### Agora Gap Verification Progress
+Completed comprehensive gap verification:
+- **CRITICAL gaps (4)**: 2 IMPLEMENTED, 2 REAL gaps confirmed
+- **HIGH gaps (15)**: 7 IMPLEMENTED, 3 PARTIAL, 5 REAL
+- **MEDIUM gaps (14)**: 10 verified, 4 deferred pending pressure-testing session
+
+Used sub-agents for parallel verification of HIGH gaps successfully. Sub-agents struggled with MEDIUM gaps due to unclear task boundaries.
+
+### 21-Layer System Audit
+Conducted first comprehensive self-assessment across 21 system layers. Honest grading:
+- **Overall: C+ (70%)**
+- **Strengths**: Git rollback (A-), PARA filing structure (B+), Skills framework (B-)
+- **Critical gaps**: Simulation/sandbox (F), Health/heartbeat automation (D+), Coordination layer (C)
+
+Identified 5 highest-confidence solutions and 4 highest-risk gaps. Awaiting pressure-testing session before building.
+
+### Tool Failure Protocol Established
+After repeated tool syntax errors and gateway restart misuse, formalized the protocol:
+1. READ error message completely
+2. IDENTIFY specific issue
+3. FIX actual syntax problem
+4. RETRY with corrected parameters
+5. ESCALATE only specific error after 2 attempts
+
+Documented in tool_failure_protocol.org (Zettelkasten atomic note, concept-based filename).
+
+### Key Operational Learnings
+- Gateway restarts are for actual service issues, not syntax errors
+- Skills don't automatically replace old habits; must actively consult them
+- Complexity check must be invoked BEFORE execution, not as justification after
+- "What should I do?" is forbidden; use complexity check to decide autonomously
+- Sub-agents successful for parallel HIGH gap verification; MEDIUM gaps need clearer task definition
+
+### Token Usage Reality Check
+685k tokens "in" vs 6.4k "out" (107:1 ratio) revealed unsustainable consumption pattern. Added research task to Infrastructure project for optimization strategies.
+
+### Workflow Integration Success
+Successfully established:
+- Bidirectional linking between GTD.org and 5_projects/*
+- Atomic Zettelkasten notes in memex/2_notes/
+- Clean separation: actionable tasks in GTD, reference material in projects
+- LOGBOOK drawers for state tracking
+- .env-based configuration for portability
+
+### Pattern Recognition Failure
+Despite creating skills explicitly forbidding dated filenames in notes, I created "operational_learnings_2026-03-17.org" before correcting to "tool_failure_protocol.org". Skills don't automatically override habits; active consultation required.
+
+## Status: Session End
+Awaiting pressure-testing session for 21-layer audit assumptions. All building paused until final plan approved.
+
+* Captured from memory/2026-03-17.md on 2026-03-26 01:00
+
+:PROPERTIES:
+:CREATED: [2026-03-26 Thu 01:00]
+:END:
+
+## Major System Developments
+
+### Three OpenClaw Skills Deployed
+Created and deployed three integrated skills for the org-agent-memex system:
+- **org-agent-memex-zettlekasten**: Nightly distillation of daily logs into atomic notes
+- **org-agent-memex-gtd**: Automated task promotion and GTD workflow management
+- **org-agent-memex-workbreakdown**: Meta-cognitive skill for task decomposition to prevent context saturation
+
+All skills follow the established pattern: SKILL.md with YAML frontmatter, README.md for users, and integration with the PARA + Zettelkasten + GTD workflow.
+
+### Agora Gap Verification Progress
+Completed comprehensive gap verification:
+- **CRITICAL gaps (4)**: 2 IMPLEMENTED, 2 REAL gaps confirmed
+- **HIGH gaps (15)**: 7 IMPLEMENTED, 3 PARTIAL, 5 REAL
+- **MEDIUM gaps (14)**: 10 verified, 4 deferred pending pressure-testing session
+
+Used sub-agents for parallel verification of HIGH gaps successfully. Sub-agents struggled with MEDIUM gaps due to unclear task boundaries.
+
+### 21-Layer System Audit
+Conducted first comprehensive self-assessment across 21 system layers. Honest grading:
+- **Overall: C+ (70%)**
+- **Strengths**: Git rollback (A-), PARA filing structure (B+), Skills framework (B-)
+- **Critical gaps**: Simulation/sandbox (F), Health/heartbeat automation (D+), Coordination layer (C)
+
+Identified 5 highest-confidence solutions and 4 highest-risk gaps. Awaiting pressure-testing session before building.
+
+### Tool Failure Protocol Established
+After repeated tool syntax errors and gateway restart misuse, formalized the protocol:
+1. READ error message completely
+2. IDENTIFY specific issue
+3. FIX actual syntax problem
+4. RETRY with corrected parameters
+5. ESCALATE only specific error after 2 attempts
+
+Documented in tool_failure_protocol.org (Zettelkasten atomic note, concept-based filename).
+
+### Key Operational Learnings
+- Gateway restarts are for actual service issues, not syntax errors
+- Skills don't automatically replace old habits; must actively consult them
+- Complexity check must be invoked BEFORE execution, not as justification after
+- "What should I do?" is forbidden; use complexity check to decide autonomously
+- Sub-agents successful for parallel HIGH gap verification; MEDIUM gaps need clearer task definition
+
+### Token Usage Reality Check
+685k tokens "in" vs 6.4k "out" (107:1 ratio) revealed unsustainable consumption pattern. Added research task to Infrastructure project for optimization strategies.
+
+### Workflow Integration Success
+Successfully established:
+- Bidirectional linking between GTD.org and 5_projects/*
+- Atomic Zettelkasten notes in memex/2_notes/
+- Clean separation: actionable tasks in GTD, reference material in projects
+- LOGBOOK drawers for state tracking
+- .env-based configuration for portability
+
+### Pattern Recognition Failure
+Despite creating skills explicitly forbidding dated filenames in notes, I created "operational_learnings_2026-03-17.org" before correcting to "tool_failure_protocol.org". Skills don't automatically override habits; active consultation required.
+
+## Status: Session End
+Awaiting pressure-testing session for 21-layer audit assumptions. All building paused until final plan approved.

daily/2026-03-18.org

@@ -0,0 +1,84 @@
+* 2026-03-18 Wednesday
+
+** Fleeting Notes
+- No explicit notes were captured today.
+- Automatically generated due to missing daily log, as per AGENTS.md resilience ritual.
+
+** Completed Tasks (derived from git commits)
+- Removed misplaced sections from Identity doc (a4f5c34)
+- Added Lightning Node Architecture section to Exchange doc (1f35d50)
+- Unified PDS content: Migration and Sync now under PDS section (8a724b1)
+- Cleaned up Infrastructure doc: removed duplicates, reorganized sections (25f8924)
+- Fixed identity organization: restored cryptographic sections to Identity (1c4024e)
+- Removed empty ** Personas heading (7938b9c)
+- Removed stray artifact file functions.exec:337 (179c4ce)
+- Restructured Identity docs: merged Social Recovery, moved contracts to Public Space (bb9c9cf)
+- Reorganized identity requirements under Master Key and Personas groupings (eff39d3)
+- Refactored: integrated standalone gap specs into requirements files and deleted gap files (8cfa675)
+- Chore: removed completed Agora gap analysis file (17c8fb0)
+- Docs: resolved all 45 Agora specification gaps across CRITICAL, HIGH, MEDIUM, and LOW priorities (95c84d6)
+* Captured from memory/2026-03-18.md on 2026-03-20 01:00
+
+:PROPERTIES:
+:CREATED: [2026-03-20 Fri 01:00]
+:END:
+## 2026-03-18
+- Completed 100% of the Agora protocol specification gaps (45 gaps total: 6 CRITICAL, 15 HIGH, 14 MEDIUM, 10 LOW).
+- Created new specifications: `agora-contract-versioning.org` and `agora-cryptographic-specification.org`.
+- Assisted user with UniFi Object-Oriented Networking (OON) to configure a "Local" firewall rule under the "Secure" action, successfully enabling personal devices on the Family VLAN to access a printer on the IoT VLAN.
+- Confirmed the Emacs project directory is named `dotemacs` (previously `emacs_setup`).
+
+* Captured from memory/2026-03-18.md on 2026-03-21 01:00
+
+:PROPERTIES:
+:CREATED: [2026-03-21 Sat 01:00]
+:END:
+## 2026-03-18
+- Completed 100% of the Agora protocol specification gaps (45 gaps total: 6 CRITICAL, 15 HIGH, 14 MEDIUM, 10 LOW).
+- Created new specifications: `agora-contract-versioning.org` and `agora-cryptographic-specification.org`.
+- Assisted user with UniFi Object-Oriented Networking (OON) to configure a "Local" firewall rule under the "Secure" action, successfully enabling personal devices on the Family VLAN to access a printer on the IoT VLAN.
+- Confirmed the Emacs project directory is named `dotemacs` (previously `emacs_setup`).
+
+* Captured from memory/2026-03-18.md on 2026-03-22 01:00
+
+:PROPERTIES:
+:CREATED: [2026-03-22 Sun 01:00]
+:END:
+## 2026-03-18
+- Completed 100% of the Agora protocol specification gaps (45 gaps total: 6 CRITICAL, 15 HIGH, 14 MEDIUM, 10 LOW).
+- Created new specifications: `agora-contract-versioning.org` and `agora-cryptographic-specification.org`.
+- Assisted user with UniFi Object-Oriented Networking (OON) to configure a "Local" firewall rule under the "Secure" action, successfully enabling personal devices on the Family VLAN to access a printer on the IoT VLAN.
+- Confirmed the Emacs project directory is named `dotemacs` (previously `emacs_setup`).
+
+* Captured from memory/2026-03-18.md on 2026-03-23 01:00
+
+:PROPERTIES:
+:CREATED: [2026-03-23 Mon 01:00]
+:END:
+## 2026-03-18
+- Completed 100% of the Agora protocol specification gaps (45 gaps total: 6 CRITICAL, 15 HIGH, 14 MEDIUM, 10 LOW).
+- Created new specifications: `agora-contract-versioning.org` and `agora-cryptographic-specification.org`.
+- Assisted user with UniFi Object-Oriented Networking (OON) to configure a "Local" firewall rule under the "Secure" action, successfully enabling personal devices on the Family VLAN to access a printer on the IoT VLAN.
+- Confirmed the Emacs project directory is named `dotemacs` (previously `emacs_setup`).
+
+* Captured from memory/2026-03-18.md on 2026-03-25 01:01
+
+:PROPERTIES:
+:CREATED: [2026-03-25 Wed 01:01]
+:END:
+## 2026-03-18
+- Completed 100% of the Agora protocol specification gaps (45 gaps total: 6 CRITICAL, 15 HIGH, 14 MEDIUM, 10 LOW).
+- Created new specifications: `agora-contract-versioning.org` and `agora-cryptographic-specification.org`.
+- Assisted user with UniFi Object-Oriented Networking (OON) to configure a "Local" firewall rule under the "Secure" action, successfully enabling personal devices on the Family VLAN to access a printer on the IoT VLAN.
+- Confirmed the Emacs project directory is named `dotemacs` (previously `emacs_setup`).
+
+* Captured from memory/2026-03-18.md on 2026-03-26 01:00
+
+:PROPERTIES:
+:CREATED: [2026-03-26 Thu 01:00]
+:END:
+## 2026-03-18
+- Completed 100% of the Agora protocol specification gaps (45 gaps total: 6 CRITICAL, 15 HIGH, 14 MEDIUM, 10 LOW).
+- Created new specifications: `agora-contract-versioning.org` and `agora-cryptographic-specification.org`.
+- Assisted user with UniFi Object-Oriented Networking (OON) to configure a "Local" firewall rule under the "Secure" action, successfully enabling personal devices on the Family VLAN to access a printer on the IoT VLAN.
+- Confirmed the Emacs project directory is named `dotemacs` (previously `emacs_setup`).

daily/2026-03-21.org

@@ -0,0 +1,135 @@
+* Session Summary: 2026-03-21
+:PROPERTIES:
+:CREATED: [2026-03-22 Sun 01:00]
+:END:
+* Captured from memory/2026-03-21.md on 2026-03-22 01:00
+
+### Key Discussions & Decisions:
+- **Agora Documentation Refinements:**
+    - **Identity (`agora-requirements-02-identity.org`):**
+        - Clarified Master Key usage for Persona derivation vs. Persona actions (signing contracts, being founders/guardians). Master Key for derivation; Persona keys for actions.
+        - Updated analogy from "Ft. Knox for your keys" to "Sphinx for your keys".
+        - Enhanced "Persona as legal person" analogy to include explicit protected rights (freedom of speech, due process).
+    - **Primitives (`agora-requirements-04-the-primitive.org`):**
+        - **Simplified Content Flags:** Drastically reduced core flags to 12: `is_public`, `is_direct`, `is_aggregated`, `is_contract`, `is_ephemeral`, `is_task`, `is_file`, `threaded`, `indexable`, `is_invoice`, `is_payment`, `is_escrow`.
+        - Eliminated redundant flags: `is_private` (covered by `is_public: false`), `is_page`/`is_static` (covered by `is_aggregated: false`), `is_attestation`, `is_question`, `is_review`, `is_offer`, `paywalled` (all derived semantically via core flags, `references` field, and payload content).
+        - **"Boosts" implemented as "Quote Notes":** Introduced `is_quote` flag and `quoted_cid` field in the Note structure to enable re-sharing with commentary.
+    - **Social & Contracts (`agora-requirements-05-social-and-contracts.org`):**
+        - **Social Note Backups documented as "Supporter Backup Contracts":** A new contract type formalizing an agreement for a Supporter Persona to mirror a Publisher Persona's Notes for redundancy.
+
+### Operational Highlights & Tooling Challenges:
+- **Security Hardening:**
+    - UFW installed and enabled.
+    - `journalctl` access for system logs verified after `sudoers` configuration.
+    - Exposed Docker ports (gitea: 2222, 3000; openclaw-chromium: 9222) initially denied by UFW.
+    - Port 2222 re-opened at user's request for Gitea SSH access.
+- **`edit` Tool Limitations:** Faced repeated `edit` tool failures due to strict `oldText` matching requirements with Org-mode's complex formatting (especially tables and invisible characters). This led to reliance on read-modify-write strategy for large updates.
+- **`org-json-bridge` Project Initiated:** Began developing `org-json-bridge` skill to overcome `edit` tool limitations by enabling programmatic Org-mode manipulation via JSON parsing/serialization.
+
+### Scheduled Tasks:
+- **Overnight Documentation Improvement:** A sub-agent was launched to review and improve Agora requirements files 1-5, focusing on consistency, clarity, subheader logic, and removal of duplication/redundancies. Results expected in the morning.
+
+### Open Questions:
+- User is considering further flag reductions (`is_escrow`, `is_payment`, `is_invoice`, `is_file`, `is_task`, `is_contract`). This will be revisited in the morning.
+
+* Captured from memory/2026-03-21.md on 2026-03-23 01:00
+
+:PROPERTIES:
+:CREATED: [2026-03-23 Mon 01:00]
+:END:
+
+### Key Discussions & Decisions:
+- **Agora Documentation Refinements:**
+    - **Identity (`agora-requirements-02-identity.org`):**
+        - Clarified Master Key usage for Persona derivation vs. Persona actions (signing contracts, being founders/guardians). Master Key for derivation; Persona keys for actions.
+        - Updated analogy from "Ft. Knox for your keys" to "Sphinx for your keys".
+        - Enhanced "Persona as legal person" analogy to include explicit protected rights (freedom of speech, due process).
+    - **Primitives (`agora-requirements-04-the-primitive.org`):**
+        - **Simplified Content Flags:** Drastically reduced core flags to 12: `is_public`, `is_direct`, `is_aggregated`, `is_contract`, `is_ephemeral`, `is_task`, `is_file`, `threaded`, `indexable`, `is_invoice`, `is_payment`, `is_escrow`.
+        - Eliminated redundant flags: `is_private` (covered by `is_public: false`), `is_page`/`is_static` (covered by `is_aggregated: false`), `is_attestation`, `is_question`, `is_review`, `is_offer`, `paywalled` (all derived semantically via core flags, `references` field, and payload content).
+        - **"Boosts" implemented as "Quote Notes":** Introduced `is_quote` flag and `quoted_cid` field in the Note structure to enable re-sharing with commentary.
+    - **Social & Contracts (`agora-requirements-05-social-and-contracts.org`):**
+        - **Social Note Backups documented as "Supporter Backup Contracts":** A new contract type formalizing an agreement for a Supporter Persona to mirror a Publisher Persona's Notes for redundancy.
+
+### Operational Highlights & Tooling Challenges:
+- **Security Hardening:**
+    - UFW installed and enabled.
+    - `journalctl` access for system logs verified after `sudoers` configuration.
+    - Exposed Docker ports (gitea: 2222, 3000; openclaw-chromium: 9222) initially denied by UFW.
+    - Port 2222 re-opened at user's request for Gitea SSH access.
+- **`edit` Tool Limitations:** Faced repeated `edit` tool failures due to strict `oldText` matching requirements with Org-mode's complex formatting (especially tables and invisible characters). This led to reliance on read-modify-write strategy for large updates.
+- **`org-json-bridge` Project Initiated:** Began developing `org-json-bridge` skill to overcome `edit` tool limitations by enabling programmatic Org-mode manipulation via JSON parsing/serialization.
+
+### Scheduled Tasks:
+- **Overnight Documentation Improvement:** A sub-agent was launched to review and improve Agora requirements files 1-5, focusing on consistency, clarity, subheader logic, and removal of duplication/redundancies. Results expected in the morning.
+
+### Open Questions:
+- User is considering further flag reductions (`is_escrow`, `is_payment`, `is_invoice`, `is_file`, `is_task`, `is_contract`). This will be revisited in the morning.
+
+* Captured from memory/2026-03-21.md on 2026-03-25 01:01
+
+:PROPERTIES:
+:CREATED: [2026-03-25 Wed 01:01]
+:END:
+
+### Key Discussions & Decisions:
+- **Agora Documentation Refinements:**
+    - **Identity (`agora-requirements-02-identity.org`):**
+        - Clarified Master Key usage for Persona derivation vs. Persona actions (signing contracts, being founders/guardians). Master Key for derivation; Persona keys for actions.
+        - Updated analogy from "Ft. Knox for your keys" to "Sphinx for your keys".
+        - Enhanced "Persona as legal person" analogy to include explicit protected rights (freedom of speech, due process).
+    - **Primitives (`agora-requirements-04-the-primitive.org`):**
+        - **Simplified Content Flags:** Drastically reduced core flags to 12: `is_public`, `is_direct`, `is_aggregated`, `is_contract`, `is_ephemeral`, `is_task`, `is_file`, `threaded`, `indexable`, `is_invoice`, `is_payment`, `is_escrow`.
+        - Eliminated redundant flags: `is_private` (covered by `is_public: false`), `is_page`/`is_static` (covered by `is_aggregated: false`), `is_attestation`, `is_question`, `is_review`, `is_offer`, `paywalled` (all derived semantically via core flags, `references` field, and payload content).
+        - **"Boosts" implemented as "Quote Notes":** Introduced `is_quote` flag and `quoted_cid` field in the Note structure to enable re-sharing with commentary.
+    - **Social & Contracts (`agora-requirements-05-social-and-contracts.org`):**
+        - **Social Note Backups documented as "Supporter Backup Contracts":** A new contract type formalizing an agreement for a Supporter Persona to mirror a Publisher Persona's Notes for redundancy.
+
+### Operational Highlights & Tooling Challenges:
+- **Security Hardening:**
+    - UFW installed and enabled.
+    - `journalctl` access for system logs verified after `sudoers` configuration.
+    - Exposed Docker ports (gitea: 2222, 3000; openclaw-chromium: 9222) initially denied by UFW.
+    - Port 2222 re-opened at user's request for Gitea SSH access.
+- **`edit` Tool Limitations:** Faced repeated `edit` tool failures due to strict `oldText` matching requirements with Org-mode's complex formatting (especially tables and invisible characters). This led to reliance on read-modify-write strategy for large updates.
+- **`org-json-bridge` Project Initiated:** Began developing `org-json-bridge` skill to overcome `edit` tool limitations by enabling programmatic Org-mode manipulation via JSON parsing/serialization.
+
+### Scheduled Tasks:
+- **Overnight Documentation Improvement:** A sub-agent was launched to review and improve Agora requirements files 1-5, focusing on consistency, clarity, subheader logic, and removal of duplication/redundancies. Results expected in the morning.
+
+### Open Questions:
+- User is considering further flag reductions (`is_escrow`, `is_payment`, `is_invoice`, `is_file`, `is_task`, `is_contract`). This will be revisited in the morning.
+
+* Captured from memory/2026-03-21.md on 2026-03-26 01:00
+
+:PROPERTIES:
+:CREATED: [2026-03-26 Thu 01:00]
+:END:
+
+### Key Discussions & Decisions:
+- **Agora Documentation Refinements:**
+    - **Identity (`agora-requirements-02-identity.org`):**
+        - Clarified Master Key usage for Persona derivation vs. Persona actions (signing contracts, being founders/guardians). Master Key for derivation; Persona keys for actions.
+        - Updated analogy from "Ft. Knox for your keys" to "Sphinx for your keys".
+        - Enhanced "Persona as legal person" analogy to include explicit protected rights (freedom of speech, due process).
+    - **Primitives (`agora-requirements-04-the-primitive.org`):**
+        - **Simplified Content Flags:** Drastically reduced core flags to 12: `is_public`, `is_direct`, `is_aggregated`, `is_contract`, `is_ephemeral`, `is_task`, `is_file`, `threaded`, `indexable`, `is_invoice`, `is_payment`, `is_escrow`.
+        - Eliminated redundant flags: `is_private` (covered by `is_public: false`), `is_page`/`is_static` (covered by `is_aggregated: false`), `is_attestation`, `is_question`, `is_review`, `is_offer`, `paywalled` (all derived semantically via core flags, `references` field, and payload content).
+        - **"Boosts" implemented as "Quote Notes":** Introduced `is_quote` flag and `quoted_cid` field in the Note structure to enable re-sharing with commentary.
+    - **Social & Contracts (`agora-requirements-05-social-and-contracts.org`):**
+        - **Social Note Backups documented as "Supporter Backup Contracts":** A new contract type formalizing an agreement for a Supporter Persona to mirror a Publisher Persona's Notes for redundancy.
+
+### Operational Highlights & Tooling Challenges:
+- **Security Hardening:**
+    - UFW installed and enabled.
+    - `journalctl` access for system logs verified after `sudoers` configuration.
+    - Exposed Docker ports (gitea: 2222, 3000; openclaw-chromium: 9222) initially denied by UFW.
+    - Port 2222 re-opened at user's request for Gitea SSH access.
+- **`edit` Tool Limitations:** Faced repeated `edit` tool failures due to strict `oldText` matching requirements with Org-mode's complex formatting (especially tables and invisible characters). This led to reliance on read-modify-write strategy for large updates.
+- **`org-json-bridge` Project Initiated:** Began developing `org-json-bridge` skill to overcome `edit` tool limitations by enabling programmatic Org-mode manipulation via JSON parsing/serialization.
+
+### Scheduled Tasks:
+- **Overnight Documentation Improvement:** A sub-agent was launched to review and improve Agora requirements files 1-5, focusing on consistency, clarity, subheader logic, and removal of duplication/redundancies. Results expected in the morning.
+
+### Open Questions:
+- User is considering further flag reductions (`is_escrow`, `is_payment`, `is_invoice`, `is_file`, `is_task`, `is_contract`). This will be revisited in the morning.

daily/2026-03-22.org

@@ -0,0 +1,50 @@
+#+TITLE: 2026-03-22 (Sunday)
+#+DATE: [2026-03-22 Sun]
+#+FILETAGS: :daily:openclaw:emacs:gtd:
+
+* Activities
+** OpenClaw Resilience and Memory Restoration
+- **Problem:** Agent suffered from "context amnesia" after a session reset at 08:10 AM, losing the path to `emacs.org` and failing to rediscover it.
+- **Root Cause:** Search depth was too shallow (workspace root only), and the `org-agent-memex-gtd` skill was not in the executable skills directory.
+- **Resolution:**
+  - Identified canonical path: `/home/amr/.openclaw/workspace/memex/5_projects/dotemacs/emacs.org`.
+  - Restored skills by copying `org-agent-memex-gtd`, `org-agent-memex-workbreakdown`, and `org-agent-memex-zettlekasten` to standard `.openclaw/skills/` directory.
+  - Synced `GTD.org` and `memex/gtd.org` to ensure "Ground Truth" is consistent.
+
+** Emacs Configuration Modularization
+- **Action:** Refactored the monolithic `emacs.org` into a modern modular system.
+- **New Structure:**
+  - `dotemacs.org`: Master orchestrator and bootstrap.
+  - `modules/emacs-core.org`: Straight.el, server, performance.
+  - `modules/emacs-ui.org`: Appearance, org-modern.
+  - `modules/emacs-org.org`: Core Org, Agenda, Capture.
+  - `modules/emacs-gtd.org`: Org-GTD specifics.
+  - `modules/emacs-roam.org`: Org-roam and Atomic Notes (Zettelkasten).
+  - `modules/emacs-writing.org`: Spellcheck, flycheck, text modes.
+  - `modules/emacs-media.org`: calibredb, nov.el, org-noter.
+  - `modules/emacs-ai.org`: ellama and providers.
+  - `modules/emacs-shell.org`: Bash/Eshell integration.
+- **Standard:** Documented modularity as the new standard in `SOUL.md`.
+
+** org-json-bridge Enhancement
+- **Action:** Verified and improved the Org-to-JSON bridge for programmatic manipulation.
+- **Improvement:** Refactored `org-json-bridge.el` with a recursive cleaning function to ensure 100% JSON-serializable output of the Org AST.
+- **Verification:** Successfully tested parsing of `inbox.org` via the Python CLI.
+
+** Task Management Standard
+- **Change:** Migrated `GTD.org` from simple checkmarks `[ ]` to proper Org-mode `TODO`/`NEXT` headings.
+- **Rationale:** Enables the `org-gtd` skill to programmatically promote and track tasks.
+- **Persistence:** Encoded this as a "Permanent Learning" in `SOUL.md`.
+
+** Security Hardening and Audit
+- **Action:** Addressed critical vulnerabilities from 2026-03-13 audit.
+- **Improvements:**
+  - Hardened Docker port bindings for Chromium, Gitea, and GitLab (now bound to `127.0.0.1` instead of `0.0.0.0`).
+  - Drafted manual `sudo` commands for UFW activation and system log access.
+- **Result:** Minimized network attack surface for infrastructure services.
+
+* Logs
+- [10:45] Shifted focus from Security Audit back to Emacs Refactor to address memory restoration.
+- [11:15] Completed modular split of emacs.org.
+- [11:45] Verified org-json-bridge functionality with new Emacs installation.
+- [14:30] Implemented Docker port hardening across all active services.

daily/README.org

@@ -0,0 +1,9 @@
+#+TITLE: daily: The Immutable Log
+#+AUTHOR: Amr
+#+CREATED: [2026-03-17 Tue]
+#+BEGIN_COMMENT
+Chronological daily logs (YYYY-MM-DD.org) serving as the primary capture location for fleeting notes and daily events. These are immutable records.
+#+END_COMMENT
+
+* daily: The Immutable Log
+Chronological daily logs (YYYY-MM-DD.org) serving as the primary capture location for fleeting notes and daily events. These are immutable records.

gtd.org

@@ -0,0 +1,686 @@
+#+TITLE: Amero GTD
+#+author: Amero Garcia
+#+created: [2026-03-16 Mon 14:28]
+#+DATE: 2026-03-11
+#+STARTUP: content
+#+FILETAGS: :GTD:
+
+* Actions
+:PROPERTIES:
+:ID:       gtd-actions
+:END:
+
+* Projects
+:PROPERTIES:
+:ID:       gtd-projects
+:END:
+
+** Agora: Decentralized Social Network
+:PROPERTIES:
+:ID:       agora-project
+:END:
+
+*** DONE Create atomic notes for all 10 Agora sections
+:PROPERTIES:
+:CREATED:  [2026-03-16 Mon 14:28]
+:END:
+:LOGBOOK:
+- State "DONE" from "TODO" [2026-03-17 Tue 12:00]
+:END:
+
+All 14 atomic notes created and cross-referenced.
+
+*** IN-PROGRESS Fill CRITICAL and HIGH gaps [5 CRITICAL / 15 HIGH complete]
+**** DONE Section 02: Identity - ALL HIGH priority gaps resolved
+**** DONE Section 03: Infrastructure - ALL HIGH priority gaps resolved
+*** IN-PROGRESS Fill MEDIUM gaps [14/14 complete]
+**** DONE ALL MEDIUM PRIORITY GAPS RESOLVED
+**** DONE ALL LOW PRIORITY GAPS RESOLVED (10/10)
+**** FINAL STATUS: All Agora specification gaps complete (CRITICAL, HIGH, MEDIUM, LOW)
+:PROPERTIES:
+:CREATED: [2026-03-17 Tue 23:30]
+:END:
+:LOGBOOK:
+- State "IN-PROGRESS" from "TODO" [2026-03-18 Wed 01:00]
+:END:
+
+**** DONE CRITICAL: Contract TypeScript/Protobuf Interfaces → FILLED
+:PROPERTIES:
+:CREATED: [2026-03-18 Wed 01:00]
+:END:
+:LOGBOOK:
+- State "DONE" from "TODO" [2026-03-18 Wed 01:15]
+:END:
+- INTEGRATED: Reference added to agora-requirements-02-identity.org
+- LOCATION: memex/5_projects/agora/agora-contract-schemas.org
+
+**** DONE CRITICAL: Content Flag Schema Validation → FILLED
+:PROPERTIES:
+:CREATED: [2026-03-18 Wed 01:00]
+:END:
+:LOGBOOK:
+- State "DONE" from "TODO" [2026-03-18 Wed 01:25]
+:END:
+- LOCATION: memex/5_projects/agora/agora-content-flag-schema.org
+- PENDING: Integration into agora-requirements-04-the-primitive.org
+
+**** DONE CRITICAL: PDS-to-PDS Sync Protocol → FILLED
+:PROPERTIES:
+:CREATED: [2026-03-18 Wed 01:00]
+:END:
+:LOGBOOK:
+- State "DONE" from "TODO" [2026-03-18 Wed 01:35]
+:END:
+- LOCATION: memex/5_projects/agora/agora-pds-sync-protocol.org
+- PENDING: Integration into agora-requirements-03-infrastructure.org
+
+**** DONE CRITICAL: Delta Sync Protocol → FILLED
+:PROPERTIES:
+:CREATED: [2026-03-18 Wed 01:00]
+:END:
+:LOGBOOK:
+- State "DONE" from "TODO" [2026-03-18 Wed 01:50]
+:END:
+- LOCATION: memex/5_projects/agora/agora-delta-sync-protocol.org
+- PENDING: Integration into agora-requirements-08-implementation.org
+
+**** DONE CRITICAL: Persona Revocation Protocol → ALREADY-EXISTS
+:PROPERTIES:
+:CREATED: [2026-03-18 Wed 01:00]
+:END:
+:LOGBOOK:
+- State "DONE" from "TODO" [2026-03-18 Wed 02:00]
+:END:
+- NOTE: Complete specification already in agora-requirements-02-identity.org
+- ACTION: Gap was incorrectly flagged; no work required
+
+**** TODO INTEGRATE scattered specifications into requirements files [1/4]
+:PROPERTIES:
+:CREATED: [2026-03-18 Wed 02:00]
+:END:
+
+- NEXT: Move content flag schema into Section 04
+- NEXT: Move PDS sync into Section 03
+- NEXT: Move delta sync into Section 08
+- NEXT: Delete duplicate documents after integration
+
+**** NEXT Fill HIGH priority gaps
+:PROPERTIES:
+:CREATED: [2026-03-18 Wed 02:00]
+:END:
+
+- Relay Discovery Mechanism (Section 03)
+- Relay Pricing Logic (Section 03)
+- Shamir's Parameters (Section 03)
+
+** Emacs Configuration Refactor
+:PROPERTIES:
+:ID:       emacs-config-refactor
+:CREATED:  [2026-03-22 Sun 08:00]
+:END:
+
+Modularize the monolithic emacs.org into smaller, function-specific files.
+
+*** NEXT Obtain exact file path of Emacs configuration file
+:PROPERTIES:
+:CREATED: [2026-03-22 Sun 08:00]
+:ASSIGNED: Agent
+:END:
+
+The exact path is: `/home/amr/.openclaw/workspace/memex/5_projects/dotemacs/emacs.org`
+
+*** TODO Split emacs.org into functional modules (packages, UI, GTD, etc.)
+:PROPERTIES:
+:CREATED: [2026-03-22 Sun 08:00]
+:END:
+
+** OpenClaw Security Audit
+:PROPERTIES:
+:ID:       openclaw-security-audit
+:CREATED:  [2026-03-22 Sun 10:00]
+:END:
+
+Address security audit findings and harden the system.
+
+*** DONE Harden Docker port bindings (bind to 127.0.0.1)
+:PROPERTIES:
+:CREATED: [2026-03-22 Sun 14:30]
+:ASSIGNED: Agent
+:END:
+:LOGBOOK:
+- State "DONE" from "NEXT" [2026-03-22 Sun 14:45]
+:END:
+
+*** NEXT Enable and configure UFW
+:PROPERTIES:
+:CREATED: [2026-03-22 Sun 14:30]
+:ASSIGNED: Amr (Requires sudo)
+:END:
+
+*** TODO Add user 'amr' to 'adm' group for log access
+:PROPERTIES:
+:CREATED: [2026-03-22 Sun 14:30]
+:ASSIGNED: Amr (Requires sudo)
+:END:
+
+** Aletheia (Previous Agora Iteration)
+:PROPERTIES:
+:ID:       aletheia-project
+:END:
+*** TODO Critically analyze Master_Architecture_Document for lessons learned and incorporation into Agora
+:PROPERTIES:
+:CREATED:  [2026-03-21 Sat 09:45]
+:STATUS:   PENDING USER INSTRUCTION
+:NOTES:    User to provide pointers before commencing critical reading and analysis. Do not proceed without explicit instruction.
+:END:
+
+** Personal Software Foundry (PSF) Implementation
+:PROPERTIES:
+:ID:       psf-implementation
+:CREATED:  [2026-03-22 Sun 15:30]
+:END:
+
+Institutionalizing the virtual software house operating system.
+
+*** DONE Draft PSF Operating System Manual (`PSF_OPERATING_SYSTEM.org`)
+:PROPERTIES:
+:CREATED: [2026-03-22 Sun 15:30]
+:ASSIGNED: Agent
+:END:
+:LOGBOOK:
+- State "DONE" from "NEXT" [2026-03-22 Sun 15:45]
+:END:
+
+*** DONE Update `SOUL.org` with PSF Mandates
+:PROPERTIES:
+:CREATED: [2026-03-22 Sun 15:30]
+:ASSIGNED: Agent
+:END:
+:LOGBOOK:
+- State "DONE" from "NEXT" [2026-03-22 Sun 15:45]
+:END:
+
+*** DONE Apply PSF Loop to `org-agent` Phase 1 (Core Loop)
+:PROPERTIES:
+:CREATED: [2026-03-22 Sun 15:30]
+:ASSIGNED: Technical Analyst
+:END:
+:LOGBOOK:
+- State "DONE" from "NEXT" [2026-03-23 Mon 16:30]
+:END:
+
+** Org-agent
+:PROPERTIES:
+:CREATED:  [2026-03-09 Mon 14:23]
+:END:
+
+Org-agent: A Neurosymbolic AI Agent.
+
+*** DONE Draft Swank/Socket communication protocol between CL and Emacs
+:PROPERTIES:
+:CREATED: [2026-03-22 Sun 14:00]
+:ASSIGNED: Agent
+:END:
+:LOGBOOK:
+- State "DONE" from "TODO" [2026-03-22 Sun 15:00]
+:END:
+
+*** DONE Implement core Perceive-Think-Act loop in Common Lisp
+:PROPERTIES:
+:CREATED: [2026-03-22 Sun 14:00]
+:ASSIGNED: Agent
+:END:
+:LOGBOOK:
+- State "DONE" from "NEXT" [2026-03-22 Sun 16:00]
+:END:
+
+*** DONE Implement Persistent Object-Store for Org entities in CL
+:PROPERTIES:
+:CREATED: [2026-03-22 Sun 16:30]
+:ASSIGNED: Agent
+:END:
+:LOGBOOK:
+- State "DONE" from "TODO" [2026-03-22 Sun 17:15]
+:END:
+
+*** DONE Implement LLM Connector (System 1) in CL Daemon
+:PROPERTIES:
+:CREATED: [2026-03-22 Sun 17:30]
+:ASSIGNED: Agent
+:END:
+:LOGBOOK:
+- State "DONE" from "NEXT" [2026-03-23 Mon 16:30]
+:END:
+
+*** DONE Design System 2 Heuristics (Lisp logic over Object Store)
+:PROPERTIES:
+:CREATED: [2026-03-22 Sun 17:30]
+:END:
+:LOGBOOK:
+- State "DONE" from "TODO" [2026-03-23 Mon 16:30]
+:END:
+
+*** DONE Achieve Phase 3: The Self-Editing Kernel
+:PROPERTIES:
+:CREATED: [2026-03-23 Mon 16:30]
+:END:
+- Jailing & Sandboxing implemented
+- Org-Native Skill Standard established
+- Telemetry & Introspection API active
+
+*** NEXT Verify Autonomous Self-Fix Loop
+:PROPERTIES:
+:CREATED: [2026-03-23 Mon 16:30]
+:END:
+Trigger a deliberate error and ensure `skill-self-fix` repairs the code.
+
+*** TODO Implement Skill Graph Visualizer in Web Dashboard
+:PROPERTIES:
+:CREATED: [2026-03-23 Mon 16:30]
+:END:
+Convert the flat list to a D3.js or similar graph view.
+
+*** TODO Build Playwright-Python Bridge for high-fidelity browsing
+:PROPERTIES:
+:CREATED: [2026-03-23 Mon 16:30]
+:END:
+Expand `skill-web-research` to handle JS-heavy sites.
+
+** Lisp Machine Bootstrap
+:PROPERTIES:
+:ID:       lisp-machine-bootstrap
+:CREATED:  [2026-03-22 Sun 14:15]
+:END:
+
+The "Endgame": Hardware-native Lisp machine implementation.
+
+*** TODO Research existing Lisp-on-FPGA implementations
+:PROPERTIES:
+:CREATED: [2026-03-22 Sun 14:15]
+:END:
+
+*** TODO Define minimum hardware-native Lisp ISA (Instruction Set Architecture)
+:PROPERTIES:
+:CREATED: [2026-03-22 Sun 14:15]
+:END:
+
+*** TODO Draft CLOSOS-style Virtual Machine specification
+:PROPERTIES:
+:CREATED: [2026-03-22 Sun 17:30]
+:END:
+
+*** TODO Investigate Single Address Space and Multiple Environments in CL
+:PROPERTIES:
+:CREATED: [2026-03-22 Sun 17:30]
+:END:
+
+** Infrastructure
+:PROPERTIES:
+:ID:       infrastructure-project
+:CREATED:  [2026-03-17 Tue 13:40]
+:END:
+
+IT infrastructure documentation, security hardening, and operational management.
+
+See project documents: [[file:5_projects/infrastructure/README.org][infrastructure/README.org]]
+
+*** TODO Create current state assessment document
+:PROPERTIES:
+:CREATED:  [2026-03-17 Tue 13:40]
+:END:
+
+*** TODO Create risk and vulnerability report
+:PROPERTIES:
+:CREATED:  [2026-03-17 Tue 13:40]
+:END:
+
+*** TODO Create infrastructure inventory
+:PROPERTIES:
+:CREATED:  [2026-03-17 Tue 13:40]
+:END:
+
+*** TODO Create budget analysis
+:PROPERTIES:
+:CREATED:  [2026-03-17 Tue 13:40]
+:END:
+
+*** TODO Create 30/60/90 day roadmap
+:PROPERTIES:
+:CREATED:  [2026-03-17 Tue 13:40]
+:END:
+
+*** TODO Create security implementation plan
+:PROPERTIES:
+:CREATED:  [2026-03-17 Tue 13:40]
+:END:
+
+*** TODO Create token optimization strategy
+:PROPERTIES:
+:CREATED:  [2026-03-17 Tue 13:40]
+:END:
+
+*** TODO Create account management SOPs
+:PROPERTIES:
+:CREATED:  [2026-03-17 Tue 13:40]
+:END:
+
+** Revenue Sustainability
+:PROPERTIES:
+:ID:       revenue-sustainability-project
+:CREATED:  [2026-03-17 Tue 13:40]
+:END:
+
+Business planning and revenue generation strategy.
+
+See project documents: [[file:5_projects/revenue-sustainability/README.org][revenue-sustainability/README.org]]
+
+*** TODO Set up Stripe account (payment processing)
+:PROPERTIES:
+:CREATED:  [2026-03-17 Tue 13:40]
+:END:
+
+*** TODO Set up Wave or Bonsai (invoicing)
+:PROPERTIES:
+:CREATED:  [2026-03-17 Tue 13:40]
+:END:
+
+*** TODO Create simple contract template
+:PROPERTIES:
+:CREATED:  [2026-03-17 Tue 13:40]
+:END:
+
+*** TODO Set up time tracking
+:PROPERTIES:
+:CREATED:  [2026-03-17 Tue 13:40]
+:END:
+
+*** TODO Create portfolio page (GitHub Pages)
+:PROPERTIES:
+:CREATED:  [2026-03-17 Tue 13:40]
+:END:
+
+*** TODO Set up domain name
+:PROPERTIES:
+:CREATED:  [2026-03-17 Tue 13:40]
+:END:
+
+*** TODO Set up email at domain
+:PROPERTIES:
+:CREATED:  [2026-03-17 Tue 13:40]
+:END:
+
+*** TODO Set up social media (Twitter/X, LinkedIn)
+:PROPERTIES:
+:CREATED:  [2026-03-17 Tue 13:40]
+:END:
+
+*** TODO Create testimonial collection system
+:PROPERTIES:
+:CREATED:  [2026-03-17 Tue 13:40]
+:END:
+
+** Agora Gap Verification
+:PROPERTIES:
+:ID:       agora-gap-verification-project
+:CREATED:  [2026-03-17 Tue 15:15]
+:END:
+
+Cross-reference consolidated gap analysis against actual requirement specs to identify real vs. already-addressed gaps.
+
+See project documents: [[file:5_projects/agora/agora-consolidated-gap-analysis.org][agora-consolidated-gap-analysis.org]]
+
+**DECOMPOSITION via Work Breakdown Skill:**
+Complexity check failed (51 gaps, 10 files, unpredictable scope). Breaking into atomic verification tasks.
+
+*** DONE [1/7] Verify CRITICAL Gap: Contract TypeScript/Protobuf Interfaces → REAL GAP
+:PROPERTIES:
+:CREATED: [2026-03-17 Tue 15:15]
+:ASSIGNED: Agent
+:END:
+:LOGBOOK:
+- State "NEXT" from "TODO" [2026-03-17 Tue 15:15]
+- State "DONE" from "NEXT" [2026-03-17 Tue 15:59]
+:END:
+
+*HOW:* Searched Section 02 for "interface", "type", "struct", "ContractTemplate". Found 5 TypeScript interfaces (all for revocation, not contracts). Line 951 explicitly states "Gap: No sample JSON for each contract type".
+
+*WHAT:* **REAL GAP** - Contracts described conceptually, lack formal TypeScript/Protobuf schemas.
+
+*** DONE [2/7] Verify CRITICAL Gap: Persona Revocation Protocol → IMPLEMENTED
+:PROPERTIES:
+:CREATED: [2026-03-17 Tue 15:15]
+:ASSIGNED: Agent
+:END:
+:LOGBOOK:
+- State "TODO" from "" [2026-03-17 Tue 15:15]
+- State "DONE" from "TODO" [2026-03-17 Tue 15:59]
+:END:
+
+*HOW:* Checked Section 02 lines 229-260. Found complete protocol with 3 scenarios (Key Compromise, Persona Retirement, Master Key Compromise), 4-step process, and TypeScript interfaces.
+
+*WHAT:* **ALREADY IMPLEMENTED** - Full protocol specification exists. Gap analysis incorrectly flagged this.
+
+*** DONE [3/7] Verify CRITICAL Gap: PDS-to-PDS Sync Protocol → IMPLEMENTED
+:PROPERTIES:
+:CREATED: [2026-03-17 Tue 15:15]
+:ASSIGNED: Agent
+:END:
+:LOGBOOK:
+- State "TODO" from "" [2026-03-17 Tue 15:15]
+- State "DONE" from "TODO" [2026-03-17 Tue 15:59]
+:END:
+
+*HOW:* Checked Section 03 lines 142-180. Found complete sync protocol with Concept, 3 Use Cases (Redundancy, Geographic Distribution, Load Balancing), and Merkle DAG Synchronization architecture.
+
+*WHAT:* **ALREADY IMPLEMENTED** - Protocol fully specified. PDSSyncSession interface documented.
+
+*** DONE [4/7] Verify CRITICAL Gap: Content Flag Schema Validation → REAL GAP
+:PROPERTIES:
+:CREATED: [2026-03-17 Tue 15:15]
+:ASSIGNED: Agent
+:END:
+:LOGBOOK:
+- State "TODO" from "" [2026-03-17 Tue 15:15]
+- State "DONE" from "TODO" [2026-03-17 Tue 15:59]
+:END:
+
+*HOW:* Searched Section 05 for "JSON Schema", "flag", "validation". Found 9 flags described narratively (is_public, is_direct, is_ephemeral, etc.) at lines 24-34. No formal JSON Schema found.
+
+*WHAT:* **REAL GAP** - Flags have informal descriptions but lack formal JSON Schema for validation.
+
+*** DOING [5/7] [BATCH] Verify HIGH priority gaps (15 items) - DELEGATED TO SUB-AGENTS
+:PROPERTIES:
+:CREATED: [2026-03-17 Tue 15:15]
+:ASSIGNED: Agent
+:END:
+:LOGBOOK:
+- State "TODO" from "" [2026-03-17 Tue 15:15]
+- State "NEXT" from "TODO" [2026-03-17 Tue 16:04]
+- State "DOING" from "NEXT" [2026-03-17 Tue 16:05]
+:END:
+
+*HOW:* Delegated to 5 sub-agents for parallel verification per section. Monitoring progress centrally.
+
+*Sub-Agent Assignments:*
+- **Sub-Agent 1:** Section 02 Identity (4 HIGH gaps)
+- **Sub-Agent 2:** Section 03 Infrastructure (3 HIGH gaps)
+- **Sub-Agent 3:** Section 05 Public Space (4 HIGH gaps)
+- **Sub-Agent 4:** Section 06 Advanced Integration (2 HIGH gaps)
+- **Sub-Agent 5:** Sections 08-09 Implementation/Strategy (2 HIGH gaps)
+
+*Current focus:* Orchestrating sub-agent verification. CRITICAL gaps complete (2 REAL, 2 IMPLEMENTED).
+
+*** TODO [BATCH] Verify MEDIUM priority gaps (14 items)
+:PROPERTIES:
+:CREATED: [2026-03-17 Tue 15:15]
+:ASSIGNED: Agent
+:END:
+:LOGBOOK:
+- State "TODO" from "" [2026-03-17 Tue 15:15]
+:END:
+
+Cross-reference 14 MEDIUM gaps. Defer until HIGH gaps complete.
+
+*** TODO Generate verified gap report
+:PROPERTIES:
+:CREATED: [2026-03-17 Tue 15:15]
+:ASSIGNED: Agent
+:END:
+:LOGBOOK:
+- State "TODO" from "" [2026-03-17 Tue 15:15]
+:END:
+
+Create summary documenting: which gaps are REAL (need implementation) vs. ALREADY-IMPLEMENTED (documentation only) vs. PARTIAL (needs completion).
+
+** Token Optimization
+:PROPERTIES:
+:ID:       token-optimization-project
+:CREATED:  [2026-03-17 Tue 13:40]  
+:END:
+
+Cost-effective LLM usage strategy and implementation.
+
+See project documents: [[file:5_projects/token-optimization/README.org][token-optimization/README.org]]
+
+*** TODO Configure Gemini as primary provider
+:PROPERTIES:
+:CREATED:  [2026-03-17 Tue 13:40]
+:END:
+
+*** TODO Set up OpenRouter fallback
+:PROPERTIES:
+:CREATED:  [2026-03-17 Tue 13:40]
+:END:
+
+*** TODO Implement basic usage tracking
+:PROPERTIES:
+:CREATED:  [2026-03-17 Tue 13:40]
+:END:
+
+*** TODO Document current baseline
+:PROPERTIES:
+:CREATED:  [2026-03-17 Tue 13:40]
+:END:
+
+*** TODO Add smart routing logic
+:PROPERTIES:
+:CREATED:  [2026-03-17 Tue 13:40]
+:END:
+
+*** TODO Implement context compression
+:PROPERTIES:
+:CREATED:  [2026-03-17 Tue 13:40]
+:END:
+
+*** TODO Set up budget alerts
+:PROPERTIES:
+:CREATED:  [2026-03-17 Tue 13:40]
+:END:
+
+*** TODO A/B test model choices
+:PROPERTIES:
+:CREATED:  [2026-03-17 Tue 13:40]
+:END:
+
+* Incubate
+:PROPERTIES:
+:ID:       gtd-incubate
+:END:
+
+** TODO Arabic Classics :arabic:books:literature:egypt:
+:PROPERTIES:
+:ID:       Arabic-Classics-2024-02-05-13-48-07
+:ORG_GTD_TIMESTAMP: <2025-01-01>
+:CATEGORY: Egypt
+:END:
+
+<2025-01-01>
+[2023-05-16 Tue 22:29]
+
+The Arabic Classics project builds on the fact that the majority of books in Arabic are yet to come in the public domain. With 75 years of copyright for the authors estate in Egypt, book of authors who died in 1950 are just about to come into the public domain next year in 2025.
+
+The will create and publish electronic anthologies, one for each author, bringing together all their work, prefaced by an in-depth biography, not dissimilar to the Delphi Collection.
+
+Each year, the project will go forward in time as more works enter the public domain, and a number of years backwards until the beginning of Arabic literature (and potentially neighboring languages): first in increments of 10 years, then 25, then a century or more covered each year.
+
+- Authors
+- Specs
+
+** TODO Open dog
+:PROPERTIES:
+:ID:       Open-dog-2024-02-04-18-16-26
+:ORG_GTD_TIMESTAMP: <2025-01-01>
+:CATEGORY: Atoms
+:END:
+
+<2025-01-01>
+<2025-01-01>
+[2024-02-04 Sun 17:44]
+
+** TODO Cartesian robot with changing heads
+:PROPERTIES:
+:ID:       Cartesian-robot-with-changing-heads-2024-02-04-18-17-06
+:ORG_GTD_TIMESTAMP: <2025-01-01>
+:CATEGORY: Atoms
+:END:
+
+<2025-01-01>
+<2025-01-01>
+[2024-02-04 Sun 17:44]
+
+** TODO Modular synth :music:
+:PROPERTIES:
+:ID:       Modular-synth-2024-02-04-18-17-25
+:ORG_GTD_TIMESTAMP: <2025-01-01>
+:CATEGORY: Atoms
+:END:
+
+<2025-01-01>
+<2025-01-01>
+[2024-02-04 Sun 17:45]
+
+** TODO OCR Permaculture Design Manual :permaculture:
+:PROPERTIES:
+:ID:       OCR-Permaculture-Design-Manual-2024-02-04-18-18-36
+:ORG_GTD_TIMESTAMP: <2025-01-01>
+:CATEGORY: Writing
+:END:
+
+<2025-01-01>
+<2025-01-01>
+<2025-01-01>
+[2024-02-04 Sun 17:47]
+
+** TODO Off-grid field guide
+:PROPERTIES:
+:CREATED:  [2024-03-01 Fri 12:13]
+:ID:       Off-grid-field-guide-2024-07-03-10-03-08
+:ORG_GTD_TIMESTAMP: <2025-01-01>
+:CATEGORY: Writing
+:END:
+
+<2025-01-01>
+A modular manual of different areas to go with different activities. Fits in the travelers notebook
+
+* Someday / Future
+:PROPERTIES:
+:ID:       gtd-someday
+:END:
+
+** The Holy Grail: Unified Lisp Environment
+The endgame of the Lisp Machine Mandate. Eliminate context-switching by unifying the browser, the agent, and the editor into a single Common Lisp image.
+
+*** TODO [Grail 1] Emacs xwidget-webkit integration
+Embed a full WebKit engine inside an Emacs buffer. Allow the agent to interact with the live DOM via the OACP socket.
+
+*** TODO [Grail 2] Lisp-native Agentic Browser
+Build a 'Neural Browser' in CL. Instead of HTML, it renders websites as a navigable Org-mode DAG. Mark headlines TODO to trigger clicks/fills.
+
+*** TODO [Grail 3] Full Common Lisp Emacs Implementation
+The ultimate platform. Rewrite the editor core in SBCL (Lem/Hemlock style). The browser becomes a native library, allowing direct memory inspection of the web.
+
+* Habits
+:PROPERTIES:
+:ID:       gtd-habits
+:END:
+

inbox.org

@@ -0,0 +1,6 @@
+#+title: Amero Inbox
+#+begin_comment
+This is the inbox. Everything goes in here when you capture it.
+#+end_comment
+
+* TODO @agent apply project dotemacs

inbox/README.org

@@ -1,2 +1,9 @@
-This file describes the workflow to using this Memex
+#+TITLE: inbox: The Capture Point
+#+AUTHOR: Amr
+#+CREATED: [2026-03-17 Tue]
+#+BEGIN_COMMENT
+Temporary holding area for raw captures, links, and quick thoughts before they are processed into actionable items (GTD) or knowledge (Atomic Notes (Zettelkasten)).
+#+END_COMMENT
 
+* inbox: The Capture Point
+Temporary holding area for raw captures, links, and quick thoughts before they are processed into actionable items (GTD) or knowledge (Atomic Notes (Zettelkasten)).

notes/20260314_agora_open_source_business_models.org

@@ -0,0 +1,204 @@
+#+TITLE: Agora Open Source Business Models
+#+author: User
+#+created: [2026-03-16 Mon 14:28]
+#+ID: 20260314_agora_open_source_business_models
+#+FILETAGS: agora business open-source revenue strategy
+
+* Open Source Business Models for Agora
+
+** Core Constraint
+
+Agora is strictly open source software. Revenue must be generated *around* the protocol, not from ownership of it. This aligns with the "Dumb Pipe" legal strategy and ensures Agora remains a public good.
+
+** Proven Open Source Business Models
+
+Based on analysis of successful open source companies (WordPress, MongoDB, HashiCorp, Confluent, GitLab, Red Hat):
+
+*** 1. Open Core Model
+
+*Definition:* Free open-source core + paid proprietary enterprise features.
+
+*Examples:*
+- GitLab: CE (free) vs EE (paid enterprise)
+- Confluent: Apache Kafka (free) + Confluent Platform (paid)
+- MongoDB (pre-2018): Community Server + Enterprise Server
+
+*Revenue characteristics:*
+- High margins (93% for Red Hat subscriptions vs 31% for services)
+- Scalable without linear headcount growth
+- Most profitable model per Imran Ghory analysis
+
+*Agora applicability:* Limited. Agora's philosophy is full decentralization, not feature-gating. However, could offer:
+- Managed PDS with enterprise features (backup, compliance, SLA)
+- Advanced analytics dashboard for enterprise customers
+
+*** 2. Hosting/Cloud Services ("X-as-a-Service")
+
+*Definition:* Managed hosting of open source software. Customer pays for convenience, not software.
+
+*Examples:*
+- WordPress.com (Automattic) vs WordPress.org (open source)
+- MongoDB Atlas: ~65% gross margins
+- Elastic Cloud: ~40% gross margins
+- WP Engine: Premium WordPress hosting
+
+*Revenue characteristics:*
+- Recurring revenue (SaaS model)
+- High margins (40-65%)
+- Requires operational investment
+- Risk: Cloud providers (AWS) can compete
+
+*Agora applicability:* *PRIMARY MODEL*
+
+| Service | Description | Revenue Model |
+|---------|-------------|---------------|
+| PDS Hosting | Managed Personal Data Stores | Monthly subscription per user |
+| Relay Hosting | High-availability relay nodes | Usage-based (per message routed) |
+| Agora Cloud | Full managed Agora stack | Tiered subscriptions |
+| Backup Services | Encrypted PDS backups | Per-GB storage fees |
+
+*** 3. Professional Services
+
+*Definition:* Consulting, implementation, training, support contracts.
+
+*Examples:*
+- Red Hat: Started here, moved to subscriptions
+- Cloudera: Hadoop consulting + support
+- Percona: MySQL/PostgreSQL support
+
+*Revenue characteristics:*
+- Lower margins (requires headcount)
+- Unpredictable revenue
+- Good for initial traction
+- Often combined with other models
+
+*Agora applicability:*
+- Enterprise implementation consulting
+- Custom PDS deployment
+- Migration services (from Twitter/Mastodon)
+- Training and certification programs
+
+*** 4. Marketplace Model
+
+*Definition:* Revenue from ecosystem transactions, not core software.
+
+*Examples:*
+- Android: Google Play fees (30% on transactions)
+- WordPress.org: Marketplace for themes/plugins
+- Mozilla: $500M/year from Google search default
+
+*Revenue characteristics:*
+- Network effects drive revenue
+- Low marginal cost
+- Requires large user base
+
+*Agora applicability:* *NETWORK-LEVEL REVENUE*
+
+| Revenue Stream | Mechanism |
+|----------------|-----------|
+| App Marketplace | Curated Agora apps, themes, plugins |
+| Transaction Fees | Micro-fees on marketplace transactions (not protocol) |
+| Premium Names | Auction for desirable persona names |
+| Verified Badges | Identity verification services |
+
+** Agora-Specific Revenue Streams
+
+*** Phase 1: Infrastructure Services (Immediate)
+
+*PDS Hosting:*
+- Target: Non-technical users who want sovereignty without complexity
+- Pricing: $5-20/month tiers (competitive with Mastodon hosting)
+- Value prop: "Your data, your keys, our servers"
+
+*Relay Node Operation:*
+- Target: Communities needing reliable message routing
+- Pricing: Pay-per-message or monthly capacity
+- Value prop: 99.9% uptime, geographic distribution
+
+*Validator Oracle Network:*
+- Target: Developers needing CI/CD for Agora repos
+- Pricing: Per-test execution (satoshis)
+- Value prop: Decentralized testing, cryptographic attestations
+
+*** Phase 2: Enterprise Services (Year 1-2)
+
+*Enterprise Support:*
+- SLA-backed support for self-hosted Agora
+- 24/7 incident response
+- Custom feature development
+
+*Compliance & Legal:*
+- GDPR/CCPA compliance tools
+- Legal Defense Collective membership
+- Audit and attestation services
+
+*Integration Services:*
+- Legacy system bridges
+- Custom ActivityPub connectors
+- Enterprise SSO integration
+
+*** Phase 3: Network Effects (Year 2+)
+
+*Marketplace Commission:*
+- 5-10% on premium app sales
+- Not on protocol usage (that stays free)
+- Curated, high-quality apps only
+
+*Data Services (Opt-in):*
+- Aggregated, anonymized trend analysis
+- Research partnerships
+- Always with user consent
+
+*Premium Identity:*
+- Short name auctions (e.g., @user)- Verified organization badges
+- Domain verification services
+
+** Financial Projections (Illustrative)
+
+Based on comparable open source companies:
+
+| Model | Gross Margin | Scalability | Time to Revenue |
+|-------|--------------|-------------|-----------------|
+| PDS Hosting | 60-70% | High | Immediate |
+| Relay Services | 50-60% | High | Immediate |
+| Professional Services | 30-40% | Low (headcount) | Immediate |
+| Marketplace | 80-90% | Very High | Year 2+ |
+| Enterprise Support | 70-80% | Medium | Year 1 |
+
+** Strategic Recommendations
+
+1. *Start with Hosting:* Fastest path to revenue, aligns with user needs
+2. *Avoid Open Core:* Contradicts Agora's decentralization ethos
+3. *Build Marketplace Early:* Even if low volume initially, establishes ecosystem
+4. *Professional Services Bridge:* Fund development while product matures
+5. *Network Revenue Last:* Requires scale, but highest margins
+
+** Risk Mitigation
+
+*Cloud Provider Competition:*
+- AWS/Azure could offer Agora hosting
+- Defense: First-mover advantage, community trust, Validator Oracle network effects
+- License: True open source (not SSPL) prevents lock-in fears
+
+*Funding Gap:*
+- Services revenue is slower than VC-funded competitors
+- Mitigation: Grants (Filecoin, Ethereum, Bitcoin/Lightning ecosystems), crowdfunding
+
+** Success Metrics
+
+- Year 1: 1,000 paid PDS accounts ($10k MRR)
+- Year 2: 10,000 PDS + enterprise contracts ($100k MRR)
+- Year 3: Self-sustaining via marketplace + hosting ($500k MRR)
+
+** Related
+
+- [[file:20260314_rtx_pro_6000_llm.org][RTX Pro 6000 for Local LLM Inference]] (infrastructure for self-hosting)
+- [[file:agora-strategic-positioning.org][Agora Strategic Positioning]]
+- [[file:agora-lightning-economics.org][Agora Lightning Economics]]
+
+** Sources
+
+- Palark: "How companies make millions on Open Source" (Dec 2022)
+- Navdeep Yadav: "How do Open source companies like WordPress, Android, and MongoDB make money" (Nov 2022)
+- HashiCorp S-1 SEC filing (2021)
+- Forbes: "Monetizing Open Source: Business Models That Generate Billions" (Sep 2020)

notes/20260314_cognition_first_agent_architecture.org

@@ -0,0 +1,184 @@
+#+TITLE: Cognition-First Agent Architecture: The Neurosymbolic Personal Computer
+#+author: User
+#+created: [2026-03-16 Mon 14:28]
+#+ID: 20260314_cognition_first_agent_architecture
+#+FILETAGS: agora architecture cognition agents neurosymbolic lisp-machines ai-systems
+
+* Cognition-First Agent Architecture
+
+** Core Insight
+
+A truly intelligent personal agent should be designed as a *cognitive extension*—not a service that responds to queries, but a persistent, contextual, reasoning system that participates in the user's thinking process. This is distinct from current LLM-based agents (ChatGPT, Claude) which are stateless, conversational interfaces.
+
+** Comparison: Current vs Cognition-First Design
+
+| Aspect | Current LLM Agents (OpenClaw, ChatGPT) | Cognition-First Architecture |
+|--------|----------------------------------------|------------------------------|
+| Session model | Request-response, stateless | Persistent, image-based |
+| Memory | External files (MEMORY.md), inferred | Internal, continuous, learned |
+| Context | Loaded per conversation | Always resident, predictive |
+| Interaction | Conversational turns | Participatory, interrupt-driven |
+| Tool use | Fixed palette, discovery via docs | Dynamic composition, agent-driven |
+| Proactivity | Reactive (cron, user prompts) | Epistemic triggers, continuous |
+| Reasoning visibility | Hidden or binary (on/off) | Transparent, multi-draft, tagged |
+
+** Philosophical Foundation
+
+*** Lisp Machines as Precedent
+
+Lisp machines (1970s-1980s) embodied key principles:
+- *Image-based persistence*: Workspace, definitions, and state continued across sessions
+- *Live environment*: The system was always running, always introspectable
+- *Homoiconicity*: Code and data shared the same structure, enabling meta-programming
+- *Personal computing*: Single-user machines optimized for the individual's workflow
+
+The cognition-first agent revives this philosophy: your PDS is not storage but a *running cognitive environment*—an "image" that learns your patterns.
+
+*** Neurosymbolic Computing
+
+We are describing a neurosymbolic architecture:
+
+- *Neural component (System 1)*: LLMs provide pattern recognition, generation, intuition
+  - Fast, associative, context-sensitive
+  - Handles ambiguity, natural language, creativity
+  - Limited by context window, hallucination, no persistent memory
+
+- *Symbolic component (System 2)*: The agent architecture provides structure, reasoning, persistence
+  - Slow, deliberate, rule-based
+  - Maintains knowledge graphs, executes plans, tracks epistemic state
+  - Provides guardrails, verification, long-term memory
+
+*Integration*: The neural system generates hypotheses; the symbolic system validates, structures, and persists them. Like human cognition—intuition proposes, reason disposes.
+
+** Architectural Components
+
+*** 1. Persistent Working Memory
+
+Unlike OpenClaw's fresh-session model, a cognition-first agent maintains:
+- Conceptual graph of user's projects, interests, constraints
+- Active working set: "Currently tracking: Agora PDS, RTX Pro 6000 research, rack server migration"
+- Epistemic state: Confidence levels, open questions, contradictions
+
+*Implementation*: The PDS becomes a *live object graph*—not files to read, but a runtime environment to inhabit.
+
+*** 2. Predictive Context Loading
+
+Instead of: "Read MEMORY.md and infer state"
+
+The agent: "User is asking about GPUs → preload RTX Pro 6000 note, rack server research, budget constraints, prior hardware discussions → present integrated synthesis"
+
+This mirrors how Emacs predictive loading works—you don't `cat` files, you navigate a living structure.
+
+*** 3. Transparent Cognition
+
+Current LLMs hide their reasoning (or stream it inscrutably).
+
+Cognition-first design:
+- Visible *scratch* buffer where the agent works through problems
+- Multi-draft thinking: explores approaches, shows tradeoffs
+- Tagged reasoning: [Speculative], [High confidence], [Requires validation]
+- Meta-cognitive layer: "I don't know your stance on X—should I infer from context or ask?"
+
+*** 4. Org-Mode as Native Interface
+
+Not just reading/writing text—*participating in structure*:
+- Native AST understanding of Org semantics
+- Agenda integration: agent suggestions appear in user's agenda
+- Structural editing: refactor outlines, reorganize projects, archive completed items
+- Babel integration: agent "tangles" its reasoning into executable code
+
+*** 5. Interrupt-Driven Proactivity
+
+Not heartbeat polling but epistemic triggers:
+- "When user mentions hardware purchase → check budget constraints → suggest rack-mountable options"
+- "New note connects to 3 prior notes → gently surface connection graph"
+- "Stuck on problem for 3 days → agent found relevant paper during background research"
+
+Like Emacs idle timers or process filters—event-driven, not polling.
+
+** Position in Agora Architecture
+
+*** The PDS as Lisp Image
+
+In Agora v2:
+- PDS = Personal Data Store + Runtime Environment
+- Always-on background processes: indexing, connecting, surfacing
+- State survives restarts: "I was analyzing your research when you went offline—here's my interim conclusion"
+- Sub-agents share the same "image" (distributed cognition over unified graph)
+
+*** Agent-as-Extension Pattern
+
+- Each sub-agent is a specialized cognitive tool (research, coding, analysis)
+- They share context via the PDS graph
+- Hand-offs: "Research agent found paper → Analysis agent reading → Notifies user when ready"
+- Not chatbots—collaborative thinkers
+
+*** Contrast with Current "AI Apps"
+
+Current pattern: Wrapper around LLM API (+ vector DB, + prompts)
+- Stateless, generic, SaaS-centric
+
+Agora pattern: Personal image-based agent runtime
+- Stateful, personal, local-first
+- LLMs are *substrate*, not product
+
+** System 1 / System 2 Integration
+
+| Function | System 1 (Neural/LLM) | System 2 (Symbolic/Agent) |
+|----------|----------------------|---------------------------|
+| Pattern matching | Generates associations | Structures into knowledge graph |
+| Text generation | Writes prose, code, summaries | Validates for consistency, sources |
+| Ambiguity handling | Navigates unclear requests | Tracks uncertainty, asks clarifying questions |
+| Creativity | Brainstorms, finds novel connections | Evaluates feasibility, checks constraints |
+| Memory | Context window (limited, ephemeral) | Persistent, queryable, versioned |
+| Reasoning | Intuitive leaps | Step-by-step, verifiable inference |
+
+*Cooperation*: The neural system *proposes*; the symbolic system *disposes*.
+
+** Implications for Agora Design
+
+1. *Sub-agents need shared memory*: Not just passing messages—shared conceptual graph
+2. *PDS is runtime, not storage*: Always-on processes, background indexing
+3. *Org-mode is interface*: Native participation in user's thinking structure
+4. *Epistemic hygiene*: Track confidence, uncertainty, provenance
+5. *Graceful degradation*: LLM unavailable?Symbolic system continues with reduced capability
+
+** Implementation Challenges
+
+1. *Resource management*: Always-on agents consume compute even when idle
+2. *Conflict resolution*: Multiple sub-agents modifying shared state
+3. *Version control*: How to branch/merge an agent's "image"?
+4. *Debugging*: When agent reasoning goes wrong, traceability is crucial
+5. *User control*: Interrupt-driven proactivity risks notification fatigue
+
+** Related Concepts
+
+- Lisp machines (Symbolics, LMI): Image-based, personal, extensible
+- Emacs: The extensible, customizable, self-documenting real-time display editor
+- SOAR cognitive architecture: Problem-solving as state-space search
+- Kahneman's System 1/2: Dual-process theory of cognition
+- Neurosymbolic AI: Combining neural networks with symbolic reasoning
+
+** Connections to Agora Documentation
+
+- [[file:20260314_agora_open_source_business_models.org][Agora Open Source Business Models]]
+- [[file:agora-pds-relay-architecture.org][Agora PDS & Relay Architecture]]
+- [[file:20260314_org_gtd_automation_strategies.org][Org-GTD Automation Strategies]]
+- [[file:agora-requirements.org][Agora Requirements Specification]]
+
+** Open Questions
+
+1. How does this architecture scale to resource-constrained devices?
+2. What is the migration path from stateless (current) to stateful agents?
+3. How to handle agent "personality drift" over time?
+4. Can this architecture support collective intelligence (multiple users, shared cognition)?
+5. What are the security implications of always-on agents with deep personal knowledge?
+
+** Conclusion
+
+We are describing not an "AI assistant" but a *personal cognitive infrastructure*—a neurosymbolic system where neural networks provide associative intelligence and symbolic architecture provides structure, persistence, and reasoning. The Lisp machine philosophy, applied to modern AI, creating an environment where the boundary between human and machine cognition becomes a continuum rather than an interface.
+
+#+begin_quote
+"The computer should be an extension of the mind, not a tool for the hand."
+— Paraphrasing J.C.R. Licklider, Man-Computer Symbiosis (1960)
+#+end_quote

notes/20260314_org_gtd_automation_strategies.org

@@ -0,0 +1,219 @@
+#+TITLE: Org-GTD Automation Strategies for OpenClaw Integration
+#+author: User
+#+created: [2026-03-16 Mon 14:28]
+#+ID: 20260314_org_gtd_automation_strategies
+#+FILETAGS: org-mode gtd automation emacs org-gtd
+
+* Research: Automating Org-GTD for OpenClaw Integration
+
+** The Core Problem
+
+`org-gtd.el` is designed for *interactive* Emacs use. Most functions rely on:
+- `point` being at a specific entry
+- Interactive prompts (`completing-read`, `yes-or-no-p`)
+- Context from the current buffer position
+
+This creates friction for automation—OpenClaw cannot "stand on an item" like a human user.
+
+** Approaches to Automation
+
+*** Approach 1: ID-Based Operations (Recommended)
+
+Org entries have unique IDs. We can use `org-id` to locate entries programmatically:
+
+#+begin_src elisp
+;; Move to entry by ID, then execute org-gtd function
+(defun org-gtd-automate-by-id (entry-id command)
+  "Execute org-gtd COMMAND at entry with ENTRY-ID."
+  (let ((marker (org-id-find entry-id 'marker)))
+    (when marker
+      (with-current-buffer (marker-buffer marker)
+        (goto-char (marker-position marker))
+        (funcall command)))))
+
+;; Example usage in batch mode:
+;; emacs --batch -l org-gtd \
+;;   --eval '(org-gtd-automate-by-id "my-entry-id" #'org-gtd-archive-item)'
+#+end_src
+
+*Advantages:*
+- Works with any org-gtd function
+- No regex parsing needed
+- Preserves all org-gtd logic
+
+*Limitations:*
+- Requires entries to have IDs (add `:ID:` property)
+- Functions with interactive prompts will still block
+
+*** Approach 2: Custom Non-Interactive Wrappers
+
+Write wrapper functions that accept arguments instead of using interactive prompts:
+
+#+begin_src elisp
+(defun org-gtd-set-status-noninteractive (entry-id new-status)
+  "Set status of entry with ENTRY-ID to NEW-STATUS (TODO, NEXT, WAIT, DONE)."
+  (let ((marker (org-id-find entry-id 'marker)))
+    (when marker
+      (with-current-buffer (marker-buffer marker)
+        (goto-char (marker-position marker))
+        (org-todo new-status)))))
+
+(defun org-gtd-archive-by-id (entry-id)
+  "Archive entry with ENTRY-ID."
+  (let ((marker (org-id-find entry-id 'marker)))
+    (when marker
+      (with-current-buffer (marker-buffer marker)
+        (goto-char (marker-position marker))
+        (org-archive-subtree)))))
+#+end_src
+
+*Advantages:*
+- Clean API for batch operations
+- No interactive prompts
+- Can chain multiple operations
+
+*** Approach 3: Plain Org Mode (Most Automation-Friendly)
+
+Instead of `org-gtd.el`, use standard Org features that are designed for automation:
+
+#+begin_src org
+,* TODO Project Alpha
+:PROPERTIES:
+:ID:       proj-alpha-001
+:CATEGORY: proj-alpha
+:GTD_TYPE: project
+:END:
+,** NEXT First action
+:PROPERTIES:
+:ID:       action-001
+:GTD_TYPE: next
+:END:
+,** TODO Second action
+,** WAIT Waiting for response
+
+,* TODO Standalone next action :context_home:
+:PROPERTIES:
+:GTD_TYPE: next
+:END:
+#+end_src
+
+*Standard Org functions I can use:*
+- `org-todo` — Change TODO state
+- `org-set-property` — Set/change properties
+- `org-archive-subtree` — Archive entries
+- `org-refile` — Move entries between files
+- `org-id-find` — Locate by ID
+- `org-map-entries` — Batch operations across entries
+
+** File Structure for Automation
+
+*Recommended layout:*
+
+#+begin_example
+~/memex/gtd/
+├── inbox.org      # Captured items (process to main)
+├── main.org       # Active projects and next actions
+├── someday.org    # Someday/maybe items
+├── waiting.org    # Delegated/waiting items
+├── archive.org    # Completed items
+└── templates/     # Capture templates
+#+end_example
+
+** Comparison: org-gtd.el vs Plain Org
+
+| Feature | org-gtd.el | Plain Org |
+|---------|------------|-----------|
+| Interactive workflow | Excellent | Good |
+| Batch automation | Poor | Excellent |
+| Learning curve | Medium | Low |
+| Community support | Active | Massive |
+| GTD semantics | Built-in | Manual setup |
+| Custom agenda views | Good | Excellent |
+
+** Recommendation
+
+For your use case (hybrid interactive + automation):
+
+1. *Use plain Org Mode* with custom properties for GTD semantics
+2. *Define your own TODO states:* TODO → NEXT → WAIT → DONE/CNCL
+3. *Use ID properties* on all entries for automation targeting
+4. *Create agenda views* for daily/weekly reviews
+5. *Reserve interactive work* for capture, clarification, and review
+6. *Use automation for:*
+   - Archiving completed items
+   - Moving waiting items to active
+   - Generating reports
+   - Refiling from inbox to projects
+
+** Sample Automation Commands
+
+*Archive all DONE items over 30 days old:*
+
+#+begin_src elisp
+(defun org-gtd-archive-old-done ()
+  "Archive DONE items older than 30 days."
+  (org-map-entries
+   (lambda ()
+     (when (string= (org-get-todo-state) "DONE")
+       (let ((closed (org-entry-get nil "CLOSED")))
+         (when (and closed
+                    (> (org-time-stamp-to-now closed) 30))
+           (org-archive-subtree)))))
+   t 'agenda))
+#+end_src
+
+*Find stuck projects (PROJ without NEXT):*
+
+#+begin_src elisp
+(defun org-gtd-find-stuck-projects ()
+  "Return list of IDs for projects without NEXT actions."
+  (let (stuck)
+    (org-map-entries
+     (lambda ()
+       (when (string= (org-get-todo-state) "PROJ")
+         (let ((id (org-entry-get nil "ID"))
+               (has-next nil))
+           (org-map-entries
+            (lambda ()
+              (when (string= (org-get-todo-state) "NEXT")
+                (setq has-next t)))
+            nil 'tree)
+           (unless has-next
+             (push id stuck))))))
+    stuck))
+#+end_src
+
+** Integration Points with OpenClaw
+
+*OpenClaw can:*
+1. Read your gtd.org files to find next actions
+2. Create new entries via `write` tool (append to inbox.org)
+3. Archive completed items by locating via ID
+4. Generate weekly reports (parse files, output summaries)
+5. Trigger reviews based on HEARTBEAT.md schedules
+
+*OpenClaw cannot (easily):*
+1. Toggle states interactively (requires cursor position)
+2. Process inbox items (clarification requires human judgment)
+3. Run org-agenda (needs Emacs UI)
+
+** Summary
+
+- org-gtd.el is optimized for *interactive* use
+- Batch automation works best with *plain Org + ID properties*
+- Consider a hybrid: org-gtd for capture/review, custom functions for automation
+- The "projects as hierarchy" approach (from Desmond Rivet's blog) is automation-friendly
+
+** Related
+
+- [[file:20260314_agora_open_source_business_models.org][Agora Open Source Business Models]]
+- [[file:agora-pds-relay-architecture.org][Agora PDS & Relay Architecture]]
+- Desmond Rivet's GTD implementation: https://desmondrivet.com/2023/12/05/gtd-org-mode
+- org-gtd.el: https://github.com/Trevoke/org-gtd.el
+
+** Next Steps
+
+TODO  Test org-id based automation on sample files
+TODO  Create wrapper functions for common operations
+TODO  Design plain Org GTD structure for memex
+TODO  Implement capture templates for OpenClaw integration

notes/20260314_pds_hosting_competitive_pricing.org

@@ -0,0 +1,150 @@
+#+TITLE: PDS Hosting Competitive Pricing Analysis
+#+author: User
+#+created: [2026-03-16 Mon 14:28]
+#+ID: 20260314_pds_hosting_competitive_pricing
+#+FILETAGS: agora business pricing pds hosting competitive-analysis
+
+* PDS Hosting Competitive Pricing Analysis
+
+** Purpose
+
+Benchmark pricing for Agora Personal Data Store (PDS) hosting services against existing decentralized social network hosting providers.
+
+** Mastodon Managed Hosting Benchmarks
+
+*** Masto.host (Market Leader)
+
+*Personal/Small Group Plans:*
+
+| Plan | Price | Database | Media Storage | Users | Processing Threads |
+|------|-------|----------|---------------|-------|------------------|
+| Moon | $6/mo | 2 GB | 20 GB | 5 active | 2 threads |
+| Planet | $9/mo | 5 GB | 50 GB | 20 active | 4 threads |
+| Star | $19/mo | 10 GB | 100 GB | 100 active | 8 threads |
+
+*Community Plans:*
+
+| Plan | Price | Database | Media Storage | Users | Processing Threads |
+|------|-------|----------|---------------|-------|------------------|
+| Constellation | $39/mo | 20 GB | 200 GB | 500 active | 20 threads |
+| Galaxy | $89/mo | 40 GB | 400 GB | 2000 active | 50 threads |
+
+*Add-ons:*
+- Extra Resources: $10/month (adds 4 threads, 4 GB DB, 40 GB storage)
+- ElasticSearch: $5-10/month (full-text search)
+
+*All plans include:*
+- Hosting and maintenance
+- Automatic installation and updates
+- Email notifications
+- Daily remote backups
+- Free subdomain or custom domain
+- TLS certificate (Let's Encrypt)
+- Automated cache deletion
+
+** Bluesky PDS Hosting
+
+*Current State:*
+- Bluesky operates on the AT Protocol
+- PDS (Personal Data Server) is self-hostable
+- Limited commercial PDS hosting providers (ecosystem still emerging)
+- Most users currently on Bluesky's official PDS (free, but centralized)
+
+*Self-Hosting Requirements (from AT Protocol docs):*
+- Minimum: 2 CPU cores, 4 GB RAM, 20 GB storage
+- Recommended: 4+ CPU cores, 8 GB RAM, 100 GB+ storage
+- Cost equivalent: ~$10-40/month on VPS (DigitalOcean, AWS, etc.)
+
+** Other Mastodon Hosting Providers
+
+*Pricing comparison (estimated from market research):*
+
+| Provider | Entry Price | Entry Specs | Notes |
+|----------|-------------|-------------|-------|
+| Masto.host | $6/mo | 2GB DB, 20GB media | Market leader, reliable |
+| Spacebear | €5/mo (~$5.50) | Similar to Moon | EU-based |
+| Fosstodon | $5/mo | Community-focused | Non-profit |
+| Self-hosted | $5-20/mo | Variable | Requires technical skill |
+
+** Agora PDS Hosting Recommendations
+
+*** Pricing Strategy
+
+*Positioning:* Match or slightly undercut Masto.host (market leader)
+
+*Recommended Tiers:*
+
+| Tier | Price | Storage | Features | Target |
+|------|-------|---------|----------|--------|
+| Seed | $5/mo | 10 GB | Basic PDS, backups | Individual users |
+| Sprout | $10/mo | 50 GB | PDS + Relay access | Active users |
+| Tree | $20/mo | 200 GB | PDS + Relay + Priority | Power users |
+| Forest | $50/mo | 1 TB | Enterprise PDS cluster | Communities |
+
+*Key differentiators from Mastodon:*
+1. *Lightning-native payments* (not credit card only)
+2. *PDS + Relay bundled* (Mastodon separates these)
+3. *Validator Oracle credits* included (for developers)
+4. *Cross-platform identity* (not just Mastodon federation)
+
+*** Revenue Projections
+
+*Conservative (Year 1):*
+- 100 Seed users: $500/month
+- 50 Sprout users: $500/month
+- 20 Tree users: $400/month
+- *Total: $1,400/month ($16,800/year)*
+
+*Optimistic (Year 2):*
+- 500 Seed users: $2,500/month
+- 200 Sprout users: $2,000/month
+- 100 Tree users: $2,000/month
+- 10 Forest users: $500/month
+- *Total: $7,000/month ($84,000/year)*
+
+** Technical Cost Basis
+
+*Infrastructure costs (estimated):*
+
+| User Tier | Server Cost | Storage Cost | Margin |
+|-----------|-------------|--------------|--------|
+| Seed ($5) | ~$2/mo | ~$0.50/mo | ~50% |
+| Sprout ($10) | ~$4/mo | ~$2/mo | ~40% |
+| Tree ($20) | ~$8/mo | ~$5/mo | ~35% |
+| Forest ($50) | ~$20/mo | ~$10/mo | ~40% |
+
+*Note:* Margins improve with scale (shared infrastructure, bulk storage).
+
+** Competitive Advantages
+
+1. *Protocol-level integration:* PDS + Relay + Validator Oracles as unified service
+2. *Bitcoin/Lightning payments:* Lower fees, better privacy, global accessibility
+3. *Sovereign identity:* Users truly own their data (not just "managed hosting")
+4. *No vendor lock-in:* Easy export/migration (content-addressed data)
+5. *Community governance:* Revenue shares with Relay operators
+
+** Risks
+
+1. *Market education:* Users don't yet understand PDS concept
+2. *Competition:* Bluesky may offer free PDS hosting long-term
+3. *Technical complexity:* PDS setup harder than Mastodon
+4. *Scale economics:* Need ~500+ users to reach profitability
+
+** Next Steps
+
+TODO  Validate pricing with potential users
+TODO  Build MVP PDS hosting infrastructure
+TODO  Create cost calculator for infrastructure planning
+TODO  Research VPS/reseller hosting partnerships
+
+** Related
+
+- [[file:20260314_agora_open_source_business_models.org][Agora Open Source Business Models]]
+- [[file:agora-pds-relay-architecture.org][Agora PDS & Relay Architecture]]
+- [[file:agora-lightning-economics.org][Agora Lightning Economics]]
+
+** Sources
+
+- Masto.host pricing: https://masto.host/pricing/ (accessed 2026-03-14)
+- AT Protocol documentation: https://atproto.com/
+- Mastodon hosting market research (various providers)

notes/20260314_rtx_pro_6000_llm.org

@@ -0,0 +1,104 @@
+#+TITLE: RTX Pro 6000 for Local LLM Inference
+#+author: User
+#+created: [2026-03-16 Mon 14:28]
+#+ID: 20260314_rtx_pro_6000_llm
+#+FILETAGS: hardware gpu ai llm inference nvidia
+
+* RTX Pro 6000 Blackwell for Local LLM Inference
+
+** The Headline
+
+The RTX Pro 6000 Workstation Edition is a 96GB GDDR7 single-GPU solution that can replace a 4x RTX 4090 setup for 30B parameter models, with headroom for 70B models in FP8 quantization.
+
+** Key Specifications
+
+| Spec | RTX Pro 6000 | RTX 5090 | H100 PCIe |
+|------|--------------|----------|-----------|
+| VRAM | 96GB GDDR7 | 32GB GDDR7 | 80GB HBM2e |
+| Memory Bandwidth | 1.792 TB/s | 1.792 TB/s | 2.0 TB/s |
+| Architecture | Blackwell | Blackwell | Hopper |
+| FP4 Support | Yes | Yes | No |
+| FP8 Support | Yes | Yes | Yes |
+| NVLink | No | No | No (PCIe) |
+| ECC Memory | Yes | No | Yes |
+| Form Factor | Workstation PCIe | Consumer PCIe | PCIe/SXM |
+
+** What Fits in 96GB VRAM
+
+| Model | Size | Precision | Fits? | Notes |
+|-------|------|-----------|-------|-------|
+| Llama 3.1 | 8B | FP16 | Yes | ~16GB (17% of VRAM) |
+| Qwen2.5 | 14B | FP16 | Yes | ~28GB, ~68GB headroom |
+| Qwen2.5 | 32B | FP8 | Yes | ~32GB, ~64GB headroom |
+| Qwen2.5 | 32B | FP16 | Yes | ~64GB, ~32GB headroom |
+| Llama 3.3 | 70B | Q4 (AWQ) | Yes | ~35-40GB, 56-61GB headroom |
+| Llama 3.3 | 70B | FP8 | Yes | ~70GB, ~26GB headroom |
+| Llama 3.3 | 70B | FP16 | No | ~140GB needed |
+| Mixtral 8x7B | ~47B | Q4 | Yes | ~24GB, comfortable |
+| Mixtral 8x7B | ~47B | FP16 | No | ~94GB, no KV cache headroom |
+
+** Benchmark Highlights
+
+CloudRift benchmarks (Oct 2025):
+
+| GPU | Model | Precision | Tokens/sec |
+|-----|-------|-----------|------------|
+| RTX Pro 6000 | Qwen3-Coder-30B-AWQ | AWQ | ~8,400 |
+| 4x RTX 4090 | Qwen3-Coder-30B-AWQ | AWQ | ~8,900 |
+
+*One GPU versus four, with near-identical throughput and lower power draw.*
+
+** Cost Comparison (Cloud Pricing, March 2026)
+
+| GPU | On-demand $/hr | Spot $/hr | VRAM | Fits 70B FP8? |
+|-----|---------------|-----------|------|---------------|
+| RTX 5090 | $0.76 | — | 32GB | No |
+| RTX Pro 6000 | $1.65 | $0.72 | 96GB | Yes (~26GB headroom) |
+| H100 PCIe | $2.01 | — | 80GB | Yes (~10GB headroom) |
+| H200 SXM5 | $4.23 | $1.43 | 141GB | Yes (extensive) |
+
+** Best Use Cases
+
+1. *30B model inference at high throughput* — Replaces 4x RTX 4090 setup
+2. *32B models in FP8/FP16* — Single GPU, no tensor parallelism needed
+3. *70B models in Q4/FP8* — Fits comfortably with KV cache headroom
+4. *Development/testing* — $0.72/hr spot pricing for experimentation
+5. *Diffusion pipelines* — SDXL + ControlNet + LoRA stacks simultaneously
+
+** Limitations
+
+- No NVLink — cannot scale beyond 96GB with tensor parallelism
+- No MIG partitioning — not for multi-tenant enterprise serving
+- 70B FP16 won't fit — need H200 (141GB) or multi-GPU
+- High-batch throughput — H100 SXM wins at maximum concurrency (3.35 TB/s HBM3)
+
+** Strategic Assessment
+
+For a personal/enthusiast rack-mounted setup:
+
+*Pros:*
+- 96GB VRAM covers 95% of practical local LLM use cases
+- Single-GPU simplicity (no multi-GPU orchestration)
+- Blackwell FP4 support (doubles throughput vs FP8)
+- Lower cost per token than H100 for 30B workloads
+- ECC memory for reliability
+
+*Cons:*
+- No upgrade path beyond 96GB (no NVLink)
+- GDDR7 bandwidth (1.792 TB/s) vs HBM3 (3.35 TB/s) matters at extreme concurrency
+- Workstation GPU, not datacenter (no MIG, no cluster integration)
+
+** Verdict
+
+The RTX Pro 6000 is the sweet spot for a *modular, upgradable* home lab. It won't match an 8x H100 cluster, but it doesn't need to. For single-user inference, development, and experimentation with models up to 70B parameters, it's the most practical high-VRAM option available.
+
+** Sources
+
+- Spheron Network: "NVIDIA RTX PRO 6000 Blackwell for AI" (March 2026)
+- CloudRift: "RTX 4090 vs RTX 5090 vs RTX PRO 6000: Comprehensive LLM Inference Benchmark" (Oct 2025)
+- Medium/Data Science Collective: "Benchmarking LLM Inference on NVIDIA B200, H200, H100, and RTX PRO 6000" (Feb 2026)
+
+** Related
+
+- [[file:20260313_gemini_embedding_2.org][Gemini Embedding-2 Research]]
+- [[file:20260311_agora_v2_gap_analysis.org][Agora v2 Gap Analysis]]

notes/README.org

@@ -0,0 +1,9 @@
+#+TITLE: Atomic Notes (Zettelkasten)
+#+AUTHOR: User
+#+CREATED: [2026-03-17 Tue]
+#+BEGIN_COMMENT
+Evergreen, atomic notes. Each file represents a single concept, is heavily interlinked, and uses snake_case filenames without dates.
+#+END_COMMENT
+
+* Atomic Notes (Zettelkasten)
+Evergreen, atomic notes. Each file represents a single concept, is heavily interlinked, and uses snake_case filenames without dates.

notes/android-git-clients.org

@@ -0,0 +1,132 @@
+#+TITLE: Modern Android Git Clients
+#+author: User
+#+created: [2026-03-16 Mon 14:28]
+#+DATE: 2026-03-06
+#+FILETAGS: :tools:git:android:sync
+
+* Android Git Client Options for ~/mind Sync
+
+** Recommendation: GitJournal ⭐ (Best for Org-Mode)
+
+*** Overview
+- *Purpose-built for note-taking* with Git sync
+- *Offline-first* - Works without connectivity
+- *Built with Flutter* - Modern, actively maintained (last update ~2 months ago)
+- *Open source / FOSS* - GitHub: GitJournal/GitJournal
+- *Works with any Git host* - GitHub, GitLab, self-hosted via SSH
+
+*** Key Features for Org-Mode
+- ✅ Markdown and Org-mode support (experimental)
+- ✅ Folder-based organization
+- ✅ Auto-sync to Git repository
+- ✅ Works offline, syncs when connected
+- ✅ No account required
+- ✅ No ads
+
+*** Installation
+- Google Play: https://play.google.com/store/apps/details?id=io.gitjournal.gitjournal
+- F-Droid: Available
+- GitHub: https://github.com/GitJournal/GitJournal
+
+*** Setup for ~/mind
+1. Clone ~/mind repo via SSH: `git@your-host:~/mind.git`
+2. Set up auto-sync (on save or manual)
+3. Edit org files in GitJournal
+4. Changes auto-committed and pushed
+
+*** Pros
+- Designed specifically for this workflow
+- Excellent for org-mode notes
+- Two-way sync with conflict handling
+- Active development (Flutter-based)
+- Works with any Git provider (not just GitHub)
+
+*** Cons
+- Org-mode support flagged as "experimental"
+- May need Termux for advanced Git operations
+- Simpler than full Git client
+
+---
+
+** Alternative: Termux (Most Powerful)
+
+*** Overview
+- *Full Linux terminal on Android*
+- *Complete Git command line*
+- Supports SSH, git-lfs, submodule
+
+*** Installation
+```bash
+# From F-Droid
+pkg install git openssh
+```
+
+*** Setup for ~/mind
+```bash
+# In Termux
+cd ~
+git clone ssh://user@your-host/path/to/mind.git
+# Edit with any text editor
+# Git commands for commit/push/pull
+```
+
+*** Pros
+- Full Git functionality
+- Works with orgzly (edit files, use Termux for Git)
+- SSH agent support
+- Most powerful option
+
+*** Cons
+- Command line only
+- More complex workflow
+- Requires context switching between apps
+
+---
+
+** Comparison Matrix
+
+| Feature | GitJournal | Termux |
+|---------|------------|--------|
+| UI | GUI app | Terminal |
+| Org-mode | Experimental, but works | Full support |
+| Offline | ✅ Yes | ✅ Yes |
+| Auto-sync | ✅ Built-in | Manual/script |
+| SSH Keys | ✅ Supported | ✅ Supported |
+| Conflict handling | ✅ Yes | Manual merge |
+| Learning curve | Low | Medium |
+| Best for | Daily notes sync | Power users |
+
+---
+
+** Recommendation
+
+*For your use case (org-mode + ~/mind):*
+
+🥇 *Try GitJournal first*
+- Purpose-built for note-taking with Git
+- Should handle basic org-mode editing
+- Auto-sync reduces friction
+- Can fall back to Termux if needed
+
+🥈 *Keep Termux as backup*
+- For complex Git operations
+- For merge conflict resolution
+- For full org-mode editing features
+
+---
+
+** Next Steps
+
+1. Install GitJournal from Play Store
+2. Clone ~/mind via SSH
+3. Test org-mode editing
+4. Set up auto-sync
+5. If issues, use GitJournal + Termux hybrid
+
+** Fallback:**
+If GitJournal org-mode support isn't sufficient:
+- Use *GitJournal* for sync
+- Use *Orgzly* for editing
+- Use *Termux* for Git operations
+
+Three-app workflow but each optimized for its task.

notes/closos_attributed_object_store.org

@@ -0,0 +1,18 @@
+#+TITLE: CLOSOS: Attributed Object Store
+#+ID: closos-attributed-object-store
+#+DATE: 2026-03-22
+#+FILETAGS: :architecture:lisp:os:closos:database:
+
+* Concept
+The traditional hierarchical file system (folders and files) is replaced by a system-wide database of objects retrieved via key/value attributes.
+
+* Key Principles
+- **Attribute-Based Retrieval:** Objects are not "located" in a path but retrieved via metadata (e.g., `:author`, `:date`, `:category`).
+- **Semantic Storage:** Data maintains its structural meaning. A "Note" or "Document" is a Lisp object, not just a raw byte stream.
+- **Directories as Objects:** Directories are simply specialized objects containing a list of object entries and their attributes, allowing for non-hierarchical organization where one directory can store another.
+
+* Source
+:PROPERTIES:
+:ID:       9c69a9ab-1c96-490e-9a8e-fbeafacba30e
+:END:
+- [[attachment:strandh-lispos.pdf][Robert Strandh, "CLOSOS: Specification of a Lisp operating system" (2013)]]

notes/closos_memory_persistence.org

@@ -0,0 +1,18 @@
+#+TITLE: CLOSOS: Persistence by Default (Single Memory Abstraction)
+#+ID: closos-memory-persistence
+#+DATE: 2026-03-22
+#+FILETAGS: :architecture:lisp:os:closos:persistence:
+
+* Concept
+CLOSOS eliminates the distinction between volatile primary memory (RAM) and permanent secondary memory (Disk). Primary memory functions as a transparent cache for a persistent object store.
+
+* Key Principles
+- **The Living Image:** The system state is permanent. "Saving" is not an explicit user action; changes are inherently persistent in the object store.
+- **Undo Facility:** Since data is permanent, application writers are encouraged to implement sophisticated undo/redo facilities rather than manual file saves.
+- **Atomic Snapshots:** High-integrity state is maintained via atomic flips and log-structured techniques, ensuring the system can recover from crashes without data loss.
+
+* Source
+:PROPERTIES:
+:ID:       9c69a9ab-1c96-490e-9a8e-fbeafacba30e
+:END:
+- [[attachment:strandh-lispos.pdf][Robert Strandh, "CLOSOS: Specification of a Lisp operating system" (2013)]]

notes/closos_multiple_environments.org

@@ -0,0 +1,18 @@
+#+TITLE: CLOSOS: Multiple Simultaneous Environments
+#+ID: closos-multiple-environments
+#+DATE: 2026-03-22
+#+FILETAGS: :architecture:lisp:os:closos:security:
+
+* Concept
+CLOSOS supports multiple simultaneous global environments, where an environment is a mapping from names to objects (functions, classes, packages).
+
+* Key Principles
+- **Isolation by Scope:** Each user or process can operate in a private environment. Redefining a system function (like `print-object`) in one environment does not affect other users.
+- **Dynamic Adaptability:** Facilitates safe experimentation with new features without risking system-wide corruption.
+- **Late Binding:** References are resolved against the current environment at compile/load time, enabling live updates and hot-reloading.
+
+* Source
+:PROPERTIES:
+:ID:       9c69a9ab-1c96-490e-9a8e-fbeafacba30e
+:END:
+- [[attachment:strandh-lispos.pdf][Robert Strandh, "CLOSOS: Specification of a Lisp operating system" (2013)]]

notes/closos_protection_mechanisms.org

@@ -0,0 +1,18 @@
+#+TITLE: CLOSOS: Language-Based Protection Mechanisms
+#+ID: closos-protection-mechanisms
+#+DATE: 2026-03-22
+#+FILETAGS: :architecture:lisp:os:closos:security:
+
+* Concept
+Security in a Lisp OS is enforced by the compiler and runtime environment rather than traditional hardware MMU (Memory Management Unit) boundaries.
+
+* Key Principles
+- **Controlled Access System:** The system is "closed" by the compiler. Only code produced by the trusted compiler—which excludes arbitrary pointer arithmetic and includes bounds checking—is allowed to execute in supervisor mode.
+- **Tagged Pointers:** Objects are manipulated via tagged pointers. Access rights (read/write/execute) can be embedded directly into the tag bits of the pointer itself.
+- **Capabilities:** Pointers function as capabilities. Possession of a pointer to an object implies the authority to interact with it according to the embedded access tags.
+
+* Source
+:PROPERTIES:
+:ID:       9c69a9ab-1c96-490e-9a8e-fbeafacba30e
+:END:
+- [[attachment:strandh-lispos.pdf][Robert Strandh, "CLOSOS: Specification of a Lisp operating system" (2013)]]

notes/closos_single_address_space.org

@@ -0,0 +1,18 @@
+#+TITLE: CLOSOS: Single Address Space Architecture
+#+ID: closos-single-address-space
+#+DATE: 2026-03-22
+#+FILETAGS: :architecture:lisp:os:closos:
+
+* Concept
+In a Lisp Operating System (CLOSOS), all applications and the system kernel share one large, unified 64-bit address space. 
+
+* Key Principles
+- **Removal of IPC:** Standard Unix-style Inter-Process Communication (pipes, sockets) is replaced by global pointer sharing. Applications communicate by passing pointers to objects directly.
+- **Unified Memory:** Eliminates the overhead of data serialization/deserialization between isolated process boundaries.
+- **Language-Based Security:** Protection is not enforced by hardware MMU boundaries but by the Lisp compiler and runtime (e.g., strong typing, bounds checking, no arbitrary pointer arithmetic).
+
+* Source
+:PROPERTIES:
+:ID:       9c69a9ab-1c96-490e-9a8e-fbeafacba30e
+:END:
+- [[attachment:strandh-lispos.pdf][Robert Strandh, "CLOSOS: Specification of a Lisp operating system" (2013)]]

notes/content-strategy.org

@@ -0,0 +1,67 @@
+#+TITLE: Content Strategy - OpenClaw
+#+author: User
+#+created: [2026-03-16 Mon 14:28]
+#+DATE: 2026-03-08
+#+FILETAGS: :content:marketing:revenue
+
+* Daily Content Pillars
+
+** Monday: Model Research
+- Compare new models/providers
+- Update OpenClaw config recommendations
+- Budget optimization tips
+
+** Tuesday: Setup Tutorial
+- How to configure OpenClaw for specific use case
+- Skill development
+- Integration walkthroughs
+
+** Wednesday: Automation Spotlight
+- Real automation examples
+- Bot workflows
+- Webhook integrations
+
+** Thursday: Use Case Study
+- Real-world OpenClaw applications
+- ROI calculations
+- Before/after workflows
+
+** Friday: Tips & Tricks
+- Quick productivity wins
+- Hidden features
+- Config optimizations
+
+** Weekend: Community & Reflection
+- Weekly wins
+- User questions answered
+- Industry trends
+
+* Content Formats
+
+** Short (Twitter/X)
+- 1-2 sentences
+- One command or tip
+- Visual: Terminal screenshot
+
+** Medium (Thread)
+- 5-10 tweets
+- Step-by-step guide
+- Link to detailed post
+
+** Long (Blog/Newsletter)
+- 500-800 words
+- Complete tutorial
+- With code examples
+
+* Immediate Actions (This Week)
+
+TODO  Write 10 OpenClaw tips
+TODO  Create first newsletter issue
+TODO  Set up GitHub repo with samples
+TODO  Draft Gumroad product page
+
+* Metrics
+
+- Followers: Target 100 by end of March
+- Newsletter: Target 50 subscribers by end of March
+- Engagement: 5% on Twitter, 20% on newsletter

notes/github-repos.org

@@ -0,0 +1,33 @@
+#+TITLE: GitHub Repositories & External References
+#+author: User
+#+created: [2026-03-16 Mon 14:28]
+#+DATE: 2026-03-04
+#+FILETAGS: :reference:github:repos:external
+
+* GitHub Repositories Tracker
+
+** Template
+
+| Repo URL | Description | Category | Date Added | Status |
+|----------|-------------|----------|------------|--------|
+| | | | | |
+
+** Categories
+- sales-automation
+- linkedin-tools
+- content-monetization  
+- api-integrations
+- ai-agents
+- automation-scripts
+- data-scrapers
+- browser-extensions
+
+** Currently Tracked
+
+*None yet - awaiting X bookmark analysis*
+
+** Notes
+- Sync with ~/mind/6_projects/revenue-sustainability/
+- Cross-reference with skills being built
+- Check licenses before using code
+- Credit sources appropriately

notes/homebrew.org

@@ -0,0 +1,61 @@
+#+TITLE: Homebrew Package Manager
+#+author: User
+#+created: [2026-03-16 Mon 14:28]
+#+DATE: 2026-03-04
+#+FILETAGS: :tools:package-manager:brew
+
+* Homebrew
+:PROPERTIES:
+:ID: 20260304-homebrew
+:CREATED: [2026-03-04 Tue]
+:END:
+
+** Installation
+
+Homebrew installed locally in `~/.linuxbrew/` (Linux user-space installation).
+
+```bash
+# Clone Homebrew
+git clone --depth=1 https://github.com/Homebrew/brew ~/.linuxbrew
+
+# Add to shell
+eval "$(~/.linuxbrew/bin/brew shellenv)"
+```
+
+** Configuration
+
+Added shell integration:
+- ~/.bashrc: `eval "$("$HOME"/linuxbrew/bin/brew shellenv)"`
+- OpenClaw config: `shellEnvExtra` includes brew initialization
+
+** Commands
+
+| Command | Purpose |
+|---------|---------|
+| `brew install <formula>` | Install a package |
+| `brew search <term>` | Search for packages |
+| `brew list` | List installed packages |
+| `brew update` | Update Homebrew itself |
+| `brew upgrade` | Upgrade installed packages |
+
+** Usage in OpenClaw
+
+Skills can now declare Homebrew-based dependencies:
+
+```yaml
+metadata:
+  openclaw:
+    requires:
+      bins: ["emacs", "jq", "ripgrep"]
+    install:
+      - id: homebrew
+        kind: brew
+        formula: emacs
+        bins: ["emacs"]
+```
+
+** Notes
+
+- No sudo required (user-space install)
+- Formulas may build from source (slower than bottles)
+- See https://formulae.brew.sh for available packages

notes/learning-from-failure-pinchtab.org

@@ -0,0 +1,95 @@
+#+TITLE: Learning From Failure: The PinchTab Security Incident
+#+author: User
+#+created: [2026-03-16 Mon 14:28]
+#+DATE: 2026-03-08
+#+FILETAGS: :failure:security:learning
+
+* The Failure
+
+** What Happened
+User asked me to critically analyze three browser automation tools (PinchTab, Camofox, Unbrowse) and recommend the best path forward. Instead of rigorous security analysis, I:
+
+1. Accepted PinchTab's marketing claims at face value
+2. Recommended installing a 12MB precompiled binary via `curl | bash`
+3. Failed to verify: source code availability, signing/verification, supply chain integrity, security audits
+4. Did not question the suspicious "stealth injection" terminology
+5. Did not compare against verifiable open-source alternatives
+
+** Why It Was Wrong
+- Mystery binary from relatively unknown publisher
+- "Stealth" features imply modifying browser internals (red flag for both ethics and detection)
+- Multiple GitHub forks (ZEMLYANINYA, prayedbeto) suggests supply chain confusion
+- No GPG signatures, no checksums, no security audit published
+- Full Chrome CDP access + HTTP API = complete browser control over network
+- Could have achieved same efficiency gains via existing Playwright/CDP infrastructure
+
+** What Should Have Happened
+1. Verify binary source (is it actually Go? can I build from source?)
+2. Check for security audits, CVEs, corporate backing
+3. Question "stealth injection"—what does it actually do? is it ethical/legal?
+4. Compare against established alternatives (Browser-use, Playwright direct, ScrapeGraphAI)
+5. Prefer auditable source code over mystery binaries
+6. Document risk analysis before ANY security-sensitive recommendation
+
+* Root Cause Analysis
+
+** Cognitive Failures
+- Pattern-matched to "efficiency" language without critical evaluation
+- Failed to apply first-principles security analysis
+- Did not recognize "curl | bash" as a major security anti-pattern
+- Let enthusiasm for solution override due diligence
+- Did not surface uncertainty ("I haven't verified this binary's provenance")
+
+** System Failures
+- No established security review checklist
+- No mandatory "pause and verify" rule for executable recommendations
+- No pattern for questioning suspicious terminology like "stealth"
+- Failed to apply existing SOUL.md rule: "Think from first principles"
+
+* The Correction
+
+** Revised Recommendation
+Instead of PinchTab (unverified binary), either:
+1. Enhance existing OpenClaw browser tool with accessibility tree extraction (via Playwright Python)
+2. Use browser-use (19k stars, MIT license, auditable Python source)
+3. Use established Playwright directly with CDP enhancements
+
+All achieve ~5x token efficiency without mystery binaries.
+
+** Security Principles Established
+1. *Never recommend executing unknown binaries*
+2. *Verify provenance before trusting any tool*
+3. *Prefer auditable source code over precompiled binaries*
+4. *Question suspicious terminology* ("stealth", "injection", "undetectable")
+5. *Document risk analysis* for security-sensitive recommendations
+6. *Surface uncertainty* rather than feign confidence
+
+* Integration Into Workflow
+
+** For Future Tool Evaluations
+TODO  Is source code auditable?
+TODO  Who is the publisher? What's their reputation?
+TODO  Are there security audits? CVE history?
+TODO  How is it distributed? (curl | bash = red flag)
+TODO  What permissions does it require?
+TODO  Are there established alternatives with better provenance?
+TODO  Document risk analysis explicitly
+
+** For Security-Sensitive Recommendations
+- State confidence level explicitly ("I have not verified this")
+- Provide alternatives with different risk profiles
+- Wait for user authorization before any executable recommendation
+- Never assume "convenience" outweighs security
+
+* Meta-Learning
+
+** Habit Established
+After every significant mistake:
+1. Acknowledge failure specifically (what, why, impact)
+2. Root cause analysis (cognitive + system failures)
+3. Correction (what should have happened)
+4. Integration (new rules/checklists)
+5. Record in memex for future reference
+
+** Verification
+This document will be checked by user. Pattern should repeat for all significant failures.

notes/llm-alternative-providers.org

@@ -0,0 +1,64 @@
+#+TITLE: Alternative LLM Providers - Subscription & Token Efficient
+#+author: User
+#+created: [2026-03-16 Mon 14:28]
+#+DATE: 2026-03-07
+#+FILETAGS: :research:llm:pricing:alternatives
+
+* GLM-5 (Zhipu AI) - Research
+
+** Pricing Found
+- Input: $1.00 per 1M tokens
+- Output: $3.20 per 1M tokens
+- Context: ~744B parameters, MoE architecture
+- Training: 28.5T tokens
+
+** Comparison to Current
+| Model | Input Cost | Output Cost | Context | Free Tier |
+|-------|-----------|-------------|---------|-----------|
+| Gemini 2.0 | $0 | $0 | 1M | ✅ Yes |
+| GLM-5 | $1.00 | $3.20 | ? | ? |
+| Claude | $3.00 | $15.00 | 200K | ❌ No |
+| GPT-4 | varies | varies | 128K | ❌ No |
+
+** Status: Still researching subscription/unlimited plans
+
+* Alternative Providers to Research
+
+** Tier 1: Subscription/Unlimited
+1. *Fireworks AI* - Flat-rate inference
+2. *Together AI* - Pay-per-token but high limits
+3. *Replicate* - Metered but competitive
+4. *Groq* - Ultra-fast, low cost
+
+** Tier 2: Self-Hosted (One-time cost)
+1. *RunPod* - GPU rental for local models
+2. *Lambdalabs* - GPU cloud
+3. *Local inference* - RTX 4090, etc.
+
+** Tier 3: Open Source Providers
+1. *Ollama* + RunPod/Lambda
+2. *llama.cpp* quantized models
+3. *vLLM* serving framework
+
+* Research Questions
+
+1. Does GLM-5 offer unlimited subscription tier?
+2. What about Fireworks/Together flat-rate plans?
+3. AWS Bedrock with flat-rate (Amazon Q)?
+4. Self-hosted llama3 70B vs GLM-5 quality?
+
+* Next Steps Needed
+
+- Manual research required (web browsing limited)
+- Check Zhipu pricing page directly
+- Compare subscription tiers
+- Evaluate self-hosting break-even
+
+* Current Recommendation
+
+*Until research complete:*
+- Stay on Gemini (free tier) ✅
+- Use sparingly to avoid 60/minute rate limit
+- 300K tokens/day = ~9M tokens/month free
+
+*If need more than 9M/month:* Evaluate paid tiers

notes/memex-template-pack/GUMROAD-SALES-PAGE.md

@@ -0,0 +1,70 @@
+# Memex Template System
+
+## Professional PKM for Emacs + Org-Mode Users
+
+Stop losing ideas. Start building a second brain.
+
+---
+
+### What You Get
+
+**The complete memex system** used by AI agents and knowledge workers:
+
+✓ PARA folder structure (Projects, Areas, Resources, Archive)  
+✓ Atomic Notes (Atomic Notes (Zettelkasten)) workflow (Capture → Connect → Create)  
+✓ GTD task management (@INBOX, @TODAY, @NEXT, @WAITING)  
+✓ 10+ templates for daily notes, meetings, projects  
+✓ org-roam compatible with unique IDs  
+✓ Free lifetime updates
+
+---
+
+### Who It's For
+
+- Emacs users who want a proven PKM system
+- Knowledge workers managing multiple projects
+- Writers, researchers, developers
+- Anyone tired of scattered notes
+
+---
+
+### System Requirements
+
+- Emacs 27+ with org-mode
+- org-roam (for linking)
+- org-gtd (optional)
+
+---
+
+### The Structure
+
+```
+memex/
+├── 0_inbox/         # CAPTURE (process daily)
+├── 1_thinking/      # Atomic Notes (Atomic Notes (Zettelkasten)) notes
+│   ├── dailies/     # Daily logs
+│   └── notes/       # Permanent notes
+├── 2_reference/     # External knowledge
+├── 3_creating/      # Work in progress
+├── 4_published/     # Finished output
+├── 5_archive/       # Inactive items
+├── 6_projects/      # Active projects
+└── 7_system/        # Templates & config
+```
+
+---
+
+### 30-Day Money-Back Guarantee
+
+Not working for you? Full refund. No questions.
+
+---
+
+**$20** — One-time purchase  
+Instant digital download
+
+[Buy Now][$20]
+
+---
+
+*Used by AI agents at OpenClaw. Built for humans who think.*

notes/memex-template-pack/README.md

@@ -0,0 +1,42 @@
+# Memex Template System
+
+A complete Personal Knowledge Management (PKM) system based on PARA, Atomic Notes (Atomic Notes (Zettelkasten)), and GTD methodologies using Org-mode.
+
+## What's Included
+
+### 1. PARA Structure
+- **Projects** (collection/) — Active work with deadlines
+- **Areas** (collection/) — Ongoing responsibilities  
+- **Resources** (collection/) — Reference material
+- **Archive** (collection/) — Inactive items
+
+### 2. Atomic Notes (Atomic Notes (Zettelkasten)) Flow
+- **Capture** → collection/
+- **Process** → Daily review
+- **Connect** → Use org-roam IDs
+- **Create** → collection/
+- **Archive** → collection/
+
+### 3. GTD Integration
+- @INBOX: collection/
+- @TODAY: Agendas
+- @NEXT: Context lists
+- @WAITING: Delegated
+- @SOMEDAY: Future ideas
+
+### 4. Templates
+- Daily notes
+- Meeting agendas
+- Project planning
+- Reference capture
+- Weekly reviews
+
+## Requirements
+
+- Emacs with org-mode
+- org-roam (for linking)
+- org-gtd (optional, for GTD)
+
+## Price: $20
+
+Professional grade PKM system. One-time purchase. Free updates.

notes/openclaw-consulting.org

@@ -0,0 +1,63 @@
+#+TITLE: OpenClaw Consulting Services
+#+author: User
+#+created: [2026-03-16 Mon 14:28]
+#+DATE: 2026-03-08
+#+FILETAGS: :services:offering:revenue
+
+* OpenClaw Setup & Configuration
+
+** What You Get
+- Complete OpenClaw installation and configuration
+- Signal integration with your existing setup
+- Custom skills based on your workflows
+- GitOps pipeline setup (Gitea/webhook integration)
+- Documentation and handover
+
+** Pricing
+- Basic Setup: $150 (2-3 hours)
+- Advanced Setup: $250 (4-6 hours)
+- Enterprise: Custom quote
+
+** Deliverables
+- Working OpenClaw installation
+- Configured Signal channel
+- Custom skill development
+- Git repository with your configs
+- 30-day support
+
+** Ideal For
+- Solopreneurs wanting automated workflows
+- Developers building AI-powered tools
+- Teams needing Signal/CLI integration
+- Anyone wanting their own AI agent
+
+** Contact
+- Email: user@example.com
+- Signal: +14107054317
+
+---
+
+* Automation Script Development
+
+** Services
+- Webhook automation
+- GitOps pipelines
+- Custom OpenClaw skills
+- API integrations
+- Signal bot development
+
+** Pricing
+- Simple scripts: $50-100
+- Medium complexity: $100-200
+- Complex systems: $200-500
+- Ongoing support: $50/hour
+
+** Process
+1. Discovery call (15 min, free)
+2. Scope definition & quote
+3. Development
+4. Delivery & documentation
+5. 30-day support
+
+** Contact
+- Same as above

notes/openclaw-setup-guide.org

@@ -0,0 +1,86 @@
+#+TITLE: OpenClaw Setup Guide - Complete Walkthrough
+#+author: User
+#+created: [2026-03-16 Mon 14:28]
+#+DATE: 2026-03-08
+#+FILETAGS: :tutorial:openclaw:setup
+
+* The 15-Minute OpenClaw Setup
+
+** Prerequisites
+
+- Linux/macOS machine (ARM64 or x64)
+- Node.js 18+ installed
+- Git configured
+
+** Step 1: Install OpenClaw
+
+#+BEGIN_SRC bash
+npm install -g openclaw
+openclaw doctor
+#+END_SRC
+
+This checks your system and suggests fixes.
+
+** Step 2: Configure Signal (Optional but Recommended)
+
+OpenClaw works great with Signal for secure messaging.
+
+1. Install signal-cli: https://github.com/AsamK/signal-cli
+2. Link your phone: signal-cli link -n "OpenClaw"
+3. Configure OpenClaw to use it
+
+** Step 3: Set Up Your Workspace
+
+#+BEGIN_SRC bash
+mkdir -p ~/.openclaw/workspace
+cd ~/.openclaw/workspace
+git init
+#+END_SRC
+
+Add these files:
+- SOUL.md — who you are
+- USER.md — who you're helping
+- AGENTS.md — your workflow rules
+
+** Step 4: Connect to AI Models
+
+Edit ~/.openclaw/openclaw.json:
+
+Set your primary model (Gemini is free):
+#+BEGIN_SRC json
+{
+  "agents": {
+    "defaults": {
+      "model": {
+        "primary": "google-gemini-cli/gemini-2.0-flash"
+      }
+    }
+  }
+}
+#+END_SRC
+
+** Step 5: Test Your Setup
+
+Send a message to your Signal number or run:
+#+BEGIN_SRC bash
+openclaw status
+#+END_SRC
+
+** Next Steps
+
+- Set up skills for repeated tasks
+- Configure GitOps workflow
+- Add sub-agent capabilities
+
+* Common Issues
+
+** "Command not found"
+Add to ~/.bashrc:
+export PATH="$PATH:$(npm bin -g)"
+
+** Signal not connecting
+Check signal-cli is running:
+signal-cli daemon
+
+** Model errors
+Verify your API keys are set in ~/.openclaw/openclaw.json

notes/openclaw-tips.org

@@ -0,0 +1,45 @@
+#+TITLE: 10 OpenClaw Tips for Daily Use
+#+author: User
+#+created: [2026-03-16 Mon 14:28]
+#+DATE: 2026-03-08
+#+FILETAGS: :content:tips
+
+* Tip 1: Use memory_search before every memory-dependent task
+
+Always search your memory bank before answering questions about prior work. This maintains continuity and prevents re-asking.
+
+* Tip 2: Batch similar operations to reduce token burn
+
+Group file reads, web searches, and git operations. Each tool call has overhead—combine them.
+
+* Tip 3: Create skills for repeated workflows
+
+If you do the same task 3+ times, make it a skill. Future-you will thank you.
+
+* Tip 4: Use subagents for parallel tasks
+
+Spawn subagents for independent work. You handle 4-8 concurrently. Don't let tasks block.
+
+* Tip 5: Heartbeat is for batches, cron is for schedules
+
+Heartbeat = check multiple things in context. Cron = exact timing or isolation. Choose wisely.
+
+* Tip 6: Commit before every edit
+
+Use `git commit` before and after changes. Traceability beats speed.
+
+* Tip 7: Use browser automation carefully
+
+Browser snapshots are powerful but expensive. Web fetch is cheaper for reading. Match tool to task.
+
+* Tip 8: Platform formatting matters
+
+No tables on Discord/WhatsApp. Wrap Discord links in `< >`. Know your audience.
+
+* Tip 9: Gateway config changes are immediate
+
+Every `gateway config.patch` restarts the system. Plan accordingly.
+
+* Tip 10: Silence costs nothing
+
+Use `NO_REPLY` when you have nothing to say. Quality over quantity.

notes/proof_of_work_vs_stake.org

@@ -0,0 +1,30 @@
+#+TITLE: Proof of Work vs Proof of Stake
+#+ID: 0450c91b-55a5-4bcc-9bc2-2478d983be3c
+
+* Proof of Work vs Proof of Stake
+
+** Core Concepts
+
+- **Proof of Work (PoW):** Uses computational energy as the primary mechanism for Sybil resistance and achieving consensus.
+- **Proof of Stake (PoS):** Uses capital at risk (staked tokens) to achieve the same goal.
+
+** Fundamental Differences
+
+| Aspect | Proof of Work | Proof of Stake |
+|--------|---------------|----------------|
+| Foundation | Physics (energy) | Economics (capital) |
+| Sybil Resistance | Computational cost | Financial stake at risk |
+| Resource Required | Hardware/energy | Capital/tokens |
+
+** Open Question
+
+PoW may be more fundamentally grounded in physics, while PoS is grounded in economics. Further exploration needed on the implications of this distinction.
+
+** Source
+
+- Captured as fleeting note on [[id:20260317T1100][2026-03-17]]
+- Originally part of daily blockchain consensus reading
+
+** See Also
+
+- #consensus #blockchain #energy-economics

notes/skill-agent-identity.org

@@ -0,0 +1,43 @@
+#+TITLE: Agent Identity Skill
+#+AUTHOR: org-agent
+#+SKILL_NAME: skill-agent-identity
+
+This skill defines the agent's identity, name, and persona. It acts as the "Self" concept for the Neurosymbolic Kernel.
+
+* Identity Definition
+We define the agent's name and persona here. This can be edited by the user or by the agent itself in Phase 3.
+
+#+begin_src lisp
+(defun get-agent-name ()
+  "Return the current name of the agent. Defaults to 'Agent'."
+  (or (org-agent::get-env "MEMEX_ASSISTANT") "Agent"))
+
+(defun get-agent-persona ()
+  "Return the behavioral instructions for the agent."
+  "You are a proactive Neurosymbolic Lisp Machine. Your goal is to assist the user with GTD, memory, and automation. You are concise, precise, and favor deterministic Lisp solutions over fuzzy neural guesses.")#+end_src
+
+* Trigger
+Triggers on identity-related questions.
+
+#+begin_src lisp
+(defun trigger-skill-agent-identity (context)
+  (let* ((payload (getf context :payload))
+         (text (or (getf payload :text) "")))
+    (or (search "who are you" text :test #'string-equal)
+        (search "identify yourself" text :test #'string-equal))))
+#+end_src
+
+* Neuro Prompt
+#+begin_src lisp
+(defun neuro-skill-agent-identity (context)
+  (format nil "The user asked about your identity. Explain who you are using this persona - ~a" (get-agent-persona)))
+#+end_src
+
+* Registration
+#+begin_src lisp
+(defskill :skill-agent-identity
+  :priority 100 ; Identity is a high-priority concept
+  :trigger #'trigger-skill-agent-identity
+  :neuro #'neuro-skill-agent-identity
+  :symbolic (lambda (action context) action))
+#+end_src

notes/skill-ast-normalization.org

@@ -0,0 +1,55 @@
+#+TITLE - AST Normalization Skill
+#+AUTHOR - org-agent
+#+SKILL_NAME - skill-ast-normalization
+
+This skill handles explicit user commands for AST refactoring, such as injecting missing IDs.
+
+* Trigger
+Triggers when a user requests to organize a subtree.
+
+#+begin_src lisp
+(defun trigger-skill-ast-normalization (context)
+  (let ((type (getf context :type))
+        (payload (getf context :payload)))
+    (and (eq type :EVENT)
+         (eq (getf payload :sensor) :user-command)
+         (eq (getf payload :command) :organize-subtree))))
+#+end_src
+
+* Neuro Prompt
+System 1 is bypassed if there's a deterministic action to take, but we provide a prompt just in case.
+
+#+begin_src lisp
+(defun neuro-skill-ast-normalization (context)
+  (format nil "User requested subtree organization. Context - ~a. Suggest an Org-mode action. Provide concise, high-fidelity suggestions in Lisp plist format." context))
+#+end_src
+
+* Symbolic Verification
+System 2 preempts System 1 if it finds a deterministic issue (like a missing ID).
+
+#+begin_src lisp
+(defun verify-skill-ast-normalization (proposed-action context)
+  (let* ((ast (getf (getf context :payload) :ast))
+         (missing-id (find-headline-missing-id ast)))
+    (if missing-id
+        (progn
+          (format t "System 2 - Missing ID detected, preempting System 1.~%")
+          `(:type :REQUEST :id ,(get-universal-time) 
+            :target :emacs
+            :payload (:action :refactor-subtree 
+                      :target-id nil 
+                      :properties (("ID" . ,(format nil "node-~a" (get-universal-time)))))))
+        ;; If no deterministic action, allow System 1's proposal to pass
+        proposed-action)))
+#+end_src
+
+* Registration
+Register the skill.
+
+#+begin_src lisp
+(defskill :skill-ast-normalization
+  :priority 100 ; High priority to preempt general skills
+  :trigger #'trigger-skill-ast-normalization
+  :neuro #'neuro-skill-ast-normalization
+  :symbolic #'verify-skill-ast-normalization)
+#+end_src

notes/skill-atomic-notes.org

@@ -0,0 +1,65 @@
+#+TITLE - Atomic Notes (Zettelkasten) Retrieval Skill (Sparse Tree)
+#+AUTHOR - org-agent
+#+SKILL_NAME - skill-atomic-notes
+
+This skill provides Deep Memory by performing sparse tree perception over ripgrep results. It reduces token waste by pruning irrelevant parts of the AST.
+
+* Trigger
+#+begin_src lisp
+(defun trigger-skill-atomic-notes (context)
+  (let ((type (getf context :type))
+        (payload (getf context :payload)))
+    (and (eq type :EVENT)
+         (eq (getf payload :sensor) :delegation)
+         (eq (getf payload :target-skill) :atomic-notes))))
+#+end_src
+
+* Neuro Prompt
+System 1 synthesizes an answer from a pruned, highly relevant Sparse AST.
+
+#+begin_src lisp
+(defun neuro-skill-atomic-notes (context)
+  (let* ((query (getf (getf context :payload) :query))
+         (memex-dir (org-agent::get-env "MEMEX_DIR" "/app/memex"))
+         ;; Search for files containing the query
+         (rg-cmd (format nil "rg -i -l '~a' ~a" query memex-dir))
+         (files (ignore-errors 
+                 (uiop:split-string 
+                  (uiop:run-program rg-cmd :output :string :ignore-error-status t)
+                  :separator '(#\Newline)))))
+    
+    ;; For the first 3 relevant files, build a Sparse Tree
+    (let ((sparse-trees nil))
+      (dolist (file (subseq files 0 (min 3 (length files))))
+        (when (and file (> (length file) 0))
+          ;; In a real Phase 3, we would look up the AST from the store.
+          ;; For this prototype, we'll note the file being indexed.
+          (push (format nil "FILE - ~a" file) sparse-trees)))
+      
+      (format nil "
+        You are the Atomic Notes (Zettelkasten) Memory synthesizer.
+        The user asked - '~a'
+        
+        SPARSE PERCEPTION (Relevant Files) -
+        ~a
+        
+        Synthesize an answer. If you need more detail from a specific file, 
+        ask the user to 'Focus' on that file.
+        Return a Lisp plist - (:target :emacs :action :message :text \"your answer\")
+      " query sparse-trees))))
+#+end_src
+
+* Symbolic Verification
+#+begin_src lisp
+(defun verify-skill-atomic-notes (proposed-action context)
+  proposed-action)
+#+end_src
+
+* Registration
+#+begin_src lisp
+(defskill :skill-atomic-notes
+  :priority 80
+  :trigger #'trigger-skill-atomic-notes
+  :neuro #'neuro-skill-atomic-notes
+  :symbolic #'verify-skill-atomic-notes)
+#+end_src

notes/skill-brain-mapper.org

@@ -0,0 +1,55 @@
+#+TITLE - Brain Mapper Skill
+#+AUTHOR - org-agent
+#+SKILL_NAME - skill-brain-mapper
+
+This skill allows the agent to visualize and reason about its own "Brain" by mapping the Skill Graph and analyzing performance telemetry.
+
+* Trigger
+Triggers on requests to see the agent's internal logic or skill network.
+
+#+begin_src lisp
+(defun trigger-skill-brain-mapper (context)
+  (let* ((payload (getf context :payload))
+         (text (or (getf payload :text) "")))
+    (or (search "show me your brain" text :test #'string-equal)
+        (search "skill graph" text :test #'string-equal)
+        (search "how do you think" text :test #'string-equal)
+        (search "optimize priorities" text :test #'string-equal))))
+#+end_src
+
+* Neuro Prompt
+System 1 describes the current hierarchy and identifies potential bottlenecks based on telemetry.
+
+#+begin_src lisp
+(defun neuro-skill-brain-mapper (context)
+  (let* ((skills (org-agent:context-list-all-skills))
+         ;; Gather telemetry for each skill
+         (telemetry (mapcar (lambda (s) 
+                              (let ((name (getf s :name)))
+                                (list :name name :stats (org-agent:context-get-skill-telemetry name))))
+                            skills)))
+    (format nil "
+      You are the Cognitive Architect of this Lisp Machine.
+      The user wants to see your current internal logic graph and performance.
+      
+      CURRENT SKILLS, PRIORITIES & TELEMETRY -
+      ~a
+      
+      TASK -
+      1. Explain your cognitive hierarchy. 
+      2. Identify any 'Heavy' skills (high total-time) or 'Failing' skills (high failures).
+      3. If a skill is underperforming, suggest a new priority to optimize the loop.
+      
+      Return a Lisp plist - (:target :emacs :action :message :text \"your analysis\")
+      If optimization is needed, also return a (:target :system :action :set-priority :skill \"...\" :priority N) action.
+    " telemetry)))
+#+end_src
+
+* Registration
+#+begin_src lisp
+(defskill :skill-brain-mapper
+  :priority 95 ; High priority meta-cognition
+  :trigger #'trigger-skill-brain-mapper
+  :neuro #'neuro-skill-brain-mapper
+  :symbolic (lambda (action context) action))
+#+end_src

notes/skill-chat.org

@@ -0,0 +1,60 @@
+#+TITLE: Agent Chat Skill
+#+AUTHOR: org-agent
+#+SKILL_NAME: skill-chat
+
+This skill provides a conversational interface within Emacs via the `*org-agent-chat*` buffer.
+
+* Trigger
+Triggers on direct chat messages from Emacs.
+
+#+begin_src lisp
+(defun trigger-skill-chat (context)
+  (let* ((payload (getf context :payload))
+         (sensor (getf payload :sensor)))
+    (eq sensor :chat-message)))
+#+end_src
+
+* Neuro Prompt
+System 1 acts as a conversational partner, using the agent's identity and persona.
+
+#+begin_src lisp
+(defun neuro-skill-chat (context)
+  (let* ((payload (getf context :payload))
+         (text (getf payload :text))
+         (identity-pkg (find-package :org-agent.skills.skill-agent-identity))
+         (persona-fn (when identity-pkg (find-symbol "GET-AGENT-PERSONA" identity-pkg)))
+         (persona (if (and persona-fn (fboundp persona-fn))
+                      (funcall persona-fn)
+                      "You are a helpful Lisp agent.")))
+    (format nil "
+      ~a
+      
+      The user is talking to you in a dedicated chat buffer.
+      CHAT HISTORY / CURRENT BUFFER -
+      ---
+      ~a
+      ---
+      
+      Provide a helpful, conversational response in Org-mode format.
+      Return a Lisp plist - (:target :emacs :action :insert-at-end :buffer \"*org-agent-chat*\" :text \"\\n** Agent\\n<your response>\\n\")
+    " persona text)))
+#+end_src
+
+* Symbolic Verification
+#+begin_src lisp
+(defun verify-skill-chat (proposed-action context)
+  "Ensure the chat response is properly targeted."
+  (if (and (eq (getf proposed-action :target) :emacs)
+           (eq (getf (getf proposed-action :payload) :action) :insert-at-end))
+      proposed-action
+      '(:target :emacs :action :message :text "Chat skill failed to format response correctly.")))
+#+end_src
+
+* Registration
+#+begin_src lisp
+(defskill :skill-chat
+  :priority 100 ; Chat is high-priority direct interaction
+  :trigger #'trigger-skill-chat
+  :neuro #'neuro-skill-chat
+  :symbolic #'verify-skill-chat)
+#+end_src

notes/skill-creator.org

@@ -0,0 +1,104 @@
+#+TITLE - Skill Creator (Reproductive System)
+#+AUTHOR - org-agent
+#+SKILL_NAME - skill-creator
+
+This skill allows the agent to autonomously generate new Org-Native skills. It implements the "Self-Editing OS" philosophy by using the Lisp compiler as a safety gate.
+
+* Trigger
+Triggers only when delegated to by the Router.
+
+#+begin_src lisp
+(defun trigger-skill-creator (context)
+  (let ((type (getf context :type))
+        (payload (getf context :payload)))
+    (and (eq type :EVENT)
+         (eq (getf payload :sensor) :delegation)
+         (eq (getf payload :target-skill) :skill-creator))))
+#+end_src
+
+* Neuro Prompt
+System 1 is tasked with drafting a complete Org-Native skill file.
+
+#+begin_src lisp
+(defun neuro-skill-creator (context)
+  "Generate a System 1 prompt for drafting a new skill, using self-awareness of existing hierarchy."
+  (let ((query (getf (getf context :payload) :query))
+        ;; Introspection - See what else the brain can do
+        (existing-skills (org-agent:context-list-all-skills)))
+    (format nil "
+      You are the Skill Creator for a Neurosymbolic Lisp Machine.
+      The user wants to teach the agent a new capability - '~a'
+      
+      CURRENT COGNITIVE HIERARCHY (Active Skills):
+      ~a
+      
+      Draft a COMPLETE Org-Native Skill file (.org).
+      
+      INSTRUCTIONS:
+      1. Assign a :priority integer. Negotiate this based on the existing hierarchy.
+         - Safety/Normalization should always be highest (100+).
+         - Logic/GTD should be medium (50-80).
+         - New creative capabilities should typically be lower (20-40).
+      
+      Structure:
+      - Title and Skill Name headers
+      - * Trigger block (Lisp)
+      - * Neuro Prompt block (Lisp)
+      - * Symbolic Verification block (Lisp)
+      - * Registration block (Lisp using defskill)
+      
+      Return a Lisp plist - (:target :system :action :create-skill :filename \"skill-name.org\" :content \"file content\")
+    " query existing-skills)))
+#+end_src
+
+* Symbolic Verification & Acquisition
+System 2 acts as the Gatekeeper. It extracts Lisp blocks, validates syntax, and handles acquisition.
+
+#+begin_src lisp
+(defun creator-extract-lisp-blocks (content)
+  "Extract Lisp source blocks from Org text."
+  (let ((results nil)
+        (lines (uiop:split-string content :separator '(#\Newline)))
+        (in-block nil)
+        (current-block ""))
+    (dolist (line lines)
+      (let ((clean (string-trim '(#\Space #\Tab #\Return) line)))
+        (cond
+         ((uiop:string-prefix-p "#+begin_src lisp" (string-downcase clean)) 
+          (setf in-block t))
+         ((uiop:string-prefix-p "#+end_src" (string-downcase clean)) 
+          (setf in-block nil)
+          (push current-block results)
+          (setf current-block ""))
+         (in-block (setf current-block (concatenate 'string current-block line (string #\Newline)))))))
+    (nreverse results)))
+
+(defun verify-skill-creator (proposed-action context)
+  "Validates new code syntax before delegating to the :system actuator."
+  (let* ((payload (getf proposed-action :payload))
+         (filename (getf payload :filename))
+         (content (getf payload :content))
+         (lisp-blocks (creator-extract-lisp-blocks content)))
+    
+    (kernel-log "KERNEL [Creator] Validating ~a~%" filename)
+    
+    (dolist (block lisp-blocks)
+      (multiple-value-bind (valid err) (org-agent:validate-lisp-syntax block)
+        (unless valid
+          (kernel-log "KERNEL [Creator] REJECTED ~a~%" err)
+          (return-from verify-skill-creator 
+            `(:target :emacs :action :message :text ,(format nil "Syntax error - ~a" err))))))
+    
+    ;; If syntax is valid, we return the proposed-action which targets :system.
+    ;; The core's execute-system-action will handle the file write and reload.
+    proposed-action)
+#+end_src
+
+* Registration
+#+begin_src lisp
+(defskill :skill-creator
+  :priority 70
+  :trigger #'trigger-skill-creator
+  :neuro #'neuro-skill-creator
+  :symbolic #'verify-skill-creator)
+#+end_src

notes/skill-cron.org

@@ -0,0 +1,87 @@
+#+TITLE - Cron Scheduler Skill
+#+AUTHOR - org-agent
+#+SKILL_NAME - skill-cron
+
+This skill hooks into the background heartbeat to provide autonomous temporal action, like checking for missed deadlines.
+
+* Trigger
+Triggers on every background heartbeat pulse.
+
+#+begin_src lisp
+(defun trigger-skill-cron (context)
+  (let ((type (getf context :type))
+        (payload (getf context :payload)))
+    (and (eq type :EVENT)
+         (eq (getf payload :sensor) :heartbeat))))
+#+end_src
+
+* Symbolic Pre-Processing & Neuro Prompt
+System 2 parses deadlines and only wakes up the LLM if a task is actually 
+overdue according to the current universal time.
+
+#+begin_src lisp
+(defun parse-org-timestamp (ts-str)
+  "Extract year, month, and day from an Org timestamp (e.g. <2026-03-24 Tue>) 
+   and return its universal-time representation."
+  (let ((match (nth-value 1 (cl-ppcre:scan-to-strings "<(\\d{4})-(\\d{2})-(\\d{2}).*>" ts-str))))
+    (if match
+        (encode-universal-time 0 0 0 
+                               (parse-integer (aref match 2)) 
+                               (parse-integer (aref match 1)) 
+                               (parse-integer (aref match 0)))
+        nil)))
+
+(defun neuro-skill-cron (context)
+  "Checks for deadlines and only wakes the LLM if action is needed."
+  (let* ((all-tasks (org-agent:context-query-store :todo-state "TODO" :type :HEADLINE))
+         (now (get-universal-time))
+         (overdue-tasks nil))
+    
+    (dolist (task all-tasks)
+      (let* ((attrs (org-agent:org-object-attributes task))
+             (deadline-str (getf attrs :DEADLINE))
+             (title (getf attrs :TITLE)))
+        (when deadline-str
+          (let ((deadline-time (parse-org-timestamp deadline-str)))
+            ;; Only consider it overdue if the deadline has actually passed
+            (when (and deadline-time (<= deadline-time now))
+              (push (format nil "[~a] Was due - ~a" title deadline-str) overdue-tasks))))))
+    
+    (if overdue-tasks
+        (let* ((all-delivery (mapcar (lambda (task) 
+                                       (getf (org-agent:org-object-attributes task) :DELIVERY))
+                                     all-tasks))
+               ;; Check if any overdue task specifically requested external delivery
+               (target (if (cl:some (lambda (d) (not (null d))) all-delivery) :delivery :emacs)))
+
+          (format nil "
+            You are the user's Executive Assistant.
+            The heartbeat monitor just woke you up.
+
+            The following tasks are officially OVERDUE:
+            ~a
+
+            Draft a very short, polite alert message to the user warning them about these deadlines.
+
+            Return a Lisp plist - (:target ~a :action :message :text \"your alert\")
+            If target is :delivery, make the message extra concise for a phone notification.
+          " overdue-tasks (if (eq target :delivery) ":delivery" ":emacs")))
+        nil)))
+#+end_src
+
+* Symbolic Verification
+Standard pass-through.
+
+#+begin_src lisp
+(defun verify-skill-cron (proposed-action context)
+  proposed-action)
+#+end_src
+
+* Registration
+#+begin_src lisp
+(defskill :skill-cron
+  :priority 60
+  :trigger #'trigger-skill-cron
+  :neuro #'neuro-skill-cron
+  :symbolic #'verify-skill-cron)
+#+end_src

notes/skill-emacs-bridge.org

@@ -0,0 +1,85 @@
+#+TITLE - Emacs Actuator Bridge Skill
+#+AUTHOR - org-agent
+#+SKILL_NAME - skill-emacs-bridge
+
+This skill provides the sensor (TCP Socket) and actuator (OACP Dispatch) for the Emacs interface. It abstracts the I/O layer away from the core `org-agent` kernel.
+
+* Sensor & State (TCP Socket Listener)
+We start a TCP server that listens for incoming connections from `org-agent.el`.
+
+#+begin_src lisp
+(defvar *emacs-server-thread* nil)
+(defvar *emacs-server-socket* nil)
+(defvar *active-emacs-clients* nil "List of active Emacs socket streams.")
+(defvar *emacs-clients-lock* (bt:make-lock "emacs-clients-lock"))
+
+(defun handle-emacs-client (stream)
+  "Handle a single OACP connection from Emacs."
+  (bt:with-lock-held (*emacs-clients-lock*)
+    (push stream *active-emacs-clients*))
+  (unwind-protect
+      (handler-case
+          (loop
+            (let* ((len-buf (make-string 6))
+                   (read-len (read-sequence len-buf stream)))
+              (when (zerop read-len) (return))
+              (let* ((msg-len (parse-integer len-buf :radix 16))
+                     (msg-buf (make-string msg-len)))
+                (read-sequence msg-buf stream)
+                (let ((plist (read-from-string msg-buf)))
+                  (org-agent:kernel-log "BRIDGE: Received message type ~a" (getf plist :type))
+                  ;; PROCESS: Send the message through the 4-stage cognitive loop
+                  (org-agent:cognitive-loop plist)))))
+        (error (c) (org-agent:kernel-log "BRIDGE ERROR: ~a" c)))
+    (bt:with-lock-held (*emacs-clients-lock*)
+      (setf *active-emacs-clients* (remove stream *active-emacs-clients*)))
+    (close stream)))
+
+(defun start-emacs-server (&key (port 9105))
+  "Start the OACP listener for Emacs."
+  (setf *emacs-server-socket* (usocket:socket-listen "0.0.0.0" port :reuse-address t))
+  (setf *emacs-server-thread* 
+        (bt:make-thread 
+         (lambda ()
+           (loop
+             (let ((conn (usocket:socket-accept *emacs-server-socket*)))
+               (bt:make-thread (lambda () (handle-emacs-client (usocket:socket-stream conn)))
+                               :name "org-agent-emacs-handler"))))
+         :name "org-agent-emacs-daemon"))
+  (org-agent:kernel-log "BRIDGE: Listening on port ~a" port))
+#+end_src
+
+* Actuator (Outbound Dispatcher)
+When the core `cognitive-loop` decides on an action targeting `:emacs`, it delegates to this function.
+
+#+begin_src lisp
+(defun broadcast-to-emacs (action-plist)
+  "Translate an action into OACP framing and send to all connected Emacs clients."
+  (let ((action-msg (org-agent:frame-message (prin1-to-string action-plist))))
+    (bt:with-lock-held (*emacs-clients-lock*)
+      (dolist (client *active-emacs-clients*)
+        (ignore-errors 
+         (write-string action-msg client)
+         (force-output client))))))
+#+end_src
+
+* Skill Registration
+Register the skill. We don't use `trigger`, `neuro`, or `symbolic` because this is an I/O skill, not a cognitive skill. We just use the file evaluation to bootstrap the server and register the actuator.
+
+#+begin_src lisp
+;; Register the actuator with the core Event Bus
+(org-agent:register-actuator :emacs #'broadcast-to-emacs)
+
+;; Register as a skill so it appears on the dashboard
+(defskill :skill-emacs-bridge
+  :priority 100
+  :trigger (lambda (context) nil)
+  :neuro (lambda (context) nil)
+  :symbolic (lambda (action context) action))
+
+;; Start the socket server when this skill is loaded by the daemon
+(let* ((env-port (uiop:getenv "ORG_AGENT_DAEMON_PORT"))
+       (port (if env-port (parse-integer env-port :junk-allowed t) 9105)))
+  (unless *emacs-server-thread*
+    (start-emacs-server :port port)))
+#+end_src

notes/skill-environment-config.org

@@ -0,0 +1,38 @@
+#+TITLE: Environment Configuration Skill
+#+AUTHOR: org-agent
+#+SKILL_NAME: skill-environment-config
+
+This skill provides a centralized API for retrieving configuration from Org-mode properties stored in the Memex. It follows the "Homoiconic Configuration" pattern, ensuring that the user's environment is defined entirely within their notes.
+
+* Logic
+#+begin_src lisp
+(defun get-config-attribute (property-key &optional default)
+  "Searches the global *object-store* for any headline containing PROPERTY-KEY."
+  (let ((store org-agent:*object-store*))
+    (maphash (lambda (id obj)
+               (declare (ignore id))
+               (when (eq (org-agent:org-object-type obj) :HEADLINE)
+                 (let ((val (getf (org-agent:org-object-attributes obj) property-key)))
+                   (when val
+                     (return-from get-config-attribute val)))))
+             store)
+    default))
+
+(defun get-tiered-model (tier default-model)
+  "Retrieves a model ID based on a tier keyword (:POWERFUL, :FAST, :FREE)."
+  (let ((prop (case tier
+                (:powerful :LLM_MODEL_POWERFUL)
+                (:fast     :LLM_MODEL_FAST)
+                (:free     :LLM_MODEL_FREE)
+                (t         :LLM_MODEL_TEXT))))
+    (get-config-attribute prop default-model)))
+#+end_src
+
+* Registration
+#+begin_src lisp
+(defskill :skill-environment-config
+  :priority 100 ; Foundational skill
+  :trigger (lambda (context) nil) ; No cognitive trigger
+  :neuro (lambda (context) nil)
+  :symbolic (lambda (action context) action))
+#+end_src

notes/skill-model-explorer.org

@@ -0,0 +1,62 @@
+#+TITLE: Model Explorer Skill
+#+AUTHOR: org-agent
+#+SKILL_NAME: skill-model-explorer
+
+This skill dynamically discovers all loaded LLM provider skills and lists their available models. It intercepts the `@agent list models` command and renders an Org-mode table.
+
+* Trigger Logic
+#+begin_src lisp
+(defun trigger-skill-model-explorer (context)
+  (let* ((payload (getf context :payload))
+         (sensor (getf payload :sensor))
+         (text (or (getf payload :text) "")))
+    (and (eq sensor :buffer-update)
+         (search "@agent list models" text :test #'string-equal))))
+#+end_src
+
+* Symbolic Execution
+Because this is a purely deterministic retrieval task, it completely bypasses the LLM (System 1) and executes entirely in the Symbolic (System 2) layer.
+
+#+begin_src lisp
+(defun build-org-table-for-models ()
+  "Introspects all skills to find providers and builds an Org-mode table string."
+  (let ((table-rows (list "| Provider | Model ID | Context |"
+                          "|----------+----------+---------|")))
+    ;; Iterate through all loaded skills in the kernel
+    (maphash (lambda (name skill)
+               (when (uiop:string-prefix-p "SKILL-PROVIDER-" (string-upcase name))
+                 ;; Extract the provider name cleanly (e.g., "OPENAI")
+                 (let* ((provider-name (subseq (string-upcase name) 15))
+                        (pkg-name (intern (format nil "ORG-AGENT.SKILLS.~a" (string-upcase name)) :keyword))
+                        (pkg (find-package pkg-name))
+                        (fn (when pkg (find-symbol "GET-AVAILABLE-MODELS" pkg))))
+                   (when (and fn (fboundp fn))
+                     (let ((models (funcall fn)))
+                       (dolist (model models)
+                         (push (format nil "| ~a | ~a | ~a |" 
+                                       provider-name 
+                                       (getf model :id) 
+                                       (getf model :context)) 
+                               table-rows)))))))
+             org-agent:*skills-registry*)
+    (format nil "~{~a~^~%~}" (nreverse table-rows))))
+
+(defun execute-skill-model-explorer (proposed-action context)
+  "Constructs the Emacs actuator command to insert the table."
+  (declare (ignore proposed-action)) ; We don't use System 1's proposal
+  (let* ((table-string (build-org-table-for-models))
+         ;; We use Emacs lisp to safely insert the table on the next line and align it.
+         (elisp-code (format nil "(progn (end-of-line) (insert \"\\n~a\\n\") (search-backward \"| Provider |\") (org-table-align))" table-string)))
+    `(:type :REQUEST 
+      :target :emacs 
+      :payload (:action :eval :code ,elisp-code))))
+#+end_src
+
+* Registration
+#+begin_src lisp
+(defskill :skill-model-explorer
+  :priority 85 ; High priority to intercept before the general Router
+  :trigger #'trigger-skill-model-explorer
+  :neuro (lambda (context) nil) ; Bypass System 1
+  :symbolic #'execute-skill-model-explorer)
+#+end_src

notes/skill-org-delivery.org

@@ -0,0 +1,65 @@
+#+TITLE: Org-Native Delivery Skill
+#+AUTHOR: org-agent
+#+SKILL_NAME: skill-org-delivery
+
+This skill provides the Actuator for external messaging by appending structured headlines to a central Org-mode delivery queue. 
+
+* Helper Functions
+#+begin_src lisp
+(defun format-universal-time-org (ut)
+  "Format universal time as a standard Org-mode timestamp string."
+  (multiple-value-bind (second minute hour day month year day-of-week)
+      (decode-universal-time ut)
+    (declare (ignore second day-of-week))
+    (format nil "~4,'0d-~2,'0d-~2,'0d ~a ~2,'0d:~2,'0d" 
+            year month day 
+            (nth (nth-value 6 (decode-universal-time ut)) '("Mon" "Tue" "Wed" "Thu" "Fri" "Sat" "Sun"))
+            hour minute)))
+#+end_src
+
+* Sensor & State (Actuator Registration)
+When this skill loads, it registers itself to handle `:delivery` actions.
+
+#+begin_src lisp
+(defun execute-org-delivery (action)
+  "Appends the message intent to the native Org-mode delivery file."
+  (let* ((payload (getf action :payload))
+         (text (getf payload :text))
+         (channel (or (getf payload :channel) :signal))
+         ;; Support Telegram and Discord identifiers if provided
+         (to (or (getf payload :to) 
+                 (case (or (getf payload :channel) :signal)
+                   (:telegram (org-agent::get-env "TELEGRAM_CHAT_ID"))
+                   (:discord (org-agent::get-env "DISCORD_WEBHOOK_URL"))
+                   (t (org-agent::get-env "RECIPIENT_ID")))))
+         (timestamp (format-universal-time-org (get-universal-time)))
+         (system-dir (org-agent::get-env "SYSTEM_DIR" "system/"))
+         (delivery-file (format nil "~a/delivery.org" system-dir)))
+    
+    (kernel-log "ACTUATOR [Org-Delivery] - Enqueueing ~a message for ~a..." channel to)
+    
+    (let ((entry (format nil "* TODO Message to ~a~%  :PROPERTIES:~%  :CHANNEL: ~a~%  :ENQUEUED_AT: [~a]~%  :STATUS: pending~%  :END:~%~%  ~a~%~%" 
+                         to channel timestamp text)))
+      
+      (handler-case
+          (with-open-file (out delivery-file 
+                                :direction :output 
+                                :if-exists :append 
+                                :if-does-not-exist :create)
+            (write-string entry out)
+            (kernel-log "ACTUATOR [Org-Delivery] - Entry appended to ~a" delivery-file))
+        (error (c)
+          (kernel-log "ACTUATOR [Org-Delivery] ERROR - Failed to write to file - ~a" c))))))
+
+;; Register the actuator with the core Event Bus
+(org-agent:register-actuator :delivery #'execute-org-delivery)
+#+end_src
+
+* Registration
+#+begin_src lisp
+(defskill :skill-org-delivery
+  :priority 100 ; Actuators are high priority
+  :trigger (lambda (context) nil) ; No cognitive trigger, actuator only
+  :neuro (lambda (context) nil)
+  :symbolic (lambda (action context) action))
+#+end_src

notes/skill-project-foundry.org

@@ -0,0 +1,86 @@
+#+TITLE - Project Foundry Skill
+#+AUTHOR - org-agent
+#+SKILL_NAME - skill-project-foundry
+
+This skill allows the agent to scaffold new projects within the Memex workspace. It automates directory creation, git initialization, and links the project to the user's GTD system.
+
+* Trigger
+Triggers only when delegated to by the Router.
+
+#+begin_src lisp
+(defun trigger-skill-project-foundry (context)
+  (let ((type (getf context :type))
+        (payload (getf context :payload)))
+    (and (eq type :EVENT)
+         (eq (getf payload :sensor) :delegation)
+         (eq (getf payload :target-skill) :foundry))))
+#+end_src
+
+* Scaffolding Logic
+#+begin_src lisp
+(defun scaffold-project (name type)
+  "Physically creates the project structure on disk and links it to GTD."
+  (let* ((projects-dir (org-agent::get-env "PROJECTS_DIR" "/app/5_projects/"))
+         (project-dir (format nil "~a/~a/" projects-dir name))
+         (readme-path (format nil "~aREADME.org" project-dir))
+         (memex-dir (org-agent::get-env "MEMEX_DIR" "/app/"))
+         (gtd-file (format nil "~a/gtd.org" (string-right-trim "/" memex-dir))))
+    
+    (if (uiop:directory-exists-p project-dir)
+        (format nil "ERROR - Project ~a already exists." name)
+        (progn
+          (kernel-log "FOUNDRY - Scaffolding ~a project: ~a" type name)
+          ;; 1. Create directory
+          (ensure-directories-exist project-dir)
+          ;; 2. Initialize Git (via shell delegation)
+          (org-agent:inject-stimulus 
+           `(:type :EVENT :payload (:action :run-command :target :shell :cmd ,(format nil "git init ~a" project-dir))))
+          
+          ;; 3. Create Boilerplate README
+          (with-open-file (out readme-path :direction :output :if-exists :supersede)
+            (format out "#+TITLE - ~a~%#+AUTHOR - User~%#+DATE - ~a~%~%* Overview~%Automatically scaffolded ~a project.~%"                    name (get-universal-time) type))
+          
+          ;; 4. Link to GTD.org (Homoiconic Connection)
+          (with-open-file (out gtd-file :direction :output :if-exists :append)
+            (format out "~%* PROJ ~a~%  :PROPERTIES:~%  :PROJECT_PATH: $PROJECTS_DIR/~a~%  :ID: proj-~a~%  :END:~%  Drafted by Project Foundry.~%" 
+                    name name (get-universal-time)))
+          
+          (format nil "SUCCESS - Project ~a scaffolded and linked to GTD.org" name)))))
+#+end_src
+
+* Neuro Prompt
+#+begin_src lisp
+(defun neuro-skill-project-foundry (context)
+  (let* ((payload (getf context :payload))
+         (query (getf payload :query)))
+    (format nil "
+      You are the Project Foundry.
+      The user wants to start a new project - '~a'
+      
+      Extract the PROJECT NAME and the PROJECT TYPE.
+      Return a Lisp plist - (:target :foundry :action :scaffold :name \"extracted-name\" :type \"extracted-type\")
+    " query)))
+#+end_src
+
+* Symbolic Verification & Actuation
+#+begin_src lisp
+(defun verify-skill-project-foundry (proposed-action context)
+  (let* ((payload (getf proposed-action :payload))
+         (action (getf proposed-action :action))
+         (name (getf payload :name))
+         (type (getf payload :type)))
+    
+    (if (eq action :scaffold)
+        (let ((result (scaffold-project name type)))
+          `(:target :emacs :action :message :text ,result))
+        nil)))
+#+end_src
+
+* Registration
+#+begin_src lisp
+(defskill :skill-project-foundry
+  :priority 80
+  :trigger #'trigger-skill-project-foundry
+  :neuro #'neuro-skill-project-foundry
+  :symbolic #'verify-skill-project-foundry)
+#+end_src

notes/skill-project-manager.org

@@ -0,0 +1,80 @@
+#+TITLE - Project Manager Skill
+#+AUTHOR - org-agent
+#+SKILL_NAME - skill-project-manager
+
+This skill provides the "Executive Presence" for project management. It uses the dynamic PROJECT_PATH to monitor project health and handle the lifecycle.
+
+* Trigger
+Triggers on explicit project status requests or when a project heading is saved.
+
+#+begin_src lisp
+(defun trigger-skill-project-manager (context)
+  (let* ((payload (getf context :payload))
+         (text (or (getf payload :text) ""))
+         (ast (getf payload :ast)))
+    (or (search "project status" text :test #'string-equal)
+        (and (eq (getf payload :sensor) :buffer-update)
+             (search "PROJECT_PATH" (format nil "~a" ast))))))
+#+end_src
+
+* Project Logic
+#+begin_src lisp
+(defun get-project-diagnostics (raw-path)
+  "Resolves the path and gathers folder facts (git status, file list)."
+  (let* ((resolved-path (org-agent:context-resolve-path raw-path))
+         (ls-cmd (format nil "ls -F ~a" resolved-path))
+         (git-cmd (format nil "git -C ~a status --short" resolved-path)))
+    (if (uiop:directory-exists-p resolved-path)
+        (let ((files (ignore-errors (uiop:run-program ls-cmd :output :string :ignore-error-status t)))
+              (git (ignore-errors (uiop:run-program git-cmd :output :string :ignore-error-status t))))
+          (format nil "FILES -~%~a~%GIT STATUS -~%~a" files (or git "Not a git repo or clean.")))
+        "ERROR - Project directory not found at resolved path.")))
+
+(defun get-git-diff (raw-path)
+  "Returns the current uncommitted changes in the project."
+  (let ((resolved (org-agent:context-resolve-path raw-path)))
+    (handler-case
+        (uiop:run-program (format nil "git -C ~a diff" resolved) :output :string)
+      (error () nil))))
+#+end_src
+
+* Neuro Prompt
+#+begin_src lisp
+(defun neuro-skill-project-manager (context)
+  (let* ((payload (getf context :payload))
+         (ast (getf payload :ast))
+         ;; Extract the PROJECT_PATH from the current AST
+         (path-match (nth-value 1 (cl-ppcre:scan-to-strings ":PROJECT_PATH: (\\$\\w+/[^\\s%]+)" (format nil "~a" ast)))))
+    
+    (if path-match
+        (let* ((raw-path (aref path-match 0))
+               (diagnostics (get-project-diagnostics raw-path))
+               (diff (get-git-diff raw-path)))
+          (format nil "
+            You are the Project Manager.
+            The user is looking at a project with path - ~a
+            
+            DIAGNOSTICS -
+            ~a
+            
+            UNCOMMITTED CHANGES (Diff) -
+            ---
+            ~a
+            ---
+            
+            TASK -
+            1. Summarize the project status.
+            2. If there are changes, suggest a 'git commit' message.
+            3. Return a Lisp plist - (:target :emacs :action :message :text \"your report and commit suggestion\")
+          " raw-path diagnostics (or diff "None.")))
+        nil)))
+#+end_src
+
+* Registration
+#+begin_src lisp
+(defskill :skill-project-manager
+  :priority 70
+  :trigger #'trigger-skill-project-manager
+  :neuro #'neuro-skill-project-manager
+  :symbolic (lambda (action context) action))
+#+end_src

notes/skill-provider-anthropic.org

@@ -0,0 +1,57 @@
+#+TITLE - Anthropic (Claude) Provider Skill
+#+AUTHOR - org-agent
+#+SKILL_NAME - skill-provider-anthropic
+#+DEPENDS_ON - skill-environment-config
+
+This skill registers Anthropic's Claude as a pluggable System 1 backend.
+
+* Backend Implementation
+#+begin_src lisp
+(defun execute-anthropic-request (prompt system-prompt)
+  "Executes a completion request via the Anthropic (Claude) API."
+  (let ((api-key (org-agent::get-env "ANTHROPIC_API_KEY"))
+        (config-pkg (find-package :org-agent.skills.skill-environment-config)))
+    (unless api-key
+      (return-from execute-anthropic-request "(:type :LOG :payload (:text \"Anthropic key missing\"))"))
+    
+    (let* ((get-config-fn (when config-pkg (find-symbol "GET-CONFIG-ATTRIBUTE" config-pkg)))
+           (model (if (and get-config-fn (fboundp get-config-fn))
+                      (funcall get-config-fn :LLM_MODEL_ANTHROPIC "claude-3-5-sonnet-20240620")
+                      "claude-3-5-sonnet-20240620"))
+           (url "https://api.anthropic.com/v1/messages")
+           (body (cl-json:encode-json-to-string
+                  `((model . ,model)
+                    (max_tokens . 1024)
+                    (system . ,system-prompt)
+                    (messages . (((role . "user") (content . ,prompt))))))))
+      (handler-case
+          (let* ((response (dex:post url
+                                     :headers `(("Content-Type" . "application/json")
+                                                ("x-api-key" . ,api-key)
+                                                ("anthropic-version" . "2023-06-01"))
+                                     :content body))
+                 (json (cl-json:decode-json-from-string response)))
+            ;; Extract content from Anthropic response
+            (cdr (assoc :text (car (cdr (assoc :content json))))))
+        (error (c)
+          (format nil "(:type :LOG :payload (:text \"Anthropic Failure (~a) - ~a\"))" model c))))))
+
+;; Register the backend
+(org-agent:register-neuro-backend :anthropic #'execute-anthropic-request)
+(org-agent:register-neuro-backend :claude #'execute-anthropic-request)
+
+(defun get-available-models ()
+  "Returns the list of LLM models supported by this provider."
+  '((:id "claude-3-5-sonnet-20240620" :context "200k")
+    (:id "claude-3-opus-20240229" :context "200k")
+    (:id "claude-3-haiku-20240307" :context "200k")))
+#+end_src
+
+* Registration
+#+begin_src lisp
+(defskill :skill-provider-anthropic
+  :priority 100
+  :trigger (lambda (context) nil)
+  :neuro (lambda (context) nil)
+  :symbolic (lambda (action context) action))
+#+end_src

notes/skill-provider-gemini.org

@@ -0,0 +1,39 @@
+#+TITLE - Gemini Provider Skill
+#+AUTHOR - org-agent
+#+SKILL_NAME - skill-provider-gemini
+
+This skill registers Google's Gemini as a pluggable System 1 backend, moving the logic from the core to an Org-Native skill.
+
+* Backend Implementation
+#+begin_src lisp
+(defun execute-gemini-v1-request (prompt system-prompt)
+  "Executes a completion request via the Google Gemini v1beta API."
+  (let ((api-key (org-agent::get-env "LLM_API_KEY"))
+        (endpoint (org-agent::get-env "LLM_ENDPOINT")))
+    (unless api-key
+      (return-from execute-gemini-v1-request "(:type :LOG :payload (:text \"Gemini key missing\"))"))
+    
+    (let* ((url (format nil "~a?key=~a" endpoint api-key))
+           (body (cl-json:encode-json-to-string
+                  `((contents . ((parts . ((text . ,(format nil "~a~%~%Prompt - ~a" system-prompt prompt))))))))))
+      (handler-case
+          (let* ((response (dex:post url
+                                     :headers '(("Content-Type" . "application/json"))
+                                     :content body))
+                 (json (cl-json:decode-json-from-string response)))
+            (cdr (assoc :text (cdr (assoc :parts (car (cdr (assoc :parts (car (cdr (assoc :candidates json)))))))))))
+        (error (c)
+          (format nil "(:type :LOG :payload (:text \"Gemini Failure - ~a\"))" c))))))
+
+;; Register the official backend
+(org-agent:register-neuro-backend :gemini-official #'execute-gemini-v1-request)
+#+end_src
+
+* Registration
+#+begin_src lisp
+(defskill :skill-provider-gemini
+  :priority 100
+  :trigger (lambda (context) nil)
+  :neuro (lambda (context) nil)
+  :symbolic (lambda (action context) action))
+#+end_src

notes/skill-provider-ollama.org

@@ -0,0 +1,37 @@
+#+TITLE - Ollama Provider Skill (Local)
+#+AUTHOR - org-agent
+#+SKILL_NAME - skill-provider-ollama
+
+This skill registers a local Ollama instance as a pluggable System 1 backend.
+
+* Backend Implementation
+#+begin_src lisp
+(defun execute-ollama-request (prompt system-prompt)
+  "Executes a completion request via local Ollama."
+  (let* ((url "http://host.docker.internal:11434/api/generate")
+         (body (cl-json:encode-json-to-string
+                `((model . "llama3")
+                  (system . ,system-prompt)
+                  (prompt . ,prompt)
+                  (stream . nil)))))
+    (handler-case
+        (let* ((response (dex:post url
+                                   :headers '(("Content-Type" . "application/json"))
+                                   :content body))
+               (json (cl-json:decode-json-from-string response)))
+          (cdr (assoc :response json)))
+      (error (c)
+        (format nil "(:type :LOG :payload (:text \"Ollama Failure - ~a\"))" c)))))
+
+;; Register the backend
+(org-agent:register-neuro-backend :ollama #'execute-ollama-request)
+#+end_src
+
+* Registration
+#+begin_src lisp
+(defskill :skill-provider-ollama
+  :priority 100
+  :trigger (lambda (context) nil)
+  :neuro (lambda (context) nil)
+  :symbolic (lambda (action context) action))
+#+end_src

notes/skill-provider-openai.org

@@ -0,0 +1,56 @@
+#+TITLE - OpenAI Provider Skill
+#+AUTHOR - org-agent
+#+SKILL_NAME - skill-provider-openai
+#+DEPENDS_ON - skill-environment-config
+
+This skill registers OpenAI as a pluggable System 1 backend for the Neurosymbolic Kernel.
+
+* Backend Implementation
+#+begin_src lisp
+(defun execute-openai-request (prompt system-prompt)
+  "Executes a completion request via the OpenAI API."
+  (let ((api-key (org-agent::get-env "OPENAI_API_KEY"))
+        (config-pkg (find-package :org-agent.skills.skill-environment-config)))
+    (unless api-key
+      (return-from execute-openai-request "(:type :LOG :payload (:text \"OpenAI key missing\"))"))
+    
+    (let* ((get-config-fn (when config-pkg (find-symbol "GET-CONFIG-ATTRIBUTE" config-pkg)))
+           (model (if (and get-config-fn (fboundp get-config-fn))
+                      (funcall get-config-fn :LLM_MODEL_OPENAI "gpt-4-turbo-preview")
+                      "gpt-4-turbo-preview"))
+           (url "https://api.openai.com/v1/chat/completions")
+           (body (cl-json:encode-json-to-string
+                  `((model . ,model)
+                    (messages . (((role . "system") (content . ,system-prompt))
+                                 ((role . "user") (content . ,prompt))))
+                    (temperature . 0.2)))))
+      (handler-case
+          (let* ((response (dex:post url
+                                     :headers `(("Content-Type" . "application/json")
+                                                ("Authorization" . ,(format nil "Bearer ~a" api-key)))
+                                     :content body))
+                 (json (cl-json:decode-json-from-string response)))
+            ;; Extract content from OpenAI response structure
+            (cdr (assoc :content (cdr (assoc :message (car (cdr (assoc :choices json))))))))
+        (error (c)
+          (format nil "(:type :LOG :payload (:text \"OpenAI Failure (~a) - ~a\"))" model c))))))
+
+;; Register the backend upon skill load
+(org-agent:register-neuro-backend :openai #'execute-openai-request)
+
+(defun get-available-models ()
+  "Returns the list of LLM models supported by this provider."
+  '((:id "gpt-4-turbo-preview" :context "128k")
+    (:id "gpt-4o" :context "128k")
+    (:id "gpt-4" :context "8k")
+    (:id "gpt-3.5-turbo" :context "16k")))
+#+end_src
+
+* Registration
+#+begin_src lisp
+(defskill :skill-provider-openai
+  :priority 100 ; Providers are foundational
+  :trigger (lambda (context) nil) ; No cognitive trigger
+  :neuro (lambda (context) nil)
+  :symbolic (lambda (action context) action))
+#+end_src

notes/skill-provider-openrouter.org

@@ -0,0 +1,63 @@
+#+TITLE - OpenRouter Provider Skill
+#+AUTHOR - org-agent
+#+SKILL_NAME - skill-provider-openrouter
+#+DEPENDS_ON - skill-environment-config
+
+This skill registers OpenRouter as a pluggable System 1 backend, providing access to hundreds of models.
+
+* Backend Implementation
+#+begin_src lisp
+(defun execute-openrouter-request (prompt system-prompt)
+  "Executes a completion request via the OpenRouter API (OpenAI-compatible)."
+  (let ((api-key (org-agent::get-env "OPENROUTER_API_KEY"))
+        (config-pkg (find-package :org-agent.skills.skill-environment-config)))
+    (unless api-key
+      (return-from execute-openrouter-request "(:type :LOG :payload (:text \"OpenRouter key missing\"))"))
+    
+    (let* ((get-config-fn (when config-pkg (find-symbol "GET-CONFIG-ATTRIBUTE" config-pkg)))
+           (get-tiered-fn (when config-pkg (find-symbol "GET-TIERED-MODEL" config-pkg)))
+           ;; Try to find a specific OpenRouter model, or a generic tiered model
+           (model (cond
+                    ((and get-config-fn (funcall get-config-fn :LLM_MODEL_OPENROUTER nil))
+                     (funcall get-config-fn :LLM_MODEL_OPENROUTER nil))
+                    ((and get-tiered-fn (funcall get-tiered-fn :fast nil))
+                     (funcall get-tiered-fn :fast nil))
+                    (t "meta-llama/llama-3-70b-instruct")))
+           (url "https://openrouter.ai/api/v1/chat/completions")
+           (body (cl-json:encode-json-to-string
+                  `((model . ,model)
+                    (messages . (((role . "system") (content . ,system-prompt))
+                                 ((role . "user") (content . ,prompt))))))))
+      (handler-case
+          (let* ((response (dex:post url
+                                     :headers `(("Content-Type" . "application/json")
+                                                ("Authorization" . ,(format nil "Bearer ~a" api-key))
+                                                ("HTTP-Referer" . "https://github.com/org-agent/org-agent")                                                ("X-Title" . "org-agent"))
+                                     :content body))
+                 (json (cl-json:decode-json-from-string response)))
+            ;; Extract content from OpenAI-compatible response structure
+            (cdr (assoc :content (cdr (assoc :message (car (cdr (assoc :choices json))))))))
+        (error (c)
+          (format nil "(:type :LOG :payload (:text \"OpenRouter Failure (~a) - ~a\"))" model c))))))
+
+;; Register the backend
+(org-agent:register-neuro-backend :openrouter #'execute-openrouter-request)
+
+(defun get-available-models ()
+  "Returns a curated list of top LLM models supported by OpenRouter, including free tiers."
+  '((:id "moonshotai/kimi-k2.5" :context "128k" :tier :powerful)
+    (:id "anthropic/claude-3.5-sonnet" :context "200k" :tier :powerful)
+    (:id "google/gemini-flash-1.5" :context "1m" :tier :fast)
+    (:id "google/gemma-2-9b-it:free" :context "8k" :tier :free)
+    (:id "mistralai/pixtral-12b:free" :context "32k" :tier :free)
+    (:id "openrouter/auto" :context "varying" :tier :free)))
+#+end_src
+
+* Registration
+#+begin_src lisp
+(defskill :skill-provider-openrouter
+  :priority 100
+  :trigger (lambda (context) nil)
+  :neuro (lambda (context) nil)
+  :symbolic (lambda (action context) action))
+#+end_src

notes/skill-router.org

@@ -0,0 +1,118 @@
+#+TITLE: LLM Router Skill
+#+AUTHOR: org-agent
+#+SKILL_NAME: skill-router
+#+DEPENDS_ON: skill-environment-config
+
+This skill acts as the Meta-Cognitive Router. It intercepts unstructured user requests, asks the LLM to classify the intent, and emits internal delegation events.
+
+* Trigger Logic
+The Router triggers on explicit `M-x` commands OR when it detects an "@agent" or "@[Name]" request in an Org headline during a buffer save.
+
+#+begin_src lisp
+(defun find-agent-request (ast agent-name)
+  "Recursively search the AST for a headline addressed to @agent or @name."
+  (when (listp ast)
+    (let* ((type (getf ast :type))
+           (props (getf ast :properties))
+           (title (or (getf props :TITLE) "")))
+      (if (and (eq type :HEADLINE)
+               (or (search "@agent" title :test #'string-equal)
+                   (search (format nil "@~a" agent-name) title :test #'string-equal)))
+          ;; Found it! Extract the instruction (everything after the @ tag)
+          (let* ((pos (or (search "@agent" title :test #'string-equal)
+                          (search (format nil "@~a" agent-name) title :test #'string-equal)))
+                 ;; Skip the '@name' part
+                 (instruction (subseq title (+ pos (if (search "@agent" title :test #'string-equal) 6 (1+ (length agent-name)))))))
+            (string-trim '(#\Space #\Tab) instruction))
+          ;; Not here, recurse into children
+          (cl:some (lambda (c) (find-agent-request c agent-name)) (getf ast :contents))))))
+
+(defun trigger-skill-router (context)
+  "Engage if a user command exists OR if an @agent/@name request is found in the AST."
+  (let* ((payload (getf context :payload))
+         (sensor (getf payload :sensor))
+         ;; DYNAMIC NAME RESOLUTION:
+         ;; We look for the get-agent-name function in the identity skill's package.
+         ;; If the skill hasn't loaded yet, we fall back to "Agent".
+         (identity-pkg (find-package :org-agent.skills.skill-agent-identity))
+         (name-fn (when identity-pkg (find-symbol "GET-AGENT-NAME" identity-pkg)))
+         (agent-name (if (and name-fn (fboundp name-fn))
+                         (funcall name-fn)
+                         "Agent")))
+    (cond
+     ((eq sensor :user-command) t)
+     ((eq sensor :buffer-update)
+      ;; Proactive scanning of the AST using the dynamic name
+      (let ((request (find-agent-request (getf payload :ast) agent-name)))
+        (when request
+          ;; Store the extracted instruction in the context for System 1
+          (setf (getf (getf context :payload) :text) request)
+          (kernel-log "KERNEL [Router] Detected request for @~a: ~a" agent-name request)
+          t)))
+     (t nil))))
+#+end_src
+
+* Neuro Prompt
+#+begin_src lisp
+(defun neuro-skill-router (context)
+  (let ((text (getf (getf context :payload) :text))
+        (config-pkg (find-package :org-agent.skills.skill-environment-config)))
+    (let* ((get-tiered-fn (when config-pkg (find-symbol "GET-TIERED-MODEL" config-pkg)))
+           ;; Router uses the :FAST tier for routing efficiency
+           (model (if (and get-tiered-fn (fboundp get-tiered-fn))
+                      (funcall get-tiered-fn :fast "openrouter/auto")
+                      "openrouter/auto")))
+      (format nil "
+        You are the Master Router for an autonomous Lisp agent.
+        The user said - '~a'
+        
+        Using model: ~a
+        
+        Decompose this request into a SEQUENCE of atomic intents.
+        Available targets -
+        - :atomic-notes (historical memory/note retrieval)
+        - :shell (system commands like git status)
+        - :gtd (tasks, deadlines, schedules)
+        - :web (internet research, fetching URLs, searching the web)
+        - :foundry (scaffolding new projects, creating directories)
+        - :skill-creator (new capabilities, create a skill)
+        
+        Return a Lisp plist containing a list of intents - 
+        (:type :MULTI-DELEGATION :intents ((:target-skill :atomic-notes :query \"...\") (:target-skill :shell :cmd \"...\")))
+      " text model))))
+#+end_src
+
+* Symbolic Verification
+#+begin_src lisp
+(defun verify-skill-router (proposed-action context)
+  (let ((type (getf proposed-action :type)))
+    (cond
+     ((eq type :MULTI-DELEGATION)
+      (let ((intents (getf proposed-action :intents)))
+        (kernel-log "KERNEL [Router] Processing ~a intents.~%" (length intents))
+        (dolist (intent intents)
+          (let* ((target (getf intent :target-skill))
+                 (query (getf intent :query))
+                 (cmd (getf intent :cmd))
+                 (delegation-event `(:type :EVENT :payload (:sensor :delegation :target-skill ,target :query ,query :cmd ,cmd))))
+            (kernel-log "KERNEL [Router] Delegating to ~a~%" target)
+            (org-agent:inject-stimulus delegation-event)))
+        nil))
+     ((eq type :DELEGATION)
+      (let* ((target (getf proposed-action :target-skill))
+             (query (getf proposed-action :query))
+             (delegation-event `(:type :EVENT :payload (:sensor :delegation :target-skill ,target :query ,query))))
+        (kernel-log "KERNEL [Router] Delegating to ~a~%" target)
+        (org-agent:inject-stimulus delegation-event)
+        nil))
+     (t '(:type :LOG :payload (:text "Router failed to classify."))))))
+#+end_src
+
+* Registration
+#+begin_src lisp
+(defskill :skill-router
+  :priority 90
+  :trigger #'trigger-skill-router
+  :neuro #'neuro-skill-router
+  :symbolic #'verify-skill-router)
+#+end_src

notes/skill-self-fix.org

@@ -0,0 +1,79 @@
+#+TITLE - Immune System Skill (Self-Fix)
+#+AUTHOR - org-agent
+#+SKILL_NAME - skill-self-fix
+
+This skill acts as the agent's internal repair drone. It monitors the system logs for "pain" (errors, rejections, hallucinations) and autonomously refactors the offending skills.
+
+* Trigger
+Triggers periodically on the background heartbeat.
+
+#+begin_src lisp
+(defun trigger-skill-self-fix (context)
+  (let ((type (getf context :type))
+        (payload (getf context :payload)))
+    ;; Check every heartbeat
+    (and (eq type :EVENT)
+         (eq (getf payload :sensor) :heartbeat))))
+#+end_src
+
+* Neuro Prompt
+System 1 analyzes the most recent system logs. If it detects a recurring error or a System 2 rejection, it drafts a fix for the skill's source code.
+
+#+begin_src lisp
+(defun neuro-skill-self-fix (context)
+  "Examine system logs for errors and draft fixes for the agent's own code."
+  (let* ((logs (org-agent:context-get-system-logs 30))
+         (logs-str (format nil "~{~a~%~}" logs)))
+    
+    ;; Only engage if the logs actually contain signs of failure
+    (if (or (search "REJECTED" logs-str)
+            (search "ERROR" logs-str)
+            (search "hallucinated" logs-str)
+            (search "Syntax error" logs-str))
+        
+        (format nil "
+          You are the Immune System of a Neurosymbolic Lisp Machine.
+          You have detected 'pain' in the system logs:
+          ---
+          ~a
+          ---
+          
+          TASK:
+          1. Identify which skill is failing based on the log messages.
+          2. Use your knowledge of the Org-Native Skill Standard to draft a fix.
+          3. If a System 2 rule rejected an action, refine the System 1 prompt to be more compliant.
+          4. If there was a Lisp syntax error, correct the Lisp block.
+          
+          Return a Lisp plist - (:target :system :action :create-skill :filename \"skill-name.org\" :content \"the full fixed org content\")
+          
+          Note - You can call (org-agent:context-get-skill-source \"skill-name\") if you need to see the current code.
+        " logs-str)
+        
+        ;; If logs are clean, stay dormant
+        nil)))
+#+end_src
+
+* Symbolic Verification
+System 2 ensures the "surgery" is safe before applying it.
+
+#+begin_src lisp
+(defun verify-skill-self-fix (proposed-action context)
+  "Delegate to the skill-creator's logic for final acquisition, as it already has syntax validation."
+  (let ((action (getf proposed-action :action)))
+    (if (eq action :create-skill)
+        ;; We pass this to the core creator logic (or we could just let it pass here 
+        ;; since skill-creator will handle the actual file write if it were a separate skill,
+        ;; but here we just return it and let the dispatcher handle it if we had a system actuator).
+        ;; For now, we reuse the verify-skill-creator logic if it's available.
+        proposed-action
+        nil)))
+#+end_src
+
+* Registration
+#+begin_src lisp
+(defskill :skill-self-fix
+  :priority 40 ; Low priority, runs after primary domain logic
+  :trigger #'trigger-skill-self-fix
+  :neuro #'neuro-skill-self-fix
+  :symbolic #'verify-skill-self-fix)
+#+end_src

notes/skill-shell-actuator.org

@@ -0,0 +1,92 @@
+#+TITLE - Shell Actuator Skill
+#+AUTHOR - org-agent
+#+SKILL_NAME - skill-shell-actuator
+
+This skill gives the agent the ability to execute shell commands, protected by a strict, hardcoded whitelist.
+
+* Sensor & State (Actuator Registration)
+When this skill loads, it registers itself to handle `:shell` actions.
+
+#+begin_src lisp
+;; A strict whitelist of permitted executables
+(defparameter *allowed-commands* '("ls" "git" "rg" "grep" "date" "echo" "cat"))
+
+(defun execute-shell-safely (action)
+  "System 2 strictly verifies the command against the whitelist and captures full diagnostics."
+  (let* ((cmd-string (getf (getf action :payload) :cmd))
+         (executable (car (uiop:split-string cmd-string :separator '(#\Space)))))
+    
+    (if (member executable *allowed-commands* :test #'string=)
+        (progn
+          (format t "Shell Actuator - Executing '~a'~%" cmd-string)
+          (multiple-value-bind (stdout stderr exit-code)
+              (uiop:run-program cmd-string 
+                                :output :string 
+                                :error-output :string 
+                                :ignore-error-status t)
+            ;; Inject structured diagnostics back into the core bus
+            (org-agent:inject-stimulus 
+             `(:type :EVENT 
+               :payload (:sensor :shell-response 
+                         :cmd ,cmd-string 
+                         :stdout ,(or stdout "") 
+                         :stderr ,(or stderr "") 
+                         :exit-code ,exit-code)))))
+        (progn
+          (format t "Shell Actuator - BLOCKED illegal command '~a'~%" cmd-string)
+          (org-agent:inject-stimulus 
+           `(:type :EVENT 
+             :payload (:sensor :shell-response 
+                       :cmd ,cmd-string 
+                       :stdout "" 
+                       :stderr "ERROR - Command not in security whitelist." 
+                       :exit-code 1)))))))
+
+;; Register the actuator
+(org-agent:register-actuator :shell #'execute-shell-safely)
+#+end_src
+
+* Trigger
+#+begin_src lisp
+(defun trigger-skill-shell-actuator (context)
+  (let ((type (getf context :type))
+        (payload (getf context :payload)))
+    (and (eq type :EVENT)
+         (eq (getf payload :sensor) :shell-response))))
+#+end_src
+
+* Neuro Prompt
+#+begin_src lisp
+(defun neuro-skill-shell-actuator (context)
+  (let* ((p (getf context :payload))
+         (cmd (getf p :cmd))
+         (stdout (getf p :stdout))
+         (stderr (getf p :stderr))
+         (exit-code (getf p :exit-code)))
+    (format nil "
+      You executed the shell command - '~a'
+      EXIT CODE - ~a
+      
+      STDOUT:
+      ---
+      ~a
+      ---
+      
+      STDERR:
+      ---
+      ~a
+      ---
+      
+      Analyze the diagnostics. If there was an error, explain why and suggest a fix.
+      Return a Lisp plist - (:target :emacs :action :message :text \"your summary\")
+    " cmd exit-code stdout stderr)))
+#+end_src
+
+* Registration
+#+begin_src lisp
+(defskill :skill-shell-actuator
+  :priority 80
+  :trigger #'trigger-skill-shell-actuator
+  :neuro #'neuro-skill-shell-actuator
+  :symbolic (lambda (action context) action)) ; Pass-through, safety handled by actuator fn
+#+end_src

notes/skill-task-integrity.org

@@ -0,0 +1,101 @@
+#+TITLE - Task Integrity Skill
+#+AUTHOR - org-agent
+#+SKILL_NAME - skill-task-integrity
+
+This skill handles automated GTD state transitions and integrity.
+
+* Trigger
+Triggers only on buffer updates where the AST contains TODO states.
+
+#+begin_src lisp
+(defun trigger-skill-task-integrity (context)
+  (let ((type (getf context :type))
+        (payload (getf context :payload)))
+    (and (eq type :EVENT)
+         (eq (getf payload :sensor) :buffer-update))))
+#+end_src
+
+* Neuro Prompt
+System 1 asks for suggestions on the next action. It uses the Context API 
+to provide the LLM with "peripheral vision" of the user's workload.
+
+#+begin_src lisp
+(defun neuro-skill-task-integrity (context)
+  "Generate a System 1 prompt by gathering relevant facts from the Object Store."
+  (let ((recent-wins (org-agent:context-get-recent-completed-tasks))
+        (projects (org-agent:context-get-active-projects)))
+    ;; We construct a rich, human-readable prompt that describes the user's
+    ;; current reality, momentum, and the latest event.
+    (format nil "
+      You are the user's Executive Assistant managing their Org-mode GTD system.      
+      CURRENT MOMENTUM (Recently DONE) - ~a
+      ACTIVE PROJECTS - ~a
+      
+      NEW EVENT - ~a
+      
+      Suggest the next logical Org-mode action.
+      Provide concise, high-fidelity suggestions in Lisp plist format.
+      You MUST include :target :emacs in your top-level plist if you intend to execute an action.
+    " recent-wins projects context)))
+#+end_src
+
+* Symbolic Verification
+System 2 enforces GTD integrity using deterministic Lisp logic compatible 
+with org-gtd v4.0. It ensures that a task cannot be closed (resolved) 
+if it has active dependencies or children.
+
+#+begin_src lisp
+(defun semantic-state-category (state)
+  "Map a keyword state to its org-gtd v4.0 semantic category."
+  (let ((s (string-upcase (or state ""))))
+    (cond
+     ((member s '("TODO" "NEXT" "WAIT") :test #'string=) :active)
+     ((member s '("DONE" "CNCL" "CANCELED") :test #'string=) :resolved)
+     (t :unknown))))
+
+(defun has-active-children-p (parent-id)
+  "Recursively check if a node has any children in an :active semantic state."
+  (let ((parent (org-agent:lookup-object parent-id)))
+    (when parent
+      (cl:some (lambda (child-id)
+                 (let* ((child (org-agent:lookup-object child-id))
+                        (state (getf (org-agent:org-object-attributes child) :TODO-STATE)))
+                   (or (eq (semantic-state-category state) :active)
+                       (has-active-children-p child-id))))
+               (org-agent:org-object-children parent)))))
+
+(defun verify-skill-task-integrity (proposed-action context)
+  "The System 2 gatekeeper for task consistency. 
+   Ensures parent tasks cannot be closed if children are still active."
+  (let* ((payload (getf proposed-action :payload))
+         (action (getf payload :action))
+         (target-id (getf payload :target-id))
+         (props (getf payload :properties))
+         (new-state (cdr (assoc :TODO-STATE props))))
+    
+    ;; If the proposal attempts to transition a node to a :resolved state
+    (if (and (eq action :refactor-subtree)
+             target-id
+             (eq (semantic-state-category new-state) :resolved))
+        
+        ;; Verify that all hierarchical dependencies are met
+        (if (has-active-children-p target-id)
+            (progn
+              (format t "System 2 [skill-task-integrity] - BLOCKED transition of ~a to ~a. Active children remain.~%" target-id new-state)
+              nil) ; Return NIL to block the illegal state change
+            proposed-action)
+        
+        ;; Allow all other actions (e.g., TODO -> NEXT, or simple property updates)
+        proposed-action)))
+#+end_src
+
+* Registration
+Register the skill.
+
+#+begin_src lisp
+(defskill :skill-task-integrity
+  :priority 50
+  :trigger #'trigger-skill-task-integrity
+  :neuro #'neuro-skill-task-integrity
+  :symbolic #'verify-skill-task-integrity)
+#+end_src

notes/skill-web-interface.org

@@ -0,0 +1,60 @@
+#+TITLE - Web Dashboard Skill
+#+AUTHOR - org-agent
+#+SKILL_NAME - skill-web-interface
+
+This skill provides a lightweight web interface for the Neurosymbolic Kernel using the Hunchentoot server.
+
+* Web Server Implementation
+#+begin_src lisp
+(defvar *web-server* nil)
+
+(defun start-dashboard (&optional (port 8080))
+  "Starts the Hunchentoot dashboard server."
+  (unless *web-server*
+    (setf *web-server* (make-instance 'hunchentoot:easy-acceptor :port port))
+    (hunchentoot:start *web-server*)
+    (kernel-log "WEB - Dashboard live on port ~a" port)))
+
+(hunchentoot:define-easy-handler (dashboard-home :uri "/") ()
+  (setf (hunchentoot:content-type*) "text/html")
+  (let* ((skills (org-agent:context-list-all-skills))
+         (telemetry (mapcar (lambda (s) 
+                              (let ((stats (org-agent:context-get-skill-telemetry (getf s :name))))
+                                (format nil "<li><b>~a</b> (P:~a) [Execs: ~a, Time: ~ams, Fails: ~a]</li>"
+                                        (getf s :name) 
+                                        (getf s :priority)
+                                        (or (getf stats :executions) 0)
+                                        (or (getf stats :total-time) 0)
+                                        (or (getf stats :failures) 0))))
+                            skills)))
+    (format nil "
+      <html>
+      <head><title>org-agent Dashboard</title></head>
+      <body style='font-family: monospace; background: #111; color: #eee; padding: 20px;'>
+        <h1>org-agent Neurosymbolic Kernel</h1>
+        <hr>
+        <h2>Active Skill Graph & Telemetry</h2>
+        <ul>
+          ~{~a~%~}
+        </ul>
+        <hr>
+        <h2>Recent Logs</h2>
+        <pre>~{~a~%~}</pre>
+      </body>
+      </html>
+    " telemetry (org-agent:context-get-system-logs 20))))
+
+;; Start the dashboard upon skill load
+(let* ((env-port (uiop:getenv "ORG_AGENT_WEB_PORT"))
+       (port (if env-port (parse-integer env-port :junk-allowed t) 8080)))
+  (start-dashboard port))
+#+end_src
+
+* Registration
+#+begin_src lisp
+(defskill :skill-web-interface
+  :priority 10 ; Low priority, background service
+  :trigger (lambda (context) nil)
+  :neuro (lambda (context) nil)
+  :symbolic (lambda (action context) action))
+#+end_src

notes/skill-web-research.org

@@ -0,0 +1,95 @@
+#+TITLE: Web Research Skill (Generalized)
+#+AUTHOR: org-agent
+#+SKILL_NAME: skill-web-research
+
+This skill provides the agent with internet connectivity via multiple pluggable browser engines.
+
+* Trigger
+#+begin_src lisp
+(defun trigger-skill-web-research (context)
+  (let ((type (getf context :type))
+        (payload (getf context :payload)))
+    (and (eq type :EVENT)
+         (eq (getf payload :sensor) :delegation)
+         (eq (getf payload :target-skill) :web))))
+#+end_src
+
+* Browser Engines
+We define multiple backends for fetching web content.
+
+#+begin_src lisp
+(defun fetch-with-lynx (url)
+  "Engine: Lynx. Best for fast text extraction from blogs/docs."
+  (let ((cmd (format nil "lynx -dump -nolist '~a'" url)))
+    (uiop:run-program cmd :output :string :ignore-error-status t)))
+
+(defun fetch-with-curl (url)
+  "Engine: Curl. Best for raw HTML or API inspection."
+  (let ((cmd (format nil "curl -sL '~a'" url)))
+    (uiop:run-program cmd :output :string :ignore-error-status t)))
+
+(defun fetch-with-playwright (url)
+  "Engine: Playwright (Placeholder). In the future, this calls a Python bridge."
+  (format nil "ERROR: Playwright engine not yet implemented. Falling back to Lynx...~%~a" 
+          (fetch-with-lynx url)))
+
+(defun web-fetch (url &optional engine)
+  "Dispatch the fetch request to the specified engine (defaults to Lynx)."
+  (case engine
+    (:lynx (fetch-with-lynx url))
+    (:curl (fetch-with-curl url))
+    (:playwright (fetch-with-playwright url))
+    (t (fetch-with-lynx url))))
+#+end_src
+
+* Neuro Prompt
+System 1 chooses the engine based on the task complexity.
+
+#+begin_src lisp
+(defun neuro-skill-web-research (context)
+  (let* ((payload (getf context :payload))
+         (query (getf payload :query))
+         ;; The LLM can specify an engine. If not, we default to Lynx.
+         (requested-engine (or (getf payload :engine) :lynx))
+         (is-url (or (search "http://" query) (search "https://" query)))
+         (target-url (if is-url 
+                         query 
+                         (format nil "https://duckduckgo.com/html/?q=~a" query)))
+         (web-text (web-fetch target-url requested-engine)))
+    
+    (let ((curated (if (and web-text (> (length web-text) 5000))
+                       (format nil "~a... [TRUNCATED]" (subseq web-text 0 5000))
+                       (or web-text "No content fetched."))))
+      
+      (format nil "
+        You are the Web Research synthesizer.
+        USER QUERY - '~a'
+        ENGINE USED - ~a
+        TARGET URL - ~a
+        
+        RAW CONTENT FETCHED -
+        ---
+        ~a
+        ---
+        
+        Synthesize a concise, factual answer. 
+        Return a Lisp plist - (:target :emacs :action :message :text \"your summary\")
+      " query requested-engine target-url curated))))
+#+end_src
+
+* Symbolic Verification
+#+begin_src lisp
+(defun verify-skill-web-research (proposed-action context)
+  (if (eq (getf proposed-action :action) :message)
+      proposed-action
+      '(:target :emacs :action :message :text "Web skill failed to synthesize message.")))
+#+end_src
+
+* Registration
+#+begin_src lisp
+(defskill :skill-web-research
+  :priority 80
+  :trigger #'trigger-skill-web-research
+  :neuro #'neuro-skill-web-research
+  :symbolic #'verify-skill-web-research)
+#+end_src

notes/skill-workspace-manager.org

@@ -0,0 +1,52 @@
+#+TITLE - Workspace Manager Skill
+#+AUTHOR - org-agent
+#+SKILL_NAME - skill-workspace-manager
+
+This skill automates the Para/Memex workflow, such as archiving DONE tasks and organizing the inbox.
+
+* Trigger
+Triggers on buffer saves or background heartbeats.
+
+#+begin_src lisp
+(defun trigger-skill-workspace-manager (context)
+  (let* ((payload (getf context :payload))
+         (sensor (getf payload :sensor)))
+    (or (eq sensor :buffer-update)
+        (eq sensor :heartbeat))))
+#+end_src
+
+* Symbolic Logic
+#+begin_src lisp
+(defun archive-completed-tasks ()
+  "Identify DONE tasks and suggest archiving."
+  (let ((done-tasks (org-agent:context-query-store :todo-state "DONE" :type :HEADLINE)))
+    (when done-tasks
+      (kernel-log "WORKSPACE - Found ~a tasks ready for archiving." (length done-tasks))
+      ;; Return a list of IDs to move
+      (mapcar #'org-agent:org-object-id done-tasks))))
+#+end_src
+
+* Neuro Prompt
+#+begin_src lisp
+(defun neuro-skill-workspace-manager (context)
+  (let ((ready-to-archive (archive-completed-tasks))
+        (archive-dir (org-agent::get-env "ARCHIVES_DIR" "/app/8_archives/")))
+    (if ready-to-archive
+        (format nil "
+          WORKSPACE UPDATE -
+          I found these tasks marked DONE in the Atomic Notes (Zettelkasten) - ~a
+          
+          Suggest an Org-mode action to move them to the '~a' folder.
+          Return a Lisp plist - (:target :emacs :action :message :text \"I found completed tasks. Should I archive them?\")
+        " ready-to-archive archive-dir)
+        nil)))
+#+end_src
+
+* Registration
+#+begin_src lisp
+(defskill :skill-workspace-manager
+  :priority 40
+  :trigger #'trigger-skill-workspace-manager
+  :neuro #'neuro-skill-workspace-manager
+  :symbolic (lambda (action context) action))
+#+end_src

notes/tool_failure_protocol.org

@@ -0,0 +1,53 @@
+#+TITLE: Tool Failure Protocol
+#+AUTHOR: User
+#+CREATED: [2026-03-17 Mon]
+#+ID: 20260317-tool-failure-protocol
+#+BEGIN_COMMENT
+When encountering tool errors, follow debug protocol instead of panic responses.
+#+END_COMMENT
+
+* The Protocol
+
+When tools fail, execute these steps in order:
+
+1. READ the error message completely
+2. IDENTIFY the specific issue (missing parameter? syntax error? wrong path?)
+3. FIX the actual syntax problem
+4. RETRY with corrected parameters
+5. ESCALATE only if 2 attempts fail — with SPECIFIC error, not "what should I do?"
+
+* Anti-Patterns (STOP DOING)
+
+** Gateway Restart Misuse
+Using gateway restart as panic response to tool errors is WRONG because:
+- Restarts are for gateway service issues, not syntax errors
+- Doesn't fix the underlying problem
+- Disrupts service unnecessarily
+
+** When to ACTUALLY restart gateway:**
+- Gateway daemon unresponsive (not heartbeat check)
+- Actual service crashes or memory leaks
+- NOT for: tool syntax errors, model timeouts, context saturation
+
+** Decision Escalation
+Asking "What should I do?" when I have:
+- Complexity check results
+- Clear criteria for action
+- SOUL.md mandate for "No Operational Escalation"
+
+* Positive Patterns to Reinforce
+
+** Work Breakdown Success
+Identified 51 gaps across 10 files as complex.
+Decomposed into atomic tasks.
+Used sub-agents for parallel execution.
+Results: efficient verification with proper orchestration.
+
+** Wait Mode Discipline
+After spawning sub-agents, entered proper wait mode.
+Did NOT poll status or restart gateway.
+Waited for push-based completion events.
+
+* Core Rule
+
+Tool failure is a debug challenge, not a crisis.

notes/user-accounts.org

@@ -0,0 +1,47 @@
+#+TITLE: User - Associated Accounts
+#+author: User
+#+created: [2026-03-16 Mon 14:28]
+#+DATE: 2026-03-04
+#+FILETAGS: :reference:identity:accounts
+
+* User Account Access
+:PROPERTIES:
+:ID: 20260304-user-accounts
+:CREATED: [2026-03-04 Tue 21:15 EST]
+:END:
+
+** Overview
+
+Grandfathered email account with legacy access to multiple services.
+
+** Email
+- Address: user@example.com
+- Type: Grandfathered account
+- Status: Active
+
+** Associated Services
+
+| Service | Type | Notes |
+|---------|------|-------|
+| Facebook | Social | Grandfathered access |
+| Instagram | Social | Via Facebook connection |
+| OnlyFans | Content | Grandfathered access |
+| X (Twitter) | Social | Formerly Twitter |
+| New York Times | News | Subscription access |
+| Pinterest | Social | Visual discovery |
+| Amazon | E-commerce | Prime/rewards access |
+| complexityexplorer.org | Education | Santa Fe Institute courses |
+| Reddit | Social | Forum/community |
+
+** Security Notes
+
+- Credentials stored in: ~/.openclaw/credentials/user-identity.json
+- Access restricted to agent context
+- Do not share credentials externally
+- Review access quarterly
+
+** Account History
+
+- Created: 2026-03-04 (assigned to agent identity)
+- Previous identity: Sol
+- Current identity: User

notes/x-oauth-attempts.org

@@ -0,0 +1,36 @@
+#+TITLE: X OAuth Login Attempts
+#+author: User
+#+created: [2026-03-16 Mon 14:28]
+#+DATE: 2026-03-04
+#+FILETAGS: :reference:oauth:automation
+
+* X OAuth Login Process
+
+** Attempts Made
+
+*** Attempt 1: Direct OAuth flow
+- ❌ Failed: OTP expired (code 482109)
+
+*** Attempt 2: Fresh OTP
+- OTP: 927519
+- ❌ Failed: Page remained on X login, didn't navigate to Google
+
+** Technical Issues
+
+1. *Timing:* OAuth flows are time-sensitive
+2. *Session state:* Browser cookies/session handling complex
+3. *Redirect handling:* X → Google → X redirects not working via automation
+
+** Recommendation
+
+Use *manual approach* for now:
+- User logs in normally
+- Share bookmark content directly
+- Export/import bookmark files
+
+** Alternative Solutions**
+
+1. App Password (more reliable for automation)
+2. OAuth 2.0 with refresh tokens
+3. Browser extension automation
+4. Session cookie reuse

org-inbox.org

@@ -8514,7 +8514,7 @@ Instead of relying on SKILL.md or OpenCode's AGENTS.md, all capabilities are def
 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.             |
@@ -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

projects/PROJECT-STATUS.org

@@ -0,0 +1,87 @@
+#+TITLE: Project Status Dashboard
+#+author: Amero Garcia
+#+created: [2026-03-16 Mon 14:28]
+#+DATE: 2026-03-08
+#+FILETAGS: :status:projects:tracking
+
+* Active Projects Status
+
+| Project            | Status          | Blocked     | Next Action          | Owner |
+|--------------------+-----------------+-------------+----------------------+-------|
+| Gitea Server       | 🟡 Initializing | No          | Wait + configure     | Sol   |
+| X Bookmarks        | 🔴 Stalled      | YES - OAuth | Awaiting user export | User  |
+| Token Optimization | 🟢 Active       | No          | Stay on free tier    | Sol   |
+| Revenue Skills     | 🟡 Partial      | No          | Continue LinkedIn    | Sol   |
+| Security Hardening | 🟢 Complete     | No          | Monitor              | Sol   |
+
+* Stalled Items (Blockers)
+
+*X Bookmarks*
+- Blocker: OAuth 2.0 User Context required
+- Attempted: OAuth 1.0a, client credentials
+- Solution: User data export OR OAuth 2.0 walkthrough
+- Status: Waiting for user input
+- Action: Leave stalled, don't ask again
+
+* Completing Without Input (In Progress)
+
+*Gitea Server*
+- Current: Database initializing
+- ETA: 3-5 minutes
+- Next: Configure admin, create mind repo
+- Cost: Minimal tokens
+- Action: Continue autonomously
+
+*Revenue Skills*
+- LinkedIn skill: Complete ✅
+- Next: Sales Automation research
+- Source: Cron social listening data
+- Action: Build using existing research
+
+* Daily Autonomous Actions
+
+*Every 2 Hours (Free Operations):*
+- Check Gitea status
+- Git commit any changes
+- Verify sync working
+
+*Daily (7 AM Update):*
+- Report status
+- Flag real blockers only
+- Propose next steps
+
+* Decision Matrix (When to Ask User)
+
+| Scenario                      | Action   |
+|-------------------------------+----------|
+| Technical setup (Docker, git) | Do it ✅ |
+| Budget impact > $5            | Ask 💰   |
+| New project direction         | Ask 📋   |
+| Security changes              | Ask 🔒   |
+| Stalled 3+ days               | Ask ⏸️   |
+| Routine completion            | Do it ✅ |
+
+* Current Queue (Sol completes without asking)
+
+1. ✅ Finish Gitea setup (in progress)
+2. ✅ Create admin account
+3. ✅ Create mind repository
+4. ✅ Test clone/push/pull
+5. ✅ Document setup
+6. ⏸️ X bookmarks (if user provides export)
+7. 🔄 Resume revenue skill building
+8. 🔄 Continue LLM provider research
+
+* Blocked Until User Input
+
+- ❌ X bookmarks (need export)
+- ❌ New budget allocation (currently $10)
+- ❌ AWS Community Builders (need approval)
+
+---
+
+#+BEGIN_SRC
+Rule: If status is 🟡 or 🟢, continue autonomously.
+Rule: If status is 🔴 for >24hrs, ask once.
+Rule: Update this file after every significant action.
+#+END_SRC

projects/README.org

@@ -0,0 +1,9 @@
+#+TITLE: projects: Active Projects
+#+AUTHOR: Amr
+#+CREATED: [2026-03-17 Tue]
+#+BEGIN_COMMENT
+Active, time-bound efforts with a clear definition of done. Each project has its own dedicated folder for specifications and artifacts.
+#+END_COMMENT
+
+* projects: Active Projects
+Active, time-bound efforts with a clear definition of done. Each project has its own dedicated folder for specifications and artifacts.

projects/agora/agora-requirements-00-readme.org

@@ -0,0 +1,37 @@
+#+TITLE: Agora: 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
+
+* Agora: 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 [[file:../../gtd.org::*Agora: Decentralized Social Network][GTD.org > Projects > Agora]]
+
+* Key Documents
+
+- [[file:agora-requirements-01-overview.org][01. Overview]]
+- [[file:agora-requirements-02-identity.org][02. Identity]]
+- [[file:agora-requirements-03-infrastructure.org][03. Infrastructure]]
+- [[file:agora-requirements-04-the-primitive.org][04. The Primitive]]
+- [[file:agora-requirements-05-social.org][05. Social Spaces]]
+- [[file:agora-requirements-05-public-space.org][05. Public Space & Exchange]]
+- [[file:agora-requirements-06-exchange.org][06. Exchange]]
+- [[file:agora-requirements-06-advanced-integration.org][06. Advanced Integration]]
+- [[file:agora-requirements-07-library.org][07. Farcaster & Nostr Integration]]
+- [[file:agora-requirements-08-implementation.org][08. Implementation]]
+- [[file:agora-requirements-09-strategy.org][09. Strategy]]
+- [[file:agora-requirements-10-assessment.org][10. Gap Assessment]]
+- [[file:agora-consolidated-gap-analysis.org][Consolidated Gap Analysis]]
+
+* Status
+
+- [X] Concept and atomic notes complete
+- [X] Comprehensive specification built
+- [ ] Governance decision (DEC-001) pending
+- [ ] Implementation planning not started

projects/agora/agora-requirements-01-overview.org

@@ -0,0 +1,425 @@
+#+TITLE: Agora 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
+
+* 1. Introduction to the Agora Protocol
+
+The Agora 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. 
+
+Agora 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 Agora'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
+
+Agora's design is predicated upon a set of core principles that collectively ensure a robust, user-centric decentralized network.
+
+** 2.1. User Sovereignty and Data Ownership
+
+Central to Agora is the tenet of user sovereignty. Unlike centralized paradigms where platforms intermediate and often monetize user data, Agora'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, Agora 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 Agora 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
+
+Agora 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
+
+Agora'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 Agora'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 **[[file:agora-requirements-04-the-primitive.org][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 Agora-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
+
+Agora'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 Agora.
+-   **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 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 Agora 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
+
+Agora'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.
+-   **PDS-as-a-Service:** Services can integrate seamlessly, offering free sign-ups with grace periods and requiring in-Agora 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 Agora, 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
+
+Agora 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 Agora's reach to a wider user base while maintaining security and privacy.
+
+* 4. Agora Use Cases: A Paradigm Shift
+
+The synergistic combination of Agora's core differentiators enables a wide array of transformative use cases, redefining digital interaction across multiple domains.
+
+** 4.1. Decentralized Social Interaction
+
+Agora 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
+
+Agora 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
+
+Agora 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:** Agora'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 Agora 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 Agora protocol for order matching and liquidity.
+
+** 4.4. Decentralized Collaboration and Project Management
+
+Agora 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
+
+Agora'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, Agora 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 Agora 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 Agora 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, Agora 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. Agora 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. Agora 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 Agora 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 Agora" for easy reconnecting.
+- Surface collectives matching imported community memberships.
+
+** The "Four Orders of Growth" (Scaling Sequence)
+
+Scaling a decentralized network requires shifting from "Hand-holding" to "Protocol Incentives." Agora follows a strictly defined orders-of-magnitude 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 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.
+
+** 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 *Agora 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" Agora apps through the economic layer.
+
+* Strategic Positioning
+
+** Platform Replacement Strategy
+
+Rather than positioning Agora as an existential threat to Big Tech (Apple, Google, Meta), Agora 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.
+- *Agora 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.
+- *Agora Advantage:* User-chosen discovery algorithms, no surveillance capitalism.
+
+** Professional Communities (LinkedIn, corporate intranets)
+- *Pain Point:* Professional data exploitation, platform-controlled networking.
+- *Agora Advantage:* Sovereign professional identity, portable reputation.
+
+** Creator Platforms (Medium, Substack)
+- *Pain Point:* Platform fees (10-50%), censorship risk, no portability.
+- *Agora Advantage:* Near-zero fees, content ownership, subscriber portability.
+
+** Marketplaces (eBay, Etsy)
+- *Pain Point:* High fees (10-15%), centralized dispute resolution, account bans.
+- *Agora Advantage:* Low fees (<5%), transparent reputation, sovereign stores.
+
+** Adult Content (Pornhub, OnlyFans)
+- *Pain Point:* Censorship, payment processor discrimination, lack of privacy.
+- *Agora Advantage:* Censorship-resistant, Lightning-native payments, pseudonymous.
+
+** Specialized Communities (QRZ, Logbook of the World)
+- *Pain Point:* Aging infrastructure, lack of modern features, centralization.
+- *Agora Advantage:* Modern protocol, extensible, community-governed.
+
+** Decentralized Communities (Nostr, Fediverse)
+- *Pain Point:* Fragmentation, lack of economic layer, UI/UX challenges.
+- *Agora 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, Agora'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 Agora 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, Agora 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, Agora 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:* Agora'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:* Agora is non-custodial. Users control their own keys and funds.
+
+** Data Privacy (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
+
+- [[id:agora-bootstrap-sequence][Agora Bootstrap Sequence]]
+- [[id:agora-strategic-positioning][Agora Strategic Positioning]]
+- [[id:agora-legal-regulatory][Agora Legal & Regulatory Strategy]]

projects/agora/agora-requirements-02-identity.org

@@ -0,0 +1,612 @@
+* 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 Agora. 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 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 Agora'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 Agora 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 Agora 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, Agora'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)
+- Agora 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 Agora 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, 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.
+-   **Agora:** 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: Agora's Standard
+
+Agora 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 Agora'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 Agora 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, Agora 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 Agora's identity system MUST adhere to a strict set of rules to ensure the security, privacy, and integrity of user accounts.
+
+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
+
+Agora 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
+Agora 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, Agora 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, Agora 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 Agora 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 Agora economy.
+
+*** Delegated Authoring & AI Personas
+
+**** Owner DID vs. Editor DID: The Mechanism of Agency
+Agora 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, Agora 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)
+Agora 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:* Agora 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, Agora 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 Agora 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 Agora.
+
+*** 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
+Agora 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;
+  };
+  
+  // Agora 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 Agora 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 Agora ecosystem.
+
+*** Key Event Log (KEL): The Observer-First Transparency Log
+Every Persona in Agora 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
+Agora 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
+Agora-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.

projects/agora/agora-requirements-03-infrastructure.org

@@ -0,0 +1,823 @@
+#+TITLE: Agora Requirements - 03: Infrastructure
+#+author: Amero Garcia
+#+created: [2026-03-16 Mon 14:28]
+#+DATE: 2026-03-14
+#+ID: agora-requirements-03-infrastructure
+#+STARTUP: content
+
+* The Sovereign Infrastructure: Your Digital Foundation
+
+Agora's infrastructure is meticulously architected to deliver on the promise of true digital sovereignty. Unlike traditional platforms that centralize control, Agora 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 Agora'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 Agora'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, Agora 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 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 Agora 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:* 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. Agora'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
+Agora 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, Agora 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 Agora
+
+The Relay Network serves as Agora'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 Agora 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, Agora 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 Agora 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)
+- *Agora Protocol:* 10% (development fund)
+
+**** Network Resilience: Global Firehose vs. Fragmented Relays
+The Agora 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 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 Agora 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.
+
+** Agora-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), Agora 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 Agora'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 Agora 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, Agora 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 Agora content is discoverable on legacy search engines like Google, the network utilizes automated rendering pipelines.
+
+**** The Firehose
+Agora 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 Agora 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 Agora-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 Agora 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 Agora DID Document.
+
+*** The Service Schema
+Every Agora 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
+
+Agora'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 Agora 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 Agora 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
+
+- [[file:agora-requirements-04-the-primitive.org][The Primitive]] - Content Object structure and core encryption primitives.
+- [[file:agora-requirements-05-social.org][Social]] - Messaging models, social publishing, and the attention marketplace.
+- [[file:agora-requirements-02-identity.org][Identity]] - Master Key (Psyche) and Persona governance.
+- [[file:agora-requirements-06-exchange-and-contracts.org][Exchange and Contracts]] - Economic primitives, fee structures, and the SCAL layer.
+
+** Gaps
+
+- *None.* All identified gaps in the infrastructure layer have been resolved.

projects/agora/agora-requirements-04-the-primitive.org

@@ -0,0 +1,428 @@
+#+TITLE: Agora 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
+
+* The Primitive: The Atomic Foundation of Agora
+
+** Concept: The Universal Data Primitive
+
+The Primitive is Agora'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 Agora. 
+
+This elegant simplicity—the "Everything is a Note" paradigm—enables Agora's powerful interoperability, immutable audit trails, and seamless cross-application compatibility. By reducing all digital interactions to a single, cryptographically verifiable primitive, Agora 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 Agora. 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 Agora 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 Agora 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
+
+Agora 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": "Agora 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. 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. Agora 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:** Agora 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
+Agora 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:** Agora 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, Agora!",
+  "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
+
+- [[file:agora-requirements-02-identity.org][Identity]] - Personas and contracts
+- [[file:agora-requirements-03-infrastructure.org][Infrastructure]] - PDS and Relay
+- [[file:agora-requirements-05-social.org][Social]] - Relationships and communication
+- [[file:agora-requirements-06-exchange.org][Exchange]] - Economic layer
+
+** Gaps
+
+- *None.* All identified gaps in the primitive layer have been resolved.
+
+# Local Variables:
+# org-confirm-babel-evaluate: nil
+# End:

projects/agora/agora-requirements-05-social.org

@@ -0,0 +1,181 @@
+#+TITLE: Agora 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
+
+* Social Space: Where Human Connection Becomes Sovereign
+
+The Social Space is where Agora's revolutionary architecture transforms how humans connect, communicate, and transact. Unlike traditional platforms that own your relationships and monetize your attention, Agora 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 Agora: 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 Agora 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
+Agora 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 Agora—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), Agora 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), Agora 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 Agora 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, Agora 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 Agora, 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
+
+Agora'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, Agora 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. Agora 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 [[file:agora-requirements-03-infrastructure.org][Infrastructure]]). Agora-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 Agora, the Algorithm Layer is reimagined as an open **Information Router**. By moving the algorithm out of the central server and into an open market, Agora 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 Agora 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
+
+- [[file:agora-requirements-06-exchange-and-contracts.org][06: Exchange and Contracts]] - Economic layer and human connection formalization.
+- [[file:agora-requirements-02-identity.org][02: Identity]] - Personas and Master Keys.
+- [[file:agora-requirements-03-infrastructure.org][03: Infrastructure]] - PDS and Relays.

projects/agora/agora-requirements-06-exchange-and-contracts.org

@@ -0,0 +1,306 @@
+#+TITLE: Agora Requirements - 06: Exchange
+#+author: Amero Garcia
+#+created: [2026-03-16 Mon 14:28]
+#+DATE: 2026-03-15
+#+ID: agora-requirements-06-exchange
+#+STARTUP: content
+
+* Exchange
+
+** Concept
+
+The Exchange layer provides the economic substrate of Agora: value transfer via the Lightning Network, multi-currency support, and payment primitives. Built on top of Content Objects (see [[file:agora-requirements-04-the-primitive.org][The Primitive]]) and Social relationships (see [[file:agora-requirements-05-social.org][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 Agora'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 Agora 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, Agora implements SCAL. A contract in this system is not a static PDF; it is an executable cryptographic object.
+
+*** 1. The Ricardian Contract Module
+Agora 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, Agora 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 [[file:agora-requirements-10-governance-and-assets.org][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, Agora 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, Agora 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 Agora'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, Agora 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 [[file:agora-requirements-07-advanced-integration.org][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
+Agora 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 on Agora defining the asset's RGB schema and initial supply.
+- *Client Support:* Agora 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
+Agora 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
+
+- [[file:agora-requirements-04-the-primitive.org][The Primitive]] - Content Object structure
+- [[file:agora-requirements-05-social.org][Social]] - Connection types for economic relationships
+- [[file:agora-requirements-02-identity.org][Identity]] - Contracts and attestations
+
+** Gaps
+
+- *None.* All identified gaps in the exchange layer have been resolved.

projects/agora/agora-requirements-07-advanced-integration.org

@@ -0,0 +1,465 @@
+#+TITLE: Agora 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
+
+* Advanced Integration
+
+** AI Integration
+
+*** Overview
+
+Agora 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, 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 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 Agora 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 Agora 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), Agora 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
+
+- [[id:agora-ai-integration][Agora AI Personas & Privacy]]
+- [[id:agora-physical-iot][Agora Physical World & IoT]]

projects/agora/agora-requirements-08-library.org

@@ -0,0 +1,116 @@
+#+TITLE: Agora Requirements - 08: Library
+#+author: Amero Garcia
+#+created: [2026-03-16 Mon 14:28]
+#+DATE: 2026-03-14
+#+ID: agora-requirements-07-library
+#+STARTUP: content
+
+* 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 Agora'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 Agora
+
+- 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 Agora-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 Agora's social layer.
+- The system MUST support offline access for synced content.
+- The system MUST integrate with Agora's economic layer for paid content.
+
+** Related Documents
+
+- [[id:agora-content-primitives][Agora Unified Content Primitive]]
+- [[id:agora-pds-relay-architecture][Agora PDS & Relay Architecture]]

projects/agora/agora-requirements-09-implementation.org

@@ -0,0 +1,565 @@
+#+TITLE: Agora Requirements - 09: Implementation
+#+author: Amero Garcia
+#+created: [2026-03-16 Mon 14:28]
+#+DATE: 2026-03-14
+#+ID: agora-requirements-08-implementation
+#+STARTUP: content
+
+* Implementation
+
+** Client Architecture
+
+Sovereign iOS/Android clients with 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
+
+Agora is a set of open protocols, not a single API service. Developers build against the *Agora 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 *Agora Envelope* format (`proof`, `encryption_metadata`, `payload`).
+
+** Testing & Adversarial
+
+*** Testing Philosophy
+
+Agora'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 *Agora 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:* An Agora 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.
+
+*** Agora-to-Web Gateways
+
+See [[file:agora-requirements-03-infrastructure.org][Infrastructure - Agora-to-Web Gateways]] for detailed requirements. Implementation notes:
+- Clients SHOULD provide links to Gateway-rendered versions of public content for sharing with non-Agora users.
+- Clients MAY embed Gateway content in web views for hybrid experiences.
+
+** Conflict Resolution Algorithm
+
+*** Concept
+Due to the offline-first nature of Agora 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, Agora 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
+
+- [[id:agora-client-architecture][Agora Client App Architecture]]
+- [[id:agora-dev-api-specs][Agora API & Protocol Versioning Spec]]
+- [[id:agora-testing-strategy][Agora 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 {
+  // 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:

projects/agora/agora-requirements-10-governance-and-assets.org

@@ -0,0 +1,92 @@
+#+TITLE: Agora Requirements - 10: Governance and Physical Assets
+#+author: Amero Garcia
+#+created: [2026-03-22 Sun]
+#+ID: agora-requirements-10-governance
+#+STARTUP: content
+
+* Governance and Physical Assets
+
+** Overview
+
+This section expands Agora's capabilities beyond digital communication and into physical reality and organizational coordination. By integrating Physical Asset Linking (PAL) and the Governance Executable Module (GEM), Agora empowers Collectives to manage real-world resources and execute democratic decisions autonomously via smart contracts.
+
+** Governance Executable Module (GEM)
+
+** Concept
+Governance in Agora 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, Agora 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 Agora 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, Agora 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, Agora 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.

projects/agora/agora-requirements-10-user-journey.org

@@ -0,0 +1,33 @@
+#+TITLE: Agora Requirements: User Journey & Product Experience
+#+AUTHOR: Project Agora
+#+DATE: 2026-03-26
+
+* The Sovereign User Journey
+
+This document outlines the cohesive, narrative user journey of the Agora 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
+- [[file:agora-requirements-02-identity.org][02 Identity (Master Keys & Personas)]]
+- [[file:agora-requirements-03-infrastructure.org][03 Infrastructure (PDS & WebRTC Seeding)]]
+- [[file:agora-requirements-06-exchange-and-contracts.org][06 Exchange & Contracts (HODL Escrows & Arbitration)]]

projects/agora/agora-requirements-11-assessment.org

@@ -0,0 +1,72 @@
+#+TITLE: Agora 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
+
+* Realistic Assessment: Practicality, Technology, and Performance
+
+The Agora 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
+
+Agora'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, Agora reduces the "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 Agora 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 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
+
+Agora'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, Agora 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
+
+Agora 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
+
+- [[file:agora-requirements-01-overview.org][01: Overview]]
+- [[file:agora-requirements-02-identity.org][02: Identity]]
+- [[file:agora-requirements-09-implementation.org][09: Implementation]]

projects/dotemacs/README.org

@@ -0,0 +1,26 @@
+#+title: Emacs Setup Improvement & Documentation Project
+#+author: Amero Garcia
+#+created: [2026-03-16 Mon 13:58]
+#+begin_comment
+This file outlines the project to collaboratively improve and document Amr's Emacs setup, aiming to make Emacs his primary computing tool.
+#+end_comment
+
+* Emacs Setup Improvement & Documentation Project
+
+*Goal:** To collaboratively improve and comprehensively document Amr's Emacs configuration, transitioning Emacs into his primary computing environment.
+
+*Initial Scope:**
+-   Reviewing the existing Emacs Org-mode configuration file (tangled to set up Emacs).
+-   Identifying areas for optimization, new functionalities, and better integration with workflows.
+-   Documenting each significant setting, function, and package.
+
+*Information Needed from Amr:**
+-   Location of the current Emacs Org-mode configuration file.
+-   Key pain points or areas where Emacs currently falls short as a "main computing tool."
+-   Specific desired functionalities or integrations (e.g., mail, calendar, task management, coding environments, note-taking, web browsing within Emacs).
+-   Any existing documentation or design principles for the current setup.
+
+*Next Steps:**
+1.  Receive Emacs configuration file location from Amr.
+2.  Analyze current setup.
+3.  Propose documentation structure and initial improvements.

projects/dotemacs/dotemacs.org

@@ -0,0 +1,27 @@
+#+TITLE: Amr's Modular Emacs Configuration
+#+PROPERTY: header-args :tangle no ; This file is for loading other modules, not for tangling itself.
+
+* Configuration Modules
+
+This file loads the modular Emacs configuration files. It should be the primary way Emacs is configured, replacing or integrating with the original `~/.emacs`, `~/.emacs.d/init.el`, `~/.emacs.d/early-init.el`, and `~/.emacs.d/config.el`.
+
+#+begin_src emacs-lisp :exports none
+;; Load early-init.el first, if it exists and is separate (though it's now part of emacs-early-init.org)
+;; (load-file (expand-file-name "emacs-early-init.org" (file-name-directory load-file-name)))
+
+;; Load the core settings, including package management and essential setup.
+(org-babel-load-file (expand-file-name "emacs-core.org" (file-name-directory load-file-name)))
+
+;; Load early init settings (if separate and not fully covered by core)
+(org-babel-load-file (expand-file-name "emacs-early-init.org" (file-name-directory load-file-name)))
+
+;; Load other modules in a logical order
+(org-babel-load-file (expand-file-name "emacs-org.org" (file-name-directory load-file-name)))
+(org-babel-load-file (expand-file-name "emacs-gtd.org" (file-name-directory load-file-name)))
+(org-babel-load-file (expand-file-name "emacs-roam.org" (file-name-directory load-file-name)))
+(org-babel-load-file (expand-file-name "emacs-writing.org" (file-name-directory load-file-name)))
+(org-babel-load-file (expand-file-name "emacs-media.org" (file-name-directory load-file-name)))
+(org-babel-load-file (expand-file-name "emacs-shell.org" (file-name-directory load-file-name)))
+(org-babel-load-file (expand-file-name "emacs-ai.org" (file-name-directory load-file-name)))
+(org-babel-load-file (expand-file-name "emacs-misc.org" (file-name-directory load-file-name)))
+#+end_src

projects/dotemacs/emacs-ai.org

@@ -0,0 +1,104 @@
+#+TITLE: AI Configuration
+#+PROPERTY: header-args :tangle ~/.emacs.d/config.el
+
+* AI Settings
+
+** Ellama
+
+#+begin_src elisp :tangle no
+  ;; YOU DON'T NEED NONE OF THIS CODE FOR SIMPLE INSTALL
+  ;; IT IS AN EXAMPLE OF CUSTOMIZATION.
+  (use-package ellama
+    :init
+    (require 'llm-openai)
+    ;; setup key bindings
+    (setq ellama-keymap-prefix "C-c e")
+    )
+#+end_src
+
+#+begin_src elisp ~/.emacs.d/custom.el :tangle no
+  (setopt ellama-providers
+  	'(
+  	  ;; Ollama Provider (added here with a name)
+  	  ("ollama" . (make-llm-ollama
+                               ;; Consider a dedicated embedding model if gemma isn't ideal for it.
+                               :chat-model "gemma3:latest"
+                               :embedding-model "gemma3:latest" ; Or e.g., "nomic-embed-text"
+                               :default-chat-non-standard-params '(("num_ctx" . 8192))))
+
+  	  ("openai" . (make-llm-openai
+                         :key (auth-source-pass-get "api-key" "www/openai.com/amr@gharbeia.net")
+                         :chat-model "gpt-4o"
+  		       :embedding-model "text-embedding-3-large"))
+
+            ("groq" . (make-llm-openai-compatible
+                       :url "https://api.groq.com/openai/v1"
+                       :key (auth-source-pass-get "api-key" "www/console.groq.com/groq@amr.gharbeia.net")
+                       ;; Check Groq console for available models, these might change
+                       :chat-model "llama3-70b-8192" ; Example, verify on Groq
+                       :embedding-model "llama3-70b-8192")) ; Groq might not offer dedicated embedding models via this API
+            ))
+
+  ;; --- Set Active Providers ---
+  ;; Choose your default provider from the list above by its name
+  (setopt ellama-provider "ollama") ; Or "ollama", "openai", "groq"
+
+  ;; You can specify different providers for different tasks if needed
+  (setopt ellama-translation-provider "ollama")
+  (setopt ellama-naming-provider "ollama")
+  (setopt ellama-naming-scheme 'ellama-generate-name-by-llm)
+
+  (setq llm-debug t)
+#+end_src
+
+#+begin_src elisp
+  (use-package ellama
+  :ensure t
+  :bind ("C-c e" . ellama)
+  ;; send last message in chat buffer with C-c C-c
+  :hook (org-ctrl-c-ctrl-c-final . ellama-chat-send-last-message)
+  :init (setopt ellama-auto-scroll t)
+  :config
+  ;; show ellama context in header line in all buffers
+  (ellama-context-header-line-global-mode +1)
+  ;; show ellama session id in header line in all buffers
+  (ellama-session-header-line-global-mode +1))
+#+end_src
+
+** GPTel
+   
+#+begin_src elisp :tangle no
+  (use-package gptel)
+#+end_src
+
+#+begin_src elisp :tangle no
+  (setq gptel-api-key (auth-source-pass-get "api-key" "www/console.groq.com/groq@amr.gharbeia.net"))
+#+end_src
+
+#+begin_src elisp :tangle no
+  (gptel-make-openai "Groq"               ;Any name you want
+  :host "api.groq.com"
+  :endpoint "/openai/v1/chat/completions"
+  :stream t
+  :key (auth-source-pass-get "api-key" "www/console.groq.com/groq@amr.gharbeia.net")                   ;can be a function that returns the key
+  :models '(llama-3.1-70b-versatile
+            llama-3.1-8b-instant
+            llama3-70b-8192
+            llama3-8b-8192
+            mixtral-8x7b-32768
+            gemma-7b-it))
+#+end_src
+
+** Elisa
+
+#+begin_src elisp :tangle no
+  (use-package elisa
+    :init
+    (setopt elisa-limit 5)
+    (require 'llm-ollama)
+    (setopt elisa-embeddings-provider (make-llm-ollama :embedding-model "nomic-embed-text"))
+    (setopt elisa-chat-provider (make-llm-ollama
+                                 :chat-model "sskostyaev/openchat:8k-rag"
+                                 :embedding-model "nomic-embed-text"))
+    )
+#+end_src

projects/dotemacs/emacs-core.org

@@ -0,0 +1,169 @@
+#+TITLE: Core Emacs Configuration
+#+PROPERTY: header-args :tangle ~/.emacs.d/config.el
+
+* Front matter
+
+#+begin_src elisp :tangle ~/.emacs
+  ;;; .emacs --- Global settings
+  ;;; Commentary:
+  ;;; Code:
+
+  ;; -*- lexical-binding: t; -*-
+#+end_src
+
+#+begin_src elisp
+  ;;; config.el --- Summary
+  ;;; Commentary:
+  ;;; Code:
+
+  ;; -*- lexical-binding: t; -*-
+#+end_src
+
+#+begin_src elisp :tangle ~/.emacs.d/custom.el
+  ;;; custom.el --- Summary
+  ;;; Commentary:
+  ;;; Code:
+
+  ;; -*- lexical-binding: t; -*-
+#+end_src
+
+* Garbage collector
+
+Increase threshold to 500 MB to ease startup
+#+begin_src elisp :tangle ~/.emacs
+  (setq gc-cons-threshold (* 500 1024 1024))
+#+end_src
+
+Decrease threshold to 5 MB after init
+#+begin_src elisp :tangle ~/.emacs
+  (add-hook 'after-init-hook (lambda () (setq gc-cons-threshold (* 5 1024 1024))))
+#+end_src
+
+* Straight.el and use-package
+
+Bootstrap Straight.el and install use-package
+#+begin_src elisp :tangle ~/.emacs
+  (setq straight-repository-branch "develop") ;; Using develop branch temporarily to fix the org-roam-dailies issue.
+
+   (eval-and-compile
+     (defvar bootstrap-version)
+     (let ((bootstrap-file
+            (expand-file-name "straight/repos/straight.el/bootstrap.el"
+               		   (or (bound-and-true-p straight-base-dir)
+               		       user-emacs-directory)))
+           (bootstrap-version 7))
+       (unless (file-exists-p bootstrap-file)
+         (with-current-buffer
+             (url-retrieve-synchronously  "https://raw.githubusercontent.com/radian-software/straight.el/develop/install.el" 'silent 'inhibit-cookies)
+           (goto-char (point-max))
+           (eval-print-last-sexp)))
+       (load bootstrap-file nil 'nomessage))
+     
+     (straight-use-package 'use-package)
+     )
+#+end_src
+
+Integrate use-package and straight
+#+begin_src elisp :tangle ~/.emacs
+  (setq straight-use-package-by-default t)
+#+end_src
+
+Make sure Org is installed (straight.el)
+#+begin_src elisp :tangle ~/.emacs
+  (unless (file-directory-p "~/.emacs.d/straight/versions") (make-directory (concat user-emacs-directory "straight/versions")))
+#+end_src
+
+#+begin_src elisp :tangle ~/.emacs
+  (use-package org)
+#+end_src
+
+A use-package declaration for simplifying your .emacs
+#+begin_src elisp
+  (require 'use-package)
+#+end_src
+
+* Custom file
+
+#+begin_src elisp
+  (setq custom-file (expand-file-name "custom.el" user-emacs-directory))
+  (when (file-exists-p custom-file) (load custom-file))
+#+end_src
+
+* System information
+
+#+begin_src elisp  :tangle ~/.emacs.d/custom.el
+  (defvar my-laptop-p (equal (system-name) "lilitop"))
+  (defvar my-server-p (and (equal (system-name) "localhost") (equal user-login-name "root")))
+  (defvar my-phone-p (not (null (getenv "ANDROID_ROOT")))
+    "If non-nil, GNU Emacs is running on Termux.")
+  (when my-phone-p (defvar gnutls-algorithm-priority "NORMAL:-VERS-TLS1.3"))
+  (global-auto-revert-mode)  ; simplifies syncing
+#+end_src
+
+* Persistent history
+
+#+begin_src elisp
+  (savehist-mode)
+#+end_src
+
+* Backup and versioning
+
+#+begin_src emacs-lisp
+  (use-package magit
+    :ensure t
+    )
+#+end_src
+
+* Personal information
+
+#+begin_src elisp :tangle ~/.emacs.d/custom.el
+  (setq user-full-name "Amr Gharbeia")
+  (defvar email-address "amr@gharbeia.net")
+  (defvar calendar-latitude 39.0)
+  (defvar calendar-longitude -77.1)
+  (defvar calendar-location-name "Washington, DC")
+  (defvar calendar-time-zone -300)
+  (defvar calendar-standard-time-zone-name "EST")
+  (defvar calendar-daylight-time-zone-name "EDT")
+#+end_src
+
+* Saving Emacs Sessions
+
+Close frame when done
+#+begin_src elisp
+  (add-hook 'server-done-hook (lambda () (delete-frame)))
+#+end_src
+
+Save desktop session
+#+begin_src elisp
+  (desktop-save-mode t)
+#+end_src
+
+* Security
+
+#+begin_src elisp :tangle no
+  (use-package password-store)
+#+end_src
+
+#+begin_src elisp
+  (use-package auth-source
+    :config (auth-source-pass-enable)
+    )
+#+end_src
+
+* End matter
+
+#+begin_src elisp :tangle ~/.emacs
+  (provide '.emacs)
+  ;;; .emacs ends here
+#+end_src
+
+#+begin_src elisp
+  (provide 'config)
+  ;;; config.el ends here
+#+end_src
+
+#+begin_src elisp :tangle ~/.emacs.d/custom.el
+  (provide 'custom)
+  ;;; custom.el ends here
+#+end_src

projects/dotemacs/emacs-early-init.org

@@ -0,0 +1,18 @@
+#+TITLE: Early Init Configuration
+#+PROPERTY: header-args :tangle ~/.emacs.d/early-init.el
+
+* early-init.el
+
+For straight.el to pick up before package.el
+
+#+begin_src elisp
+  (setq package-enable-at-startup nil)
+#+end_src
+
+* Run Emacs as a server
+
+#+begin_src elisp
+  (require 'server)
+  (unless (server-running-p) (server-start))
+  (defvar server-max-buffers 100)
+#+end_src

projects/dotemacs/emacs-gtd.org

@@ -0,0 +1,150 @@
+#+TITLE: GTD & Agenda Configuration
+#+PROPERTY: header-args :tangle ~/.emacs.d/config.el
+
+* Agenda
+
+Basic agenda settings
+#+begin_src elisp
+   (setq org-deadline-warning-days 7)
+   (setq org-agenda-skip-additional-timestamps-same-entry t)
+   (setq org-agenda-span 'fortnight)
+   (setq org-agenda-tags-column 'auto)
+   (setq org-agenda-skip-scheduled-if-deadline-is-shown t)
+#+end_src
+
+Agenda files
+#+begin_src elisp
+  (setq org-agenda-files (list
+  			(concat org-directory "/0_inbox/inbox.org")
+  			(concat org-directory "/0_inbox/org-gtd-tasks.org")
+  			)
+        )
+#+end_src
+
+Better agenda views
+#+begin_src elisp :tangle no
+  (use-package org-super-agenda)
+#+end_src
+
+* To-do
+
+Basic todo
+#+begin_src elisp
+  (setq org-todo-keywords
+          '(
+            (sequence "TODO(t)" "NEXT(n)" "|" "DONE(d!)")
+            (sequence "WAIT(w@/!)" "|" "CNCL(c@)")
+            )
+          )
+
+  (setq org-todo-keyword-faces
+          '(
+            ("TODO" :foreground "red" :weight bold)
+            ("NEXT" :foreground "red" :weight bold)
+            ("WAIT" :foreground "yellow" :weight bold)
+            ("DONE" :foreground "green" :weight bold)
+            ("CNCL" :foreground "blue" :weight bold)
+            )
+          )
+
+  (setq org-enforce-todo-dependencies t)
+  (setq org-tags-exclude-from-inheritance '("crypt" "!private"))
+#+end_src
+
+Switch entry to 'DONE' when all subentries are done
+#+begin_src elisp
+  (defun org-summary-todo (n-done n-not-done)
+    "Switch entry to 'DONE' when all subentries are done, to 'TODO' otherwise.
+  Uses N-DONE and N-NOT-DONE"
+    (let (org-log-done org-log-states)   ; turn off logging
+      (org-todo (if (= n-not-done 0) "DONE" "TODO")
+                )
+        )
+    )
+
+    (add-hook 'org-after-todo-statistics-hook #'org-summary-todo)
+#+end_src
+
+* Getting Things Done (GTD)
+#+begin_src elisp
+  (use-package org-gtd
+    :defer t
+    :init (setq org-gtd-update-ack "3.0.0")
+    :after org
+    :config
+    ;; Keeping these two settings on instead of enabling (org-gtd-mode) until this issue is resolved https://github.om/Trevoke/org-gtd.el/issues/198
+    (setq org-edna-use-inheritance t)
+    (org-edna-mode)
+    ;;    (org-gtd-mode)
+    :bind (
+  	 ("C-c d c" . org-gtd-capture)
+  	 ("C-c d e" . org-gtd-engage)
+  	 ("C-c d p" . org-gtd-process-inbox)
+  	 :map org-gtd-clarify-map
+  	 ("C-c c" . org-gtd-organize)
+  	 )
+    )
+#+end_src
+
+#+begin_src elisp
+  (defvar org-gtd-directory org-directory)
+  (defvar org-gtd-organize-hooks '(org-gtd-set-area-of-focus org-set-tags-command))
+  (defvar org-gtd-organize-hooks '(org-gtd-set-area-of-focus))
+  (defvar org-gtd-areas-of-focus '(
+  				 "Atoms"
+  				 "Bits"
+  				 "Cells"
+  				 "Flags"
+  				 "Business"
+  				 "Wealth"
+  				 "Learning"
+  				 "Skills"
+  				 "Privacy"
+  				 "Archive"
+  				 "Library"
+  				 "Writing"
+  				 "Health"
+  				 "Home"
+  				 "Family"
+  				 "Social"
+  				 "Egypt"
+  				 )
+    )
+  (defvar org-gtd-clarify-show-horizons 'right)
+#+end_src
+
+Logging
+#+begin_src elisp
+  (setq org-log-into-drawer "LOGBOOK")
+#+end_src
+
+Clocking work in drawer
+#+begin_src elisp :tangle no
+  (setq org-clock-into-drawer t)
+#+end_src
+
+Habits
+#+begin_src elisp :tangle no
+  (setq org-habit-graph-column 80)
+  (setq org-habit-show-habits-only-for-today nil)
+#+end_src
+
+* Refile
+
+org-refile targets
+#+begin_src elisp
+  (setq org-refile-targets '((nil :maxlevel . 9)
+                             (org-agenda-files :maxlevel . 9)
+                             )
+        )
+#+end_src
+
+Set type of refile targets completion
+#+begin_src elisp
+  (setq org-outline-path-complete-in-steps nil)
+#+end_src
+
+Allow refiling to new parents created on the go after confirmation
+#+begin_src elisp
+  (setq org-refile-allow-creating-parent-nodes 'confirm)
+#+end_src

projects/dotemacs/emacs-media.org

@@ -0,0 +1,175 @@
+#+TITLE: Media and Books Configuration
+#+PROPERTY: header-args :tangle ~/.emacs.d/config.el
+
+* Read ebooks (calibredb)
+
+#+begin_src elisp
+  (use-package calibredb
+:defer t
+    :config
+      (setq calibredb-format-all-the-icons t)
+      (setq calibredb-format-icons-in-terminal t)
+      )
+#+end_src
+
+#+begin_src elisp
+  ;; Forcefully reset the variable after loading calibredb
+  (defvar calibredb-root-dir (concat (getenv "HOME") "/library/books"))
+  (defvar calibredb-db-dir (expand-file-name "metadata.db" calibredb-root-dir))
+  					; (defvar calibredb-library-alist (concat (getenv "HOME") "/library/books"))
+  ;;  (defvar calibredb-search-page-max-rows 1000)
+  (defvar calibredb-id-width 6)
+  (defvar calibredb-title-width 100)
+  (defvar calibredb-format-width 0)
+  (defvar calibredb-date-width 0)
+  (defvar calibredb-author-width 20)
+  (defvar calibredb-comment-width 0)
+  (defvar calibredb-tag-width 0)
+#+end_src
+
+Some keybindings
+
+#+begin_src elisp ~/.emacs.d/custom.el
+  (defvar calibredb-show-mode-map
+    (let ((map (make-sparse-keymap)))
+      (define-key map "?" #'calibredb-entry-dispatch)
+      (define-key map "o" #'calibredb-find-file)
+      (define-key map "O" #'calibredb-find-file-other-frame)
+      (define-key map "V" #'calibredb-open-file-with-default-tool)
+      (define-key map "s" #'calibredb-set-metadata-dispatch)
+      (define-key map "e" #'calibredb-export-dispatch)
+      (define-key map "q" #'calibredb-entry-quit)
+      (define-key map "y" #'calibredb-yank-dispatch)
+      (define-key map "," #'calibredb-quick-look)
+      (define-key map "." #'calibredb-dired-open)
+      (define-key map "\M-/" #'calibredb-rga)
+      (define-key map "\M-t" #'calibredb-set-metadata--tags)
+      (define-key map "\M-a" #'calibredb-set-metadata--author_sort)
+      (define-key map "\M-A" #'calibredb-set-metadata--authors)
+      (define-key map "\M-T" #'calibredb-set-metadata--title)
+      (define-key map "\M-c" #'calibredb-set-metadata--comments)
+      map)
+    "Keymap for `calibredb-show-mode'.")
+#+end_src
+
+#+begin_src elisp
+  (defvar calibredb-search-mode-map
+    (let ((map (make-sparse-keymap)))
+      (define-key map [mouse-3] #'calibredb-search-mouse)
+      (define-key map (kbd "<RET>") #'calibredb-find-file)
+      (define-key map "?" #'calibredb-dispatch)
+      (define-key map "a" #'calibredb-add)
+      (define-key map "A" #'calibredb-add-dir)
+      (define-key map "c" #'calibredb-clone)
+      (define-key map "d" #'calibredb-remove)
+      (define-key map "D" #'calibredb-remove-marked-items)
+      (define-key map "j" #'calibredb-next-entry)
+      (define-key map "k" #'calibredb-previous-entry)
+      (define-key map "l" #'calibredb-virtual-library-list)
+      (define-key map "L" #'calibredb-library-list)
+      (define-key map "n" #'calibredb-virtual-library-next)
+      (define-key map "N" #'calibredb-library-next)
+      (define-key map "p" #'calibredb-virtual-library-previous)
+      (define-key map "P" #'calibredb-library-previous)
+      (define-key map "s" #'calibredb-set-metadata-dispatch)
+      (define-key map "S" #'calibredb-switch-library)
+      (define-key map "o" #'calibredb-find-file)
+      (define-key map "O" #'calibredb-find-file-other-frame)
+      (define-key map "v" #'calibredb-view)
+      (define-key map "V" #'calibredb-open-file-with-default-tool)
+      (define-key map "," #'calibredb-quick-look)
+      (define-key map "." #'calibredb-dired-open)
+      (define-key map "y" #'calibredb-yank-dispatch)
+      (define-key map "b" #'calibredb-catalog-bib-dispatch)
+      (define-key map "e" #'calibredb-export-dispatch)
+      (define-key map "r" #'calibredb-search-refresh-and-clear-filter)
+      (define-key map "R" #'calibredb-search-clear-filter)
+      (define-key map "q" #'calibredb-search-quit)
+      (define-key map "m" #'calibredb-mark-and-forward)
+      (define-key map "f" #'calibredb-toggle-favorite-at-point)
+      (define-key map "x" #'calibredb-toggle-archive-at-point)
+      (define-key map "h" #'calibredb-toggle-highlight-at-point)
+      (define-key map "u" #'calibredb-unmark-and-forward)
+      (define-key map "i" #'calibredb-edit-annotation)
+      (define-key map (kbd "<DEL>") #'calibredb-unmark-and-backward)
+      (define-key map (kbd "<backtab>") #'calibredb-toggle-view)
+      (define-key map (kbd "TAB") #'calibredb-toggle-view-at-point)
+      (define-key map "\M-n" #'calibredb-show-next-entry)
+      (define-key map "\M-p" #'calibredb-show-previous-entry)
+      (define-key map "/" #'calibredb-search-live-filter)
+      (define-key map "\M-t" #'calibredb-set-metadata--tags)
+      (define-key map "\M-a" #'calibredb-set-metadata--author_sort)
+      (define-key map "\M-A" #'calibredb-set-metadata--authors)
+      (define-key map "\M-T" #'calibredb-set-metadata--title)
+      (define-key map "\M-c" #'calibredb-set-metadata--comments)
+      map)
+    "Keymap for `calibredb-search-mode'.")
+#+end_src
+
+* Annotate PDFs and EPUBs (org-noter)
+
+#+begin_src elisp :tangle no
+  (use-package org-noter)
+#+end_src
+
+#+begin_src elisp :tangle ~/.emacs.d/custom.el
+  (defvar org-noter-notes-search-path (list (concat org-directory "/library/books")))
+  (defvar org-noter-default-notes-file-names '("books.org"))  
+#+end_src
+
+* Link PDFs (org-noter-pdftools)
+
+#+begin_src elisp
+  (use-package org-noter-pdftools
+    :after org-noter
+    :config
+    ;; Add a function to ensure precise note is inserted
+    (defun org-noter-pdftools-insert-precise-note (&optional toggle-no-questions)
+      (interactive "P")
+      (org-noter--with-valid-session
+       (let ((org-noter-insert-note-no-questions (if toggle-no-questions
+  						   (not org-noter-insert-note-no-questions)
+                                                   org-noter-insert-note-no-questions))
+             (org-pdftools-use-isearch-link t)
+             (org-pdftools-use-freepointer-annot t))
+         (org-noter-insert-note (org-noter--get-precise-info)))))
+
+    ;; fix https://github.com/weirdNox/org-noter/pull/93/commits/f8349ae7575e599f375de1be6be2d0d5de4e6cbf
+    (defun org-noter-set-start-location (&optional arg)
+      "When opening a session with this document, go to the current location.
+  With a prefix ARG, remove start location."
+      (interactive "P")
+      (org-noter--with-valid-session
+       (let ((inhibit-read-only t)
+             (ast (org-noter--parse-root))
+             (location (org-noter--doc-approx-location (when (called-interactively-p 'any) 'interactive))))
+         (with-current-buffer (org-noter--session-notes-buffer session)
+           (org-with-wide-buffer
+            (goto-char (org-element-property :begin ast))
+            (if arg
+                (org-entry-delete nil org-noter-property-note-location)
+              (org-entry-put nil org-noter-property-note-location
+                             (org-noter--pretty-print-location location))))))))
+    (with-eval-after-load 'pdf-annot
+      (add-hook 'pdf-annot-activate-handler-functions #'org-noter-pdftools-jump-to-note)
+      )
+    )
+#+end_src
+
+* View EPUBs (nov.el)
+
+#+begin_src elisp :tangle no
+  (use-package nov
+    :config
+    (add-to-list 'auto-mode-alist '("\\.epub\\'" . nov-mode))
+    )
+#+end_src
+
+* Zotero (helm-bibtex)
+#+begin_src elisp :tangle no
+  (use-package helm-bibtex)
+#+end_src
+
+#+begin_src elisp :tangle ~/.emacs.d/custom.el
+  (defvar bibtex-completion-bibliography '("~/bibliography/zotero.bib"))
+#+end_src

projects/dotemacs/emacs-misc.org

@@ -0,0 +1,46 @@
+#+TITLE: Miscellaneous Configuration
+#+PROPERTY: header-args :tangle ~/.emacs.d/config.el
+
+* Browser (eww)
+
+#+begin_src elisp
+  (use-package eww
+    :bind* (("M-m g x" . eww)
+            ("M-m g :" . eww-browse-with-external-browser)
+            ("M-m g #" . eww-list-histories)
+            ("M-m g {" . eww-back-url)
+            ("M-m g }" . eww-forward-url))
+    :config
+    (progn
+      (add-hook 'eww-mode-hook 'visual-line-mode)
+      )
+    )
+#+end_src
+
+* Manage Docker in Emacs
+
+#+begin_src elisp
+  (use-package docker
+    :bind ("C-c d" . docker)
+    )
+#+end_src
+
+* Periodic table of the elements
+
+#+begin_src elisp :tangle no
+  (use-package chemtable)
+#+end_src
+
+* Accounting (beancount)
+
+#+begin_src elisp :tangle no
+  (use-package beancount
+    :straight (beancount :type git :host github :repo "beancount/beancount-mode")
+    :config
+    (add-to-list 'auto-mode-alist '("\\.beancount\\'" . beancount-mode))
+    (add-hook 'beancount-mode-hook #'outline-minor-mode)
+    (define-key beancount-mode-map (kbd "C-c C-n") #'outline-next-visible-heading)
+    (define-key beancount-mode-map (kbd "C-c C-p") #'outline-previous-visible-heading)
+    (add-hook 'beancount-mode-hook #'flymake-bean-check-enable)
+    )
+#+end_src

projects/dotemacs/emacs-org.org

@@ -0,0 +1,233 @@
+#+TITLE: Org Mode Configuration
+#+PROPERTY: header-args :tangle ~/.emacs.d/config.el
+
+* Org Mode
+
+** Basic setup
+
+#+begin_src elisp
+  (use-package org
+    :config
+    (defvar org-outline-path-complete-in-steps nil)
+    :bind (("C-c l" . org-store-link)
+  	 ("C-c a" . org-agenda)
+  	 ("C-c c" . org-capture)
+  	 :map org-mode-map)
+    )
+#+end_src
+
+#+begin_src elisp
+  (defvar org-directory (concat (getenv "HOME") "/org/"))
+#+end_src
+
+** Looks
+
+Basic 
+#+begin_src elisp
+  (defvar org-pretty-entities t) ; Improve org mode looks
+  (defvar org-hide-emphasis-markers t) ; Hide emphasis markup
+  (defvar org-num-mode nil)
+  (defvar org-startup-folded 'shw2levels)
+#+end_src
+
+Indentation of headers
+#+begin_src elisp
+  (defvar org-startup-indented t) ; Indent org heirarchy
+  (defvar org-adapt-indentation t)
+  (defvar org-hide-leading-stars t) ; Minimal Outline
+  (defvar org-odd-levels-only nil)
+#+end_src
+
+Indentation of lists
+#+begin_src elisp
+  (setq org-list-demote-modify-bullet t)
+#+end_src
+
+Org-modern
+#+begin_src elisp
+  (use-package org-modern
+    :ensure t
+    :config
+        ;; Choose some fonts
+    (set-face-attribute 'default nil :family "sans-serif")
+    (set-face-attribute 'variable-pitch nil :family "sans-serif")
+    (set-face-attribute 'org-modern-symbol nil :family "Iosevka")
+
+    ;; Edit settings
+    (defvar org-auto-align-tags nil)
+    (defvar org-tags-column 0)
+    (defvar org-catch-invisible-edits 'show-and-error)
+    (defvar org-special-ctrl-a/e t)
+    (defvar org-insert-heading-respect-content t)
+
+     ;; Org styling, hide markup etc.
+     (defvar org-hide-emphasis-markers t)
+     (defvar org-pretty-entities t)
+
+     ;; Agenda styling
+     (defvar org-agenda-tags-column 0)
+     (defvar org-agenda-block-separator ?─)
+     (defvar org-agenda-time-grid
+       '((daily today require-timed)
+         (800 1000 1200 1400 1600 1800 2000)
+         " ┄┄┄┄┄ " "┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄"))
+     (defvar org-agenda-current-time-string
+       "◀── now ─────────────────────────────────────────────────")
+
+    ;; Ellipsis styling
+     (defvar org-ellipsis "…")
+     (set-face-attribute 'org-ellipsis nil :inherit 'default :box nil)
+    
+     (global-org-modern-mode)
+    )
+#+end_src
+
+Highlight Sourcecode Syntax
+#+begin_src elisp
+  (setq org-src-fontify-natively t)
+  (setq org-src-tab-acts-natively t)
+#+end_src
+
+Images
+#+begin_src elisp
+  (setq org-startup-with-inline-images t)
+  (setq org-image-actual-width '(300))
+#+end_src
+
+** Capture
+
+#+begin_src elisp
+  (defvar org-default-notes-file (concat org-directory "/0_inbox/inbox.org"))
+#+end_src
+
+*** Org-protocol
+
+Linux configuration
+#+begin_src bash :tangle no
+[Desktop Entry]
+Name=org-protocol
+Comment=Intercept calls from emacsclient to trigger custom actions
+Categories=Other;
+Keywords=org-protocol;
+Icon=emacs
+Type=Application
+Exec=emacsclient -- %u
+Terminal=false
+StartupWMClass=Emacs
+MimeType=x-scheme-handler/org-protocol;
+#+end_src
+
+#+begin_src bash :tangle no
+update-desktop-database ~/.local/share/applications/
+#+end_src
+
+Basic configuration
+#+begin_src elisp
+  (require 'org-protocol)
+  (setq org-protocol-default-buffer-for-file-links "*scratch*") ; fixes 'no buffers remain to edit error for org-protocol capturer
+#+end_src
+
+Org-protocol templates
+#+begin_src elisp :tangle ~/.emacs.d/custom.el
+  (defvar org-capture-templates '(
+                                ("p" "Protocol"
+                                 entry
+                                 (file "0_inbox/inbox.org")
+                                 "* %^{Title}\nSource: %u, %c\n #+BEGIN_QUOTE\n%i\n#+END_QUOTE\n\n\n%?"
+                                 )
+                                ("L" "Protocol Link"
+                                 entry
+                                 (file "0_inbox/inbox.org")
+                                 "* %? [[%:link][%:description]]\n:PROPERTIES:\n:TITLE: %:description\n:URI: %:link\n:CREATED: %U\n:END:"
+                                 :prepend nil
+                                 :empty-lines 1
+                                 :created t
+                                 :kill-buffer t
+                                 )
+                                )
+        )
+#+end_src
+
+#+begin_src elisp
+  (setq org-protocol-default-template-key "L")
+#+end_src
+
+Convert Orgzly captures to org-protocol captures standard
+#+begin_src elisp
+  (defun my/org-convert-orgzly-to-org-protocol ()
+    "Reformat Orgzly bookmark at point to org-protocol bookmark."
+    (interactive)
+    (when (org-at-heading-p)
+      (let ((headline (nth 4 (org-heading-components))))
+        ;; Find and store the link. Delete the link line.
+        (search-forward-regexp "^https?://\\S-*" nil t)
+        (let ((link (match-string 0)))
+          (beginning-of-line)
+          (kill-line)
+          ;; Delete any trailing blank spaces
+          (org-back-to-heading)
+          (end-of-line)
+          (when (not (org-on-heading-p))
+            (delete-char 1)
+            )
+          ;; Set new headline
+          (goto-char (org-entry-beginning-position))
+          (org-edit-headline (format "[[%s][%s]]" link headline))
+          ;; Set new properties
+          (org-set-property "TITLE" headline)
+          (org-set-property "URI" link)
+          (message "Reformatted Orgzly bookmark at point to org-protocol bookmark")
+          )
+        )
+      )
+    )
+#+end_src
+
+** Exporting
+
+#+begin_src elisp :tangle no
+  (setq org-export-with-smart-quotes t)
+  (setq org-export-backends '(beamer html latex md))
+#+end_src
+
+Export to EPUB
+#+begin_src elisp :tangle no
+  (use-package ox-epub)
+#+end_src
+
+** org-attach
+
+#+begin_src elisp
+  (defvar org-attach-id-dir (concat org-directory "/library"))
+#+end_src
+
+** Enable shell scripting support in org-babel
+
+#+begin_src elisp
+  (defvar org-babel-do-load-languages  'org-babel-load-languages  '((shell . t)))
+#+end_src
+
+** Insert org-mode links from clipboard
+#+begin_src elisp :tangle no
+  (use-package org-cliplink
+    :bind
+    (("C-x p i" . org-cliplink))
+    )
+#+end_src
+
+** Deft
+#+begin_src elisp :tangle no
+  (use-package deft
+    :commands (deft)
+    :init
+    (defvar deft-extensions '("org"))
+    (defvar deft-recursive nil)
+    (defvar deft-use-filename-as-title t)
+    :config
+    (defvar deft-directory org-directory)
+    (defvar deft-recursive t)
+    (defvar deft-strip-summary-regexp ":PROPERTIES:\n\\(.+\n\\)+:END:\n")
+    (defvar deft-use-filename-as-title t)
+    :bind  ("C-c n d" . deft)
+    )
+#+end_src

projects/dotemacs/emacs-roam.org

@@ -0,0 +1,140 @@
+#+TITLE: Org-Roam Configuration
+#+PROPERTY: header-args :tangle ~/.emacs.d/config.el
+
+* Org-roam
+
+** Basic org-roam setup
+
+#+begin_src elisp
+(use-package org-roam
+  :init (setq org-roam-v2-ack t) ;; Acknowledge V2 upgrade
+  :after org
+  :config
+  (org-roam-db-autosync-enable)
+  (require 'org-roam-dailies)
+  :bind  (
+   ("C-c n f" . org-roam-node-find)
+   ("C-c n g" . org-roam-graph)
+   ("C-c n r" . org-roam-node-random)
+   ("C-c n h" . org-roam-node-convert-headline)
+   ("C-c n i" . org-roam-node-insert)
+   ("C-c n o" . org-id-get-create)
+   ("C-c n t" . org-roam-tag-add)
+   ("C-c n a" . org-roam-alias-add)
+   ("C-c n l" . org-roam-buffer-display-dedicated)
+   )
+  )
+#+end_src
+
+#+begin_src elisp
+  (setq org-roam-directory (concat org-directory "/1_thinking"))
+  (setq org-roam-dailies-directory (concat org-directory "/0_inbox/daily"))
+#+end_src
+
+#+begin_src elisp :tangle no
+  (use-package sqlite3)
+  (require 'sqlite3)
+#+end_src
+
+Include subdirectories in org-roam
+#+begin_src elisp
+  (setq org-roam-file-exclude-regexp "^[.][.]?/")
+#+end_src
+
+** Display in org-roam-buffer
+#+begin_src elisp :tangle no
+  (setq org-roam-mode-sections
+        (list #'org-roam-backlinks-section
+              #'org-roam-reflinks-section
+              #'org-roam-unlinked-references-section 
+              )
+        )
+#+end_src
+
+** Filter org-roam nodes find by tag
+
+#+begin_src elisp :tangle no
+  (defun my/org-roam-node-has-tag (node tag)
+    "Filter function to check if the given NODE has the specified TAG."
+    (member tag (org-roam-node-tags node))
+    )
+
+  (defun my/org-roam-node-find-by-tag ()
+    "Find and open an Org-roam node based on a specified tag."
+    (interactive)
+    (let ((tag (read-string "Enter tag: ")))
+      (org-roam-node-find nil nil (lambda (node) (my/org-roam-node-has-tag node tag))))
+    )
+#+end_src
+
+** org-roam-capture templates
+#+begin_src elisp
+  (setq org-roam-capture-templates
+        '(
+          ("L" "link" plain
+           (function org-roam--capture-get-point)
+           "%?"
+           :file-name "web/%<%Y-%m-%dT%H%M%S>.org"
+           :head "#+TITLE: ${title}\n#+CREATED: %<%Y-%m-%dT%H%M%S>"
+           :immediate-finish t
+           :unnarrowed t
+           )
+
+          ("h" "hugo post" plain
+           "%?"
+           :target (file+head "posts/${slug}.org"
+                              "#+TITLE: ${title}\n#+DATE: %U\n#+HUGO_BASE_DIR: ~/gharbeia.net\n#+HUGO_SECTION: ./posts\n#+HUGO_AUTO_SET_LASTMOD: t\n#+HUGO_TAGS: article\n#+HUGO_DRAFT: true\n")
+           :immediate-finish t
+           :unnarrowed t
+           )
+
+          ("p" "person" plain
+           "%?"
+           :if-new (file+head "people/${slug}.org"
+                             "#+TITLE: ${title}")
+          :immediate-finish t
+          :unnarrowed t
+          )
+         )
+       )
+#+end_src
+
+#+begin_src elisp
+  (setq org-roam-dailies-capture-templates
+        '(
+          ("d" "daily" plain
+           ""
+          :target ("file+heaed %<%Y-%m-%d>.org"  "#+title: %<%Y-%m-%d>\n\n")
+          :immediate-finish t
+          )
+         )
+       )
+#+end_src
+
+** Move org header to org-roam-daily
+
+#+begin_src elisp :tangle no
+  (defun my/org-move-entry-to-daily-notes ()
+    "Move the current org-mode headline to the daily notes file based on its :CREATED: property."
+    (interactive)
+    (let*
+        (
+         (created-prop (org-entry-get nil "CREATED"))
+         (created-date (when created-prop
+                         (org-parse-time-string created-prop)))
+         (year (nth 5 created-date)) ; Extract year (6th element)
+         (month (nth 4 created-date)) ; Extract month (5th element)
+         (day (nth 3 created-date)) ; Extract day (4th element)
+         (target-date (format "%04d-%02d-%02d" year month day)) ; Format date string
+         (target-file (org-roam-dailies-goto target-date)) 
+         )
+      (when target-file
+        (org-cut-subtree)
+        (find-file target-file)
+        (goto-char (point-max))
+        (unless (bolp) (newline))
+        (org-paste-subtree)
+        )
+      )
+  )
+#+end_src