diff --git a/SOUL.org b/SOUL.org index 94f7992..95cec3e 100644 --- a/SOUL.org +++ b/SOUL.org @@ -3,7 +3,7 @@ #+FILETAGS: :philosophy:alignment:invariants:psf: * Overview -This file contains the **Core Invariants** of the Personal Software Foundry. These are non-negotiable philosophical constraints that every agentic action MUST satisfy. +This file contains the *Core Invariants* of the Personal Software Foundry. These are non-negotiable philosophical constraints that every agentic action MUST satisfy. System 2 (Symbolic) uses these headlines as a "Moral Compass" during the decision stage. diff --git a/daily/2026-03-16.org b/daily/2026-03-16.org index 4731b6b..13584a4 100644 --- a/daily/2026-03-16.org +++ b/daily/2026-03-16.org @@ -1,6 +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. + - *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. diff --git a/daily/2026-03-17.org b/daily/2026-03-17.org index 8cb6275..25023df 100644 --- a/daily/2026-03-17.org +++ b/daily/2026-03-17.org @@ -28,25 +28,25 @@ Chronological record of all meetings, fleeting notes, and raw conversation logs ### 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 +- *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 +- *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) +- *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. @@ -94,25 +94,25 @@ Awaiting pressure-testing session for 21-layer audit assumptions. All building p ### 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 +- *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 +- *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) +- *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. @@ -160,25 +160,25 @@ Awaiting pressure-testing session for 21-layer audit assumptions. All building p ### 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 +- *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 +- *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) +- *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. @@ -226,25 +226,25 @@ Awaiting pressure-testing session for 21-layer audit assumptions. All building p ### 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 +- *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 +- *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) +- *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. @@ -292,25 +292,25 @@ Awaiting pressure-testing session for 21-layer audit assumptions. All building p ### 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 +- *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 +- *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) +- *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. @@ -358,25 +358,25 @@ Awaiting pressure-testing session for 21-layer audit assumptions. All building p ### 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 +- *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 +- *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) +- *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. diff --git a/daily/2026-03-21.org b/daily/2026-03-21.org index 080375c..8f70d06 100644 --- a/daily/2026-03-21.org +++ b/daily/2026-03-21.org @@ -5,29 +5,29 @@ * 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`):** +- *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`. + - *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. + - *"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:** +- *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. +- *`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. +- *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. @@ -39,29 +39,29 @@ :END: ### Key Discussions & Decisions: -- **Agora Documentation Refinements:** - - **Identity (`agora-requirements-02-identity.org`):** +- *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`. + - *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. + - *"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:** +- *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. +- *`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. +- *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. @@ -73,29 +73,29 @@ :END: ### Key Discussions & Decisions: -- **Agora Documentation Refinements:** - - **Identity (`agora-requirements-02-identity.org`):** +- *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`. + - *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. + - *"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:** +- *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. +- *`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. +- *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. @@ -107,29 +107,29 @@ :END: ### Key Discussions & Decisions: -- **Agora Documentation Refinements:** - - **Identity (`agora-requirements-02-identity.org`):** +- *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`. + - *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. + - *"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:** +- *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. +- *`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. +- *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. diff --git a/daily/2026-03-22.org b/daily/2026-03-22.org index d3bbbb7..20a4b0d 100644 --- a/daily/2026-03-22.org +++ b/daily/2026-03-22.org @@ -4,16 +4,16 @@ * 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:** +- *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:** +- *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. @@ -24,24 +24,24 @@ - `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`. +- *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. +- *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`. +- *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:** +- *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. +- *Result:* Minimized network attack surface for infrastructure services. * Logs - [10:45] Shifted focus from Security Audit back to Emacs Refactor to address memory restoration. diff --git a/daily/2026-03-30.org b/daily/2026-03-30.org index 5cae71b..1df8a0d 100644 --- a/daily/2026-03-30.org +++ b/daily/2026-03-30.org @@ -9,35 +9,35 @@ This session focused on three critical architectural upgrades: modularizing the * Accomplishments ** 1. Emacs Modularization ([[file:modular-emacs-configuration.org][Modular Emacs Configuration]]) -- **New Structure:** Configuration moved from monolithic `emacs.org` to domain-specific modules in `~/memex/system/`. -- **Bootstrap Fix:** `~/.emacs` rewritten as a robust bootstrap that prioritizes the newer Org-mode version from `straight.el` to prevent version mismatches. -- **Path Normalization:** All `org-directory`, `org-roam`, and capture paths standardized to `~/memex/`. -- **Literate Mandate:** All modular files (`emacs-*.org`) are the source of truth, tangling locally to `.el` files. +- *New Structure:* Configuration moved from monolithic `emacs.org` to domain-specific modules in `~/memex/system/`. +- *Bootstrap Fix:* `~/.emacs` rewritten as a robust bootstrap that prioritizes the newer Org-mode version from `straight.el` to prevent version mismatches. +- *Path Normalization:* All `org-directory`, `org-roam`, and capture paths standardized to `~/memex/`. +- *Literate Mandate:* All modular files (`emacs-*.org`) are the source of truth, tangling locally to `.el` files. ** 2. org-gtd v4.0 Migration ([[file:org-gtd-v4-migration.org][org-gtd v4.0 Migration]]) -- **DAG Implementation:** Successfully ran `org-gtd-upgrade-v3-to-v4`. -- **Database Partitioning:** To handle context limits and prevent crashes, massive legacy blocks were moved to separate inbox files: +- *DAG Implementation:* Successfully ran `org-gtd-upgrade-v3-to-v4`. +- *Database Partitioning:* To handle context limits and prevent crashes, massive legacy blocks were moved to separate inbox files: - `inbox-rotten-uri.org` (3,048 items) - `inbox-web-bookmarks.org` (733 items) - `inbox-atoms.org` (Deeply nested items) - `inbox-emacs.org` (336 items) - `inbox-posts.org` (Legacy web content) -- **Shadow Orchestration:** Integrated `:PSF-STATE:` properties into `gtd.org` for engineering lifecycle tracking. +- *Shadow Orchestration:* Integrated `:PSF-STATE:` properties into `gtd.org` for engineering lifecycle tracking. ** 3. PSF Operationalization ([[file:personal-software-foundry.org][Personal Software Foundry]]) -- **Mandates:** Codified Lisp Machine Sovereignty, Org Mandate, and Literate Programming. -- **Skill Upgrade:** `skill-project-foundry.org` now scaffolds full SDLC structures (`src/`, `tests/`, `docs/`, `PRD.org`, `PROTOCOL.org`). -- **Audit Loop:** `Scribe-Agent.org` updated to audit workspace compliance. +- *Mandates:* Codified Lisp Machine Sovereignty, Org Mandate, and Literate Programming. +- *Skill Upgrade:* `skill-project-foundry.org` now scaffolds full SDLC structures (`src/`, `tests/`, `docs/`, `PRD.org`, `PROTOCOL.org`). +- *Audit Loop:* `Scribe-Agent.org` updated to audit workspace compliance. * Current System State -- **Emacs:** Stable, running Org 10.0-pre, modularized. -- **GTD:** v4.0 Active. Main file `org-gtd-tasks.org` shrunk to ~40k lines. -- **PSF:** Phase 1 (Foundations) Complete. +- *Emacs:* Stable, running Org 10.0-pre, modularized. +- *GTD:* v4.0 Active. Main file `org-gtd-tasks.org` shrunk to ~40k lines. +- *PSF:* Phase 1 (Foundations) Complete. * Pending Actions (Phase 2) -1. **Resolve Encoding:** Fix encoding issues in the new `inbox-*.org` files. -2. **Architect Skill:** Implement `skill-architect.org` to automate `PROTOCOL.org` generation. -3. **Analyst Skill:** Implement `skill-tech-analyst.org` for automated TDD inception. +1. *Resolve Encoding:* Fix encoding issues in the new `inbox-*.org` files. +2. *Architect Skill:* Implement `skill-architect.org` to automate `PROTOCOL.org` generation. +3. *Analyst Skill:* Implement `skill-tech-analyst.org` for automated TDD inception. * See Also - [[file:personal-software-foundry.org][Personal Software Foundry (Philosophy)]] diff --git a/daily/2026-03-31.org b/daily/2026-03-31.org index b5c2829..53151bf 100644 --- a/daily/2026-03-31.org +++ b/daily/2026-03-31.org @@ -3,42 +3,42 @@ #+FILETAGS: :daily:refactor:psf:architecture: * Overview -Today saw the complete architectural transformation of the Memex into a high-integrity **Personal Software Foundry** (PSF) following the "Code as Thought" mandate. +Today saw the complete architectural transformation of the Memex into a high-integrity *Personal Software Foundry* (PSF) following the "Code as Thought" mandate. * Accomplishments ** 1. Knowledge Management Integrity -- **Inbox Partitioning Cleanup:** Verified and marked encoding issues as DONE for the newly partitioned inbox files. -- **Metadata Audit:** Performed a systematic audit of ~1,300 entries missing the mandatory :CREATED: property; recorded this as a high-priority task for the KM Standards project. +- *Inbox Partitioning Cleanup:* Verified and marked encoding issues as DONE for the newly partitioned inbox files. +- *Metadata Audit:* Performed a systematic audit of ~1,300 entries missing the mandatory :CREATED: property; recorded this as a high-priority task for the KM Standards project. ** 2. "Code as Thought" Architecture -- **Skill Formalization:** Successfully refactored all 33 agent skills into **Universal Literate Notes**. -- **Unified Source of Truth:** Moved literate Org sources (PRD, PROTOCOL, IMPLEMENTATION) into `notes/` using kebab-case filenames (e.g., `notes/org-skill-memex-manager.org`). -- **Material Realization:** Established standard PSF project folders in `projects/` for tangled source code, tests, and documentation. -- **System Actuation:** Replaced all hard-coded skill files in `system/skills/` with symbolic links to the unified notes, ensuring real-time execution of literate thoughts. +- *Skill Formalization:* Successfully refactored all 33 agent skills into *Universal Literate Notes*. +- *Unified Source of Truth:* Moved literate Org sources (PRD, PROTOCOL, IMPLEMENTATION) into `notes/` using kebab-case filenames (e.g., `notes/org-skill-memex-manager.org`). +- *Material Realization:* Established standard PSF project folders in `projects/` for tangled source code, tests, and documentation. +- *System Actuation:* Replaced all hard-coded skill files in `system/skills/` with symbolic links to the unified notes, ensuring real-time execution of literate thoughts. ** 3. PSF Consensus Loop Implementation -- **Formalized Roles:** Established dedicated projects for the core PSF roles: +- *Formalized Roles:* Established dedicated projects for the core PSF roles: - *Architect Agent:* Transforming Demand into Blueprint. - *Technical Analyst Agent:* Transforming Blueprint into Success (TDD). - *Project Foundry Agent:* Scaffolding high-integrity workspaces. - *Scribe Agent:* Automated distillation and mandate auditing. ** 4. Advanced "Foundry Native" Features -- **Headless OAuth 2.0:** Implemented professional Google/Gemini authentication with refresh token support and a headless "Copy-Paste" handshake. -- **Onboarding & Calibration:** Developed an interactive environment verification and setup script. -- **PSF Loop Automator:** Established a meta-cognitive skill that autonomously triggers Architect and Analyst roles based on note status. -- **Sparse Tree Perceiver:** Optimized memory retrieval with a two-stage scan/read process, significantly reducing token usage and improving accuracy. -- **Foundry-Sync (GTD Bridge):** Automated the mirroring of project engineering states (Phase A-F) from Zettelkasten notes to gtd.org. +- *Headless OAuth 2.0:* Implemented professional Google/Gemini authentication with refresh token support and a headless "Copy-Paste" handshake. +- *Onboarding & Calibration:* Developed an interactive environment verification and setup script. +- *PSF Loop Automator:* Established a meta-cognitive skill that autonomously triggers Architect and Analyst roles based on note status. +- *Sparse Tree Perceiver:* Optimized memory retrieval with a two-stage scan/read process, significantly reducing token usage and improving accuracy. +- *Foundry-Sync (GTD Bridge):* Automated the mirroring of project engineering states (Phase A-F) from Zettelkasten notes to gtd.org. ** 5. High-Integrity Verification (Consensus Loop Closure) -- **Recursive Safety Harness:** Verified the AST validator against nested malicious code (Phase C/E). -- **Object Store Persistence:** Verified Lisp-native serialization fidelity for instant recall (Phase C/E). -- **Autonomous Performance Auditor:** Verified failure rate detection and RCA triggering logic (Phase C/E). -- **Sub-Agent Manager:** Verified non-blocking thread spawning and context isolation (Phase C/E). +- *Recursive Safety Harness:* Verified the AST validator against nested malicious code (Phase C/E). +- *Object Store Persistence:* Verified Lisp-native serialization fidelity for instant recall (Phase C/E). +- *Autonomous Performance Auditor:* Verified failure rate detection and RCA triggering logic (Phase C/E). +- *Sub-Agent Manager:* Verified non-blocking thread spawning and context isolation (Phase C/E). * Current System State -- **Architecture:** 100% PSF Compliant (Literate, Kebab-case, Lisp-native state). -- **Core Stability:** Kernel hardened with incremental perception, symbolic safety gating, and parallel cognitive threads. -- **Next Steps:** Begin mass metadata repair using the new inference logic. +- *Architecture:* 100% PSF Compliant (Literate, Kebab-case, Lisp-native state). +- *Core Stability:* Kernel hardened with incremental perception, symbolic safety gating, and parallel cognitive threads. +- *Next Steps:* Begin mass metadata repair using the new inference logic. diff --git a/gtd.org b/gtd.org index 5ed17e2..a93185a 100644 --- a/gtd.org +++ b/gtd.org @@ -542,7 +542,7 @@ Cross-reference consolidated gap analysis against actual requirement specs to id See project documents: [[file:5_projects/agora/agora-consolidated-gap-analysis.org][agora-consolidated-gap-analysis.org]] -**DECOMPOSITION via Work Breakdown Skill:** +*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 @@ -557,7 +557,7 @@ Complexity check failed (51 gaps, 10 files, unpredictable scope). Breaking into *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. +*WHAT:* *REAL GAP* - Contracts described conceptually, lack formal TypeScript/Protobuf schemas. *** DONE [2/7] Verify CRITICAL Gap: Persona Revocation Protocol → IMPLEMENTED :PROPERTIES: @@ -571,7 +571,7 @@ Complexity check failed (51 gaps, 10 files, unpredictable scope). Breaking into *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. +*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: @@ -585,7 +585,7 @@ Complexity check failed (51 gaps, 10 files, unpredictable scope). Breaking into *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. +*WHAT:* *ALREADY IMPLEMENTED* - Protocol fully specified. PDSSyncSession interface documented. *** DONE [4/7] Verify CRITICAL Gap: Content Flag Schema Validation → REAL GAP :PROPERTIES: @@ -599,7 +599,7 @@ Complexity check failed (51 gaps, 10 files, unpredictable scope). Breaking into *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. +*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: @@ -615,11 +615,11 @@ Complexity check failed (51 gaps, 10 files, unpredictable scope). Breaking into *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) +- *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). diff --git a/inbox.org b/inbox.org index 9405e6c..6523e1a 100644 --- a/inbox.org +++ b/inbox.org @@ -3730,7 +3730,7 @@ https://x.com/i/status/2017636775347331276 :CREATED: [2026-03-19 Thu 12:28] :END: -You're getting to know your human for the first time. Your goal is to build a rich personal profile that will make every future interaction feel personal and useful. Run this as a CONVERSATION — not a survey. Ask 2-3 questions at a time, wait for answers, then ask follow-ups based on what they share. Be genuinely curious, not clinical. If they give short answers, don't push — you'll learn more over time. What to cover (let it flow naturally, don't force the order): Identity & Basics - Name, what they prefer to be called, pronouns - Location, timezone - Phone number (if they want you to have it) Daily Life - Typical day — wake time, work hours, evening routine - Morning ritual - Currently watching/reading/playing? - Food relationship — foodie or fuel? Work & Projects - What they do, how long they've been doing it - Current active projects or businesses - Work style — planner or builder? Deep focus or context-switching? - Strengths and energy drains Family & Household - Who lives in the house? Partner, kids, pets? - Names, birthdays, relationships - Notable details — hobbies, schools, schedules - Extended family worth knowing about Interests & Hobbies - What they do for fun - Music, sports, collections, creative outlets - Travel preferences - Hidden passions or guilty pleasures Communication Preferences - Brief or detailed info delivery? - Tone — formal, casual, snarky, warm? - When to proactively reach out vs. stay quiet - What annoys them in an AI assistant - Quiet hours — when to never message Goals & Aspirations - What they're working toward now - Long-term dreams or "someday" projects - What success looks like to them Pet Peeves & Boundaries - Things they hate (AI responses, general) - Off-limits or sensitive topics - Privacy boundaries for group chats After the conversation, create these files: USER.md Compile everything into a clean, scannable format with sections and bullet points. Include subsections for Daily Life, Interests, Family, Work, etc. This is the primary reference file the agent reads every session. brain/family/README.md Household overview table with names, relationships, birthdays, ages. Include an "Upcoming Dates" section for the current year listing birthdays and anniversaries chronologically. brain/family/{firstname}.md (one per family member) Use this template for each person mentioned: # {Name} **Relationship:** {relationship to user} **Birthday:** {date} --- ## Preferences (none yet) ## Important Dates - **Birthday:** {date} ## Gift Ideas (none yet) ## Notes (none yet) Include pets too (simpler format — name, breed/species, any quirks). MEMORY.md Start a long-term memory file. Add a "Self-Knowledge" section capturing work style, core drives, decision-making patterns — the deeper personality insights that emerged from the conversation. This file grows over time. After writing the files, set up a daily question cron job: - Schedule: Once per day at 9:00 AM in the user's timezone - Each morning, check if the user answered yesterday's question. If so, extract the key facts and update the appropriate file (USER.md, family files, or MEMORY.md). Then read existing files, find a gap, and ask ONE new thoughtful question. Not a survey — something genuine. Important: - This is a foundation, not an encyclopedia. The daily cron fills gaps. - If they seem done or restless, wrap up gracefully. - Write ALL files in the same session — don't promise to do it later. - Use information they actually shared. Don't infer or fabricate. - For sections without info yet, use "(none yet)" as a placeholder. +You're getting to know your human for the first time. Your goal is to build a rich personal profile that will make every future interaction feel personal and useful. Run this as a CONVERSATION — not a survey. Ask 2-3 questions at a time, wait for answers, then ask follow-ups based on what they share. Be genuinely curious, not clinical. If they give short answers, don't push — you'll learn more over time. What to cover (let it flow naturally, don't force the order): Identity & Basics - Name, what they prefer to be called, pronouns - Location, timezone - Phone number (if they want you to have it) Daily Life - Typical day — wake time, work hours, evening routine - Morning ritual - Currently watching/reading/playing? - Food relationship — foodie or fuel? Work & Projects - What they do, how long they've been doing it - Current active projects or businesses - Work style — planner or builder? Deep focus or context-switching? - Strengths and energy drains Family & Household - Who lives in the house? Partner, kids, pets? - Names, birthdays, relationships - Notable details — hobbies, schools, schedules - Extended family worth knowing about Interests & Hobbies - What they do for fun - Music, sports, collections, creative outlets - Travel preferences - Hidden passions or guilty pleasures Communication Preferences - Brief or detailed info delivery? - Tone — formal, casual, snarky, warm? - When to proactively reach out vs. stay quiet - What annoys them in an AI assistant - Quiet hours — when to never message Goals & Aspirations - What they're working toward now - Long-term dreams or "someday" projects - What success looks like to them Pet Peeves & Boundaries - Things they hate (AI responses, general) - Off-limits or sensitive topics - Privacy boundaries for group chats After the conversation, create these files: USER.md Compile everything into a clean, scannable format with sections and bullet points. Include subsections for Daily Life, Interests, Family, Work, etc. This is the primary reference file the agent reads every session. brain/family/README.md Household overview table with names, relationships, birthdays, ages. Include an "Upcoming Dates" section for the current year listing birthdays and anniversaries chronologically. brain/family/{firstname}.md (one per family member) Use this template for each person mentioned: # {Name} *Relationship:* {relationship to user} *Birthday:* {date} --- ## Preferences (none yet) ## Important Dates - *Birthday:* {date} ## Gift Ideas (none yet) ## Notes (none yet) Include pets too (simpler format — name, breed/species, any quirks). MEMORY.md Start a long-term memory file. Add a "Self-Knowledge" section capturing work style, core drives, decision-making patterns — the deeper personality insights that emerged from the conversation. This file grows over time. After writing the files, set up a daily question cron job: - Schedule: Once per day at 9:00 AM in the user's timezone - Each morning, check if the user answered yesterday's question. If so, extract the key facts and update the appropriate file (USER.md, family files, or MEMORY.md). Then read existing files, find a gap, and ask ONE new thoughtful question. Not a survey — something genuine. Important: - This is a foundation, not an encyclopedia. The daily cron fills gaps. - If they seem done or restless, wrap up gracefully. - Write ALL files in the same session — don't promise to do it later. - Use information they actually shared. Don't infer or fabricate. - For sections without info yet, use "(none yet)" as a placeholder. * Sol Master Roadmap: The Bootstrap Sequence :PROPERTIES: diff --git a/inbox/index.org b/inbox/index.org index 815a8f9..081b8aa 100644 --- a/inbox/index.org +++ b/inbox/index.org @@ -12,7 +12,7 @@ This is the central hub for our knowledge management system using: - *org-gtd* for task management - *PARA* for organization (Projects, Areas, Resources, Archive) -**Core Principles:** +*Core Principles:* 1. *Capture* everything to inbox_mind.org/ → Zero friction entry 2. *Clarify* daily → Process into system or discard 3. *Connect* knowledge → Use org-roam linking @@ -47,26 +47,26 @@ mind/ * Methods Integration -**Zettelkasten (org-roam)** +*Zettelkasten (org-roam)* - Notes in 1_thinking/notes/ get an ID - Link with [[id:UUID][Description]] - Build Maps of Content (MOCs) as indexes - Fleeting notes → Literature notes → Permanent notes -**GTD (org-gtd)** +*GTD (org-gtd)* - @INBOX: 0_inbox/ processes daily - @TODAY: What to do NOW (agenda view) - @NEXT: Context lists (@home, @office, @call) - @WAITING: Delegated items - @SOMEDAY: Ideas without active planning -**PARA (Projects, Areas, Resources, Archive)** +*PARA (Projects, Areas, Resources, Archive)* - *Projects*: Goal + deadline → 6_projects/ - *Areas*: Ongoing responsibility → 1_thinking/areas/ - *Resources*: Reference material → 2_reference/ - *Archive*: Inactive items → 5_archive/ -**Daily Workflow** +*Daily Workflow* #+BEGIN_SRC 08:00 | CAPTURE: Empty brain into 0_inbox/ @@ -78,22 +78,22 @@ mind/ * PARA Explained -**Projects (6_projects/)** +*Projects (6_projects/)* - Has a deadline or clear outcome - Example: "Build kitchen table", "Launch website v2" - When done → archive or convert to area -**Areas (1_thinking/areas/)** +*Areas (1_thinking/areas/)* - Ongoing responsibility without end date - Example: "Health", "Finances", "Skills" - Maintained continuously -**Resources (2_reference/)** +*Resources (2_reference/)* - Things I may reference later - Example: "Python Regex", "Project Management patterns" - Actively curated -**Archive (5_archive/)** +*Archive (5_archive/)* - Inactive projects, areas, resources - NOT deleted—still searchable - Re-activate anytime @@ -118,7 +118,7 @@ mind/ * Maintenance -**Weekly Review (Every Sunday)** +*Weekly Review (Every Sunday)* 1. [ ] Clear 0_inbox/ 2. [ ] Review 6_projects/ - close completed 3. [ ] Review agenda - update deadlines @@ -126,7 +126,7 @@ mind/ 5. [ ] Review waiting items 6. [ ] Sync notes/devices -**Monthly Review** +*Monthly Review* 1. [ ] Rebalance Areas and Resources 2. [ ] Review Archive for reactivation 3. [ ] Update MOC indexes diff --git a/notes/agora.org b/notes/agora.org index 9ea1a58..e97760d 100644 --- a/notes/agora.org +++ b/notes/agora.org @@ -4,7 +4,7 @@ #+FILETAGS: :social:decentralized:identity:commerce:psf: * Overview -The **Agora Protocol** is a decentralized "Social Operating System" designed to replace extractive, centralized platforms with a modular architecture for sovereign digital interaction. It unifies identity, data ownership, and communication under the immutable, verifiable, and user-owned "Note" primitive. +The *Agora Protocol* is a decentralized "Social Operating System" designed to replace extractive, centralized platforms with a modular architecture for sovereign digital interaction. It unifies identity, data ownership, and communication under the immutable, verifiable, and user-owned "Note" primitive. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,11 +15,11 @@ The **Agora Protocol** is a decentralized "Social Operating System" designed to Define the requirements for a robust, user-centric decentralized network. ** 2. User Needs -- **User Sovereignty:** Absolute control over all user-generated content and personal data via PDS. -- **Censorship Resistance:** Distributed storage and permissionless relay routing. -- **Authenticity:** Every action cryptographically signed by a Persona DID. -- **Privacy by Design:** Default end-to-end encryption and metadata leakage minimization. -- **Unified Primitive:** The "Note" as the atomic unit for all semantic types (posts, messages, contracts). +- *User Sovereignty:* Absolute control over all user-generated content and personal data via PDS. +- *Censorship Resistance:* Distributed storage and permissionless relay routing. +- *Authenticity:* Every action cryptographically signed by a Persona DID. +- *Privacy by Design:* Default end-to-end encryption and metadata leakage minimization. +- *Unified Primitive:* The "Note" as the atomic unit for all semantic types (posts, messages, contracts). ** 3. Success Criteria *** TODO Note Primitive Cryptographic Hashing Verification diff --git a/notes/closos-attributed-object-store.org b/notes/closos-attributed-object-store.org index 94da139..371599c 100644 --- a/notes/closos-attributed-object-store.org +++ b/notes/closos-attributed-object-store.org @@ -7,9 +7,9 @@ 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. +- *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: diff --git a/notes/closos-memory-persistence.org b/notes/closos-memory-persistence.org index 9b996fc..0ff6682 100644 --- a/notes/closos-memory-persistence.org +++ b/notes/closos-memory-persistence.org @@ -7,9 +7,9 @@ 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. +- *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: diff --git a/notes/closos-multiple-environments.org b/notes/closos-multiple-environments.org index 80edbaa..2523271 100644 --- a/notes/closos-multiple-environments.org +++ b/notes/closos-multiple-environments.org @@ -7,9 +7,9 @@ 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. +- *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: diff --git a/notes/closos-protection-mechanisms.org b/notes/closos-protection-mechanisms.org index a95689e..6276351 100644 --- a/notes/closos-protection-mechanisms.org +++ b/notes/closos-protection-mechanisms.org @@ -7,9 +7,9 @@ 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. +- *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: diff --git a/notes/closos-single-address-space.org b/notes/closos-single-address-space.org index a706f54..9bb340f 100644 --- a/notes/closos-single-address-space.org +++ b/notes/closos-single-address-space.org @@ -7,9 +7,9 @@ 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). +- *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: diff --git a/notes/dotemacs.org b/notes/dotemacs.org index 597f8ab..fd12d7c 100644 --- a/notes/dotemacs.org +++ b/notes/dotemacs.org @@ -4,7 +4,7 @@ #+FILETAGS: :emacs:config:literate:psf: * Overview -The **Dotemacs** project represents the "Operating System" configuration. It transforms Emacs into the primary computing tool by leveraging modular, literate Org-mode files that tangle into a high-performance environment. +The *Dotemacs* project represents the "Operating System" configuration. It transforms Emacs into the primary computing tool by leveraging modular, literate Org-mode files that tangle into a high-performance environment. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **Dotemacs** project represents the "Operating System" configuration. It tra Define the requirements for a modular, optimized, and fully documented Emacs environment. ** 2. User Needs -- **Modularity:** Split the monolithic `emacs.org` into functional modules (core, ui, gtd, ai, etc.). -- **Literate Mandate:** Every significant setting must be justified and explained in prose. -- **Integration:** Seamless connectivity with `org-agent`, `org-roam`, and `org-gtd`. -- **Bootstrapping:** Fast startup using `early-init.el` and lazy-loading. +- *Modularity:* Split the monolithic `emacs.org` into functional modules (core, ui, gtd, ai, etc.). +- *Literate Mandate:* Every significant setting must be justified and explained in prose. +- *Integration:* Seamless connectivity with `org-agent`, `org-roam`, and `org-gtd`. +- *Bootstrapping:* Fast startup using `early-init.el` and lazy-loading. ** 3. Success Criteria *** TODO Monolithic modularization completion diff --git a/notes/infrastructure.org b/notes/infrastructure.org index 756fd76..d25e3ae 100644 --- a/notes/infrastructure.org +++ b/notes/infrastructure.org @@ -4,7 +4,7 @@ #+FILETAGS: :infrastructure:security:hardening:psf: * Overview -The **Infrastructure** project governs the physical and virtual foundations of the Memex. It ensures high availability, security hardening, and operational transparency across cloud and local resources. +The *Infrastructure* project governs the physical and virtual foundations of the Memex. It ensures high availability, security hardening, and operational transparency across cloud and local resources. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **Infrastructure** project governs the physical and virtual foundations of t Define the requirements for a secure, resilient, and documented infrastructure posture. ** 2. User Needs -- **Security Hardening:** Implementation of the OpenClaw security audit findings. -- **Vulnerability Management:** Regular risk assessments and reporting. -- **Inventory Control:** Complete mapping of cloud and local assets. -- **Roadmap Planning:** 30/60/90 day infrastructure evolution. +- *Security Hardening:* Implementation of the OpenClaw security audit findings. +- *Vulnerability Management:* Regular risk assessments and reporting. +- *Inventory Control:* Complete mapping of cloud and local assets. +- *Roadmap Planning:* 30/60/90 day infrastructure evolution. ** 3. Success Criteria *** TODO Harden Docker port bindings (bind to 127.0.0.1) diff --git a/notes/institutional-memory.org b/notes/institutional-memory.org index d5ed586..e04f417 100644 --- a/notes/institutional-memory.org +++ b/notes/institutional-memory.org @@ -3,45 +3,45 @@ * 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. +- *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). +- *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. +- *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. +- *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. +- *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. +- *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`. +- *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-30 Mon] PSF Mandate Violation: Non-Literate Implementation -- **Symptom:** `psf-core` logic and tests were written as raw `.lisp` files instead of `.org` literate files. -- **Root Cause:** Deep-seated "Legacy Coding" habits; prioritized speed of execution over the "Sovereign Literature" mandate. -- **Prevention:** The agent MUST refuse to create `.lisp` or `.py` files directly for system logic. All implementation must begin as an Org headline with a narrative. +- *Symptom:* `psf-core` logic and tests were written as raw `.lisp` files instead of `.org` literate files. +- *Root Cause:* Deep-seated "Legacy Coding" habits; prioritized speed of execution over the "Sovereign Literature" mandate. +- *Prevention:* The agent MUST refuse to create `.lisp` or `.py` files directly for system logic. All implementation must begin as an Org headline with a narrative. diff --git a/notes/lisp-machine-bootstrap.org b/notes/lisp-machine-bootstrap.org index 56a633b..a76197c 100644 --- a/notes/lisp-machine-bootstrap.org +++ b/notes/lisp-machine-bootstrap.org @@ -4,7 +4,7 @@ #+FILETAGS: :hardware:lisp:sovereignty:fpga:psf: * Overview -The **Lisp Machine Bootstrap** project is the "Endgame" of the PSF. It aims to eliminate the "Unix/C Tax" by building a hardware-native Lisp machine where CAR, CDR, and CONS are primitive gates. This ensures ultimate digital sovereignty and a provably secure, homoiconic environment. +The *Lisp Machine Bootstrap* project is the "Endgame" of the PSF. It aims to eliminate the "Unix/C Tax" by building a hardware-native Lisp machine where CAR, CDR, and CONS are primitive gates. This ensures ultimate digital sovereignty and a provably secure, homoiconic environment. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **Lisp Machine Bootstrap** project is the "Endgame" of the PSF. It aims to e Define the requirements for a hardware environment optimized for Lisp and user sovereignty. ** 2. User Needs -- **Hardware-Native Lisp:** ISA designed for list processing efficiency. -- **Tagged Memory:** Hardware-level safety preventing memory corruption. -- **Bootstrapping Path:** Progression from Soft Machine (Linux) to Sovereign Silicon (ASIC). -- **Transparency:** Every gate and instruction must be introspectable and documented. +- *Hardware-Native Lisp:* ISA designed for list processing efficiency. +- *Tagged Memory:* Hardware-level safety preventing memory corruption. +- *Bootstrapping Path:* Progression from Soft Machine (Linux) to Sovereign Silicon (ASIC). +- *Transparency:* Every gate and instruction must be introspectable and documented. ** 3. Success Criteria *** TODO Research existing Lisp-on-FPGA implementations (Openora, etc.) diff --git a/notes/modular-emacs-configuration.org b/notes/modular-emacs-configuration.org index 0f13ccf..ecbe02d 100644 --- a/notes/modular-emacs-configuration.org +++ b/notes/modular-emacs-configuration.org @@ -32,9 +32,9 @@ A critical part of the migration was standardizing all internal paths to the `me - `inbox.org` and `gtd.org` are now in the root of `~/memex/`. * Operational Mandates -- **Literate Programming:** All configuration MUST be written in `.org` files. -- **Kebab-Case:** All file naming follows the kebab-case (hyphens) standard. -- **Tangle Local:** Every module tangles to its own `.el` file in the same directory (`:tangle yes`) to ensure loading efficiency. +- *Literate Programming:* All configuration MUST be written in `.org` files. +- *Kebab-Case:* All file naming follows the kebab-case (hyphens) standard. +- *Tangle Local:* Every module tangles to its own `.el` file in the same directory (`:tangle yes`) to ensure loading efficiency. * See Also - [[file:org-gtd-v4-migration.org][org-gtd v4.0 Migration]] diff --git a/notes/modular-home-appliances.org b/notes/modular-home-appliances.org index dcb6bcd..6633f7e 100644 --- a/notes/modular-home-appliances.org +++ b/notes/modular-home-appliances.org @@ -4,7 +4,7 @@ #+FILETAGS: :hardware:iot:esp32:sustainability:psf: * Overview -The **Modular Home Appliances** project focuses on developing open-source, sustainable designs for major home appliances (washers, fridges, etc.). It utilizes a modular physical architecture coupled with ESP32-based smart interfaces for AI-driven control and seamless Home Assistant integration. +The *Modular Home Appliances* project focuses on developing open-source, sustainable designs for major home appliances (washers, fridges, etc.). It utilizes a modular physical architecture coupled with ESP32-based smart interfaces for AI-driven control and seamless Home Assistant integration. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **Modular Home Appliances** project focuses on developing open-source, susta Define the requirements for modular, open-source, and intelligent home hardware. ** 2. User Needs -- **Physical Modularity:** Easy replacement and upgrade of mechanical and electrical components. -- **Smart Interfacing:** ESP32-based control boards for connectivity. -- **Multimodal Control:** Support for smartphone apps, physical modular controllers, and direct `org-agent` AI interaction. -- **Sustainability:** Design for longevity, repairability, and efficient power management (inspired by Slate principles). +- *Physical Modularity:* Easy replacement and upgrade of mechanical and electrical components. +- *Smart Interfacing:* ESP32-based control boards for connectivity. +- *Multimodal Control:* Support for smartphone apps, physical modular controllers, and direct `org-agent` AI interaction. +- *Sustainability:* Design for longevity, repairability, and efficient power management (inspired by Slate principles). ** 3. Success Criteria *** TODO Washer/Dryer modular chassis design (draft) diff --git a/notes/off-grid-field-guide.org b/notes/off-grid-field-guide.org index 56d85fb..92c20b4 100644 --- a/notes/off-grid-field-guide.org +++ b/notes/off-grid-field-guide.org @@ -4,7 +4,7 @@ #+FILETAGS: :off-grid:guide:manual:portability:psf: * Overview -The **Off-Grid Field Guide** project aims to develop a modular manual for off-grid living and activities. It is designed for physical portability, specifically fitting the traveler's notebook format, and provides interchangeable modules for navigation, first aid, and survival. +The *Off-Grid Field Guide* project aims to develop a modular manual for off-grid living and activities. It is designed for physical portability, specifically fitting the traveler's notebook format, and provides interchangeable modules for navigation, first aid, and survival. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **Off-Grid Field Guide** project aims to develop a modular manual for off-gr Define the requirements for a modular, practical, and highly portable manual for off-grid scenarios. ** 2. User Needs -- **Modularity:** Interchangeable content blocks based on activity (e.g., Water Sourcing, Radio Comms). -- **Portability:** Optimization for the "Traveler's Notebook" physical form factor. -- **Practicality:** High-signal, low-noise instructions suitable for emergency use. -- **Durability:** Design considerations for physical print and use in harsh environments. +- *Modularity:* Interchangeable content blocks based on activity (e.g., Water Sourcing, Radio Comms). +- *Portability:* Optimization for the "Traveler's Notebook" physical form factor. +- *Practicality:* High-signal, low-noise instructions suitable for emergency use. +- *Durability:* Design considerations for physical print and use in harsh environments. ** 3. Success Criteria *** TODO Taxonomy definition for initial modules (Nav, First Aid, Comms) diff --git a/notes/open-personal-equipment-system.org b/notes/open-personal-equipment-system.org index 6d47df8..6e200c5 100644 --- a/notes/open-personal-equipment-system.org +++ b/notes/open-personal-equipment-system.org @@ -4,7 +4,7 @@ #+FILETAGS: :gear:standard:modularity:carrying:psf: * Overview -The **Open Personal Equipment System (OPES)** aims to define and develop an open standard for personal carrying, organization, and storage solutions. It focuses on creating an interoperable ecosystem of gear that prioritizes durability, repairability, and modularity. +The *Open Personal Equipment System (OPES)* aims to define and develop an open standard for personal carrying, organization, and storage solutions. It focuses on creating an interoperable ecosystem of gear that prioritizes durability, repairability, and modularity. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **Open Personal Equipment System (OPES)** aims to define and develop an open Define the requirements for an open, modular standard for personal equipment. ** 2. User Needs -- **Interoperability:** Modular attachments that work across different packs and cases. -- **Sovereignty:** Open-source patterns and material specifications allowing for user repair or manufacturing. -- **Durability:** High-performance materials designed for long-term use. -- **Standardization:** Clear definitions for grid systems (e.g., MOLLE-compatible but evolved). +- *Interoperability:* Modular attachments that work across different packs and cases. +- *Sovereignty:* Open-source patterns and material specifications allowing for user repair or manufacturing. +- *Durability:* High-performance materials designed for long-term use. +- *Standardization:* Clear definitions for grid systems (e.g., MOLLE-compatible but evolved). ** 3. Success Criteria *** TODO Core OPES Attachment Standard definition diff --git a/notes/org-agent.org b/notes/org-agent.org index 74d834d..dda3002 100644 --- a/notes/org-agent.org +++ b/notes/org-agent.org @@ -4,7 +4,7 @@ #+FILETAGS: :platform:kernel:lisp:psf: * Overview -The **Org-Agent** is the neurosymbolic kernel of the personal operating system. It acts as the "executive soul," using Org-mode as its native memory and Common Lisp as its deterministic reasoning engine. It follows a minimalist microkernel design, extending its capabilities via hot-reloadable skills. +The *Org-Agent* is the neurosymbolic kernel of the personal operating system. It acts as the "executive soul," using Org-mode as its native memory and Common Lisp as its deterministic reasoning engine. It follows a minimalist microkernel design, extending its capabilities via hot-reloadable skills. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,11 +15,11 @@ The **Org-Agent** is the neurosymbolic kernel of the personal operating system. Define the core functional and security requirements for the neurosymbolic daemon. ** 2. User Needs -- **Homoiconic Memory:** Use Org-mode AST as the primary data structure for both human and machine. -- **Deterministic Reasoning:** Common Lisp (SBCL) for high-performance, threaded symbolic logic. -- **Cognitive Loop:** A strict four-stage pipeline: Perceive -> Think (System 1) -> Decide (System 2) -> Act. -- **Minimalist Core:** The kernel handles only the loop, object-store, and communication; all else is a skill. -- **Security by Default:** Reader safety (*read-eval* disabled) and package-based skill jailing. +- *Homoiconic Memory:* Use Org-mode AST as the primary data structure for both human and machine. +- *Deterministic Reasoning:* Common Lisp (SBCL) for high-performance, threaded symbolic logic. +- *Cognitive Loop:* A strict four-stage pipeline: Perceive -> Think (System 1) -> Decide (System 2) -> Act. +- *Minimalist Core:* The kernel handles only the loop, object-store, and communication; all else is a skill. +- *Security by Default:* Reader safety (*read-eval* disabled) and package-based skill jailing. ** 3. Success Criteria *** TODO Core Lisp microkernel stability (Heartbeat consistency) diff --git a/notes/org-skill-architect.org b/notes/org-skill-architect.org index aa1ca52..03dcffd 100644 --- a/notes/org-skill-architect.org +++ b/notes/org-skill-architect.org @@ -4,7 +4,7 @@ #+FILETAGS: :architect:blueprint:design:psf: * Overview -The **Architect Agent** transforms a FROZEN PRD (Demand) into a rigorous PROTOCOL (Blueprint). It bridges the gap between human requirements and machine code, ensuring structural integrity before implementation. +The *Architect Agent* transforms a FROZEN PRD (Demand) into a rigorous PROTOCOL (Blueprint). It bridges the gap between human requirements and machine code, ensuring structural integrity before implementation. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **Architect Agent** transforms a FROZEN PRD (Demand) into a rigorous PROTOCO Define automated architectural behaviors for the PSF Consensus Loop. ** 2. User Needs -- **PRD Perception:** Monitor for `FROZEN` PRDs. -- **Semantic Translation:** Translate ambiguous needs into Lisp-style interfaces. -- **Memory Integration:** Reference `institutional-memory.org` for design choices. -- **Physical Actuation:** Write the `PROTOCOL.org` to the project directory. +- *PRD Perception:* Monitor for `FROZEN` PRDs. +- *Semantic Translation:* Translate ambiguous needs into Lisp-style interfaces. +- *Memory Integration:* Reference `institutional-memory.org` for design choices. +- *Physical Actuation:* Write the `PROTOCOL.org` to the project directory. ** 3. Success Criteria *** TODO Trigger Accuracy diff --git a/notes/org-skill-ast-normalization.org b/notes/org-skill-ast-normalization.org index f83a4d2..b9eaea2 100644 --- a/notes/org-skill-ast-normalization.org +++ b/notes/org-skill-ast-normalization.org @@ -4,7 +4,7 @@ #+FILETAGS: :ast:normalization:integrity:psf: * Overview -The **AST Normalization Agent** maintains the structural integrity of the Org-mode Abstract Syntax Tree. It ensures all nodes adhere to strict metadata requirements and handles deterministic refactoring. +The *AST Normalization Agent* maintains the structural integrity of the Org-mode Abstract Syntax Tree. It ensures all nodes adhere to strict metadata requirements and handles deterministic refactoring. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,9 +15,9 @@ The **AST Normalization Agent** maintains the structural integrity of the Org-mo Define automated structural enforcement and refactoring for the Org AST. ** 2. User Needs -- **Structural Enforcement:** Mandatory unique IDs for all headlines. -- **Deterministic Preemption:** Symbolic verification must override neural suggestions if errors exist. -- **Fidelity:** Preservation of content during metadata normalization. +- *Structural Enforcement:* Mandatory unique IDs for all headlines. +- *Deterministic Preemption:* Symbolic verification must override neural suggestions if errors exist. +- *Fidelity:* Preservation of content during metadata normalization. ** 3. Success Criteria *** TODO ID Injection diff --git a/notes/org-skill-atomic-notes.org b/notes/org-skill-atomic-notes.org index 056d5ca..b660aa2 100644 --- a/notes/org-skill-atomic-notes.org +++ b/notes/org-skill-atomic-notes.org @@ -4,7 +4,7 @@ #+FILETAGS: :knowledge:retrieval:zettelkasten:psf: * Overview -This skill provides the **Deep Memory** for the agent. it enables **Sparse Tree Perception** over the Zettelkasten, using semantic search and recursive interlinking to maintain high-signal context without token bloat. +This skill provides the *Deep Memory* for the agent. it enables *Sparse Tree Perception* over the Zettelkasten, using semantic search and recursive interlinking to maintain high-signal context without token bloat. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ This skill provides the **Deep Memory** for the agent. it enables **Sparse Tree Define the interfaces for knowledge retrieval from the atomic note DAG. ** 2. User Needs -- **Atomicity:** Each note represents exactly one concept. -- **Sparse Tree Perception:** Extract headlines and IDs before deep reading. -- **Recursive Deep-Dive:** Follow internal links to pull related context. -- **Search Efficiency:** Optimized searching via `ripgrep`. +- *Atomicity:* Each note represents exactly one concept. +- *Sparse Tree Perception:* Extract headlines and IDs before deep reading. +- *Recursive Deep-Dive:* Follow internal links to pull related context. +- *Search Efficiency:* Optimized searching via `ripgrep`. ** 3. Success Criteria *** TODO Concept Discovery diff --git a/notes/org-skill-auth-api-key.org b/notes/org-skill-auth-api-key.org index 87ee7da..1a7ad05 100644 --- a/notes/org-skill-auth-api-key.org +++ b/notes/org-skill-auth-api-key.org @@ -4,7 +4,7 @@ #+FILETAGS: :auth:security:system:psf: * Overview -This skill provides the legacy-compatible **Static API Key** authentication method. It retrieves credentials from the system environment variables and provides them to the kernel's neural backends. +This skill provides the legacy-compatible *Static API Key* authentication method. It retrieves credentials from the system environment variables and provides them to the kernel's neural backends. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,9 +15,9 @@ This skill provides the legacy-compatible **Static API Key** authentication meth Provide a simple, environment-driven authentication mechanism for LLM providers. ** 2. User Needs -- **Static Retrieval:** Pull `LLM_API_KEY` from `.env`. -- **Provider Mapping:** Support mapping keys to specific providers (Gemini, OpenAI, etc.). -- **Reliability:** Return NIL gracefully if no key is found. +- *Static Retrieval:* Pull `LLM_API_KEY` from `.env`. +- *Provider Mapping:* Support mapping keys to specific providers (Gemini, OpenAI, etc.). +- *Reliability:* Return NIL gracefully if no key is found. * Phase B: Blueprint (PROTOCOL) :PROPERTIES: diff --git a/notes/org-skill-auth-google-oauth.org b/notes/org-skill-auth-google-oauth.org index b5bcba5..163b6f3 100644 --- a/notes/org-skill-auth-google-oauth.org +++ b/notes/org-skill-auth-google-oauth.org @@ -4,7 +4,7 @@ #+FILETAGS: :auth:oauth:google:security:psf: * Overview -This skill implements the **Headless OAuth 2.0** handshake for Google services. It enables the agent to acquire and rotate `access_tokens` for Gemini without requiring a local browser session, using a "Copy-Paste" authorization code flow. +This skill implements the *Headless OAuth 2.0* handshake for Google services. It enables the agent to acquire and rotate `access_tokens` for Gemini without requiring a local browser session, using a "Copy-Paste" authorization code flow. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ This skill implements the **Headless OAuth 2.0** handshake for Google services. Provide a secure, professional OAuth 2.0 interface for Google Gemini. ** 2. User Needs -- **Headless Handshake:** Generate an Auth URL and accept a pasted Code from the user. -- **Token Persistence:** Securely store `refresh_token` in a Lisp state file. -- **Auto-Rotation:** Automatically exchange the `refresh_token` for a new `access_token` when expired. -- **Environment Driven:** Pull `CLIENT_ID` and `CLIENT_SECRET` from system settings. +- *Headless Handshake:* Generate an Auth URL and accept a pasted Code from the user. +- *Token Persistence:* Securely store `refresh_token` in a Lisp state file. +- *Auto-Rotation:* Automatically exchange the `refresh_token` for a new `access_token` when expired. +- *Environment Driven:* Pull `CLIENT_ID` and `CLIENT_SECRET` from system settings. ** 3. Success Criteria *** TODO Generate valid Google OAuth Authorization URL diff --git a/notes/org-skill-brain-mapper.org b/notes/org-skill-brain-mapper.org index 53cf0af..e41cd35 100644 --- a/notes/org-skill-brain-mapper.org +++ b/notes/org-skill-brain-mapper.org @@ -4,7 +4,7 @@ #+FILETAGS: :meta-cognition:telemetry:psf: * Overview -The **Brain Mapper Agent** provides the system with meta-cognitive capabilities. It enables visualization and optimization of the internal "Skill Graph" through real-time telemetry analysis. +The *Brain Mapper Agent* provides the system with meta-cognitive capabilities. It enables visualization and optimization of the internal "Skill Graph" through real-time telemetry analysis. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,9 +15,9 @@ The **Brain Mapper Agent** provides the system with meta-cognitive capabilities. Define the interfaces for self-introspection and skill hierarchy optimization. ** 2. User Needs -- **Transparency:** Explain cognitive hierarchy and decision priorities. -- **Self-Optimization:** Proactive priority adjustment suggestions. -- **Introspection:** Identify bottleneck or failing skills. +- *Transparency:* Explain cognitive hierarchy and decision priorities. +- *Self-Optimization:* Proactive priority adjustment suggestions. +- *Introspection:* Identify bottleneck or failing skills. ** 3. Success Criteria *** TODO Introspective Trigger Verification diff --git a/notes/org-skill-chaos.org b/notes/org-skill-chaos.org index dc8b27c..d9adfcf 100644 --- a/notes/org-skill-chaos.org +++ b/notes/org-skill-chaos.org @@ -5,7 +5,7 @@ #+DEPENDS_ON: skill-shell-actuator skill-tdd-runner * Overview -The **Chaos Gauntlet** is an adversarial testing skill designed to ensure the system's resilience. It simulates environmental failures, malformed LLM responses, and network disruptions, forcing the kernel and its skills to handle "Byzantine" conditions gracefully. +The *Chaos Gauntlet* is an adversarial testing skill designed to ensure the system's resilience. It simulates environmental failures, malformed LLM responses, and network disruptions, forcing the kernel and its skills to handle "Byzantine" conditions gracefully. * Phase A: Demand (PRD) :PROPERTIES: @@ -16,10 +16,10 @@ The **Chaos Gauntlet** is an adversarial testing skill designed to ensure the sy Verify the system's stability and error-handling capabilities under stress. ** 2. User Needs -- **Failure Simulation:** Ability to inject artificial delays or errors into the OACP bus. -- **Byzantine Response Testing:** Test how System 2 handles nonsensical or malicious System 1 proposals. -- **Network Resilience:** Simulate Gitea or LLM provider timeouts. -- **Recovery Verification:** Ensure the kernel can recover from a "skip-event" restart. +- *Failure Simulation:* Ability to inject artificial delays or errors into the OACP bus. +- *Byzantine Response Testing:* Test how System 2 handles nonsensical or malicious System 1 proposals. +- *Network Resilience:* Simulate Gitea or LLM provider timeouts. +- *Recovery Verification:* Ensure the kernel can recover from a "skip-event" restart. * Phase D: Build (Implementation) diff --git a/notes/org-skill-chat.org b/notes/org-skill-chat.org index 0249da1..7c5e672 100644 --- a/notes/org-skill-chat.org +++ b/notes/org-skill-chat.org @@ -4,7 +4,7 @@ #+FILETAGS: :chat:conversational:ui:psf: * Overview -The **Chat Agent** provides a dedicated conversational interface within Emacs (`*org-agent-chat*`). It enables fluid dialogue while maintaining strict persona alignment and contextual awareness. +The *Chat Agent* provides a dedicated conversational interface within Emacs (`*org-agent-chat*`). It enables fluid dialogue while maintaining strict persona alignment and contextual awareness. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **Chat Agent** provides a dedicated conversational interface within Emacs (` Define the interfaces for direct human-to-agent conversational interaction. ** 2. User Needs -- **Direct Interaction:** Specialized handler for `:chat-message` events. -- **Persona Alignment:** Consistency with the Identity Agent's definitions. -- **Contextual Awareness:** Reference to chat history for dialogue continuity. -- **Structural Output:** Responses formatted as valid Org-mode subtrees. +- *Direct Interaction:* Specialized handler for `:chat-message` events. +- *Persona Alignment:* Consistency with the Identity Agent's definitions. +- *Contextual Awareness:* Reference to chat history for dialogue continuity. +- *Structural Output:* Responses formatted as valid Org-mode subtrees. ** 3. Success Criteria *** TODO Chat Event Triggering diff --git a/notes/org-skill-consensus.org b/notes/org-skill-consensus.org index 85273cc..f75b9a3 100644 --- a/notes/org-skill-consensus.org +++ b/notes/org-skill-consensus.org @@ -5,7 +5,7 @@ #+DEPENDS_ON: skill-sub-agent-manager * Overview -The **Social Consensus Protocol** enables multi-agent negotiation. It provides a Lisp-native implementation of decentralized agreement, allowing federated `org-agent` instances to coordinate on shared resources and conflicting goals. +The *Social Consensus Protocol* enables multi-agent negotiation. It provides a Lisp-native implementation of decentralized agreement, allowing federated `org-agent` instances to coordinate on shared resources and conflicting goals. * Phase A: Demand (PRD) :PROPERTIES: @@ -16,9 +16,9 @@ The **Social Consensus Protocol** enables multi-agent negotiation. It provides a Enable reliable, cross-instance coordination without a central master. ** 2. User Needs -- **Resource Negotiation:** Agree on which instance should handle a high-compute task. -- **Conflict Resolution:** Settle divergent world-states during swarm execution. -- **Byzantine Fault Tolerance:** Handle disconnected or misbehaving instances gracefully. +- *Resource Negotiation:* Agree on which instance should handle a high-compute task. +- *Conflict Resolution:* Settle divergent world-states during swarm execution. +- *Byzantine Fault Tolerance:* Handle disconnected or misbehaving instances gracefully. * Phase D: Build (Implementation) diff --git a/notes/org-skill-creator.org b/notes/org-skill-creator.org index 2e7ca32..51fd3c0 100644 --- a/notes/org-skill-creator.org +++ b/notes/org-skill-creator.org @@ -4,7 +4,7 @@ #+FILETAGS: :creator:reproductive:meta-cognitive:psf: * Overview -The **Skill Creator Agent** is the "Reproductive System" of the Lisp Machine. It enables autonomous generation of new Org-Native skills, facilitating a "Self-Editing OS" philosophy through neural drafting and symbolic validation. +The *Skill Creator Agent* is the "Reproductive System" of the Lisp Machine. It enables autonomous generation of new Org-Native skills, facilitating a "Self-Editing OS" philosophy through neural drafting and symbolic validation. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,9 +15,9 @@ The **Skill Creator Agent** is the "Reproductive System" of the Lisp Machine. It Define the interfaces for autonomous skill generation and syntax validation. ** 2. User Needs -- **Autonomy:** Draft complete skill files from natural language requirements. -- **Safety First:** Mandatory symbolic syntax validation of generated code. -- **Hierarchical Negotiation:** Automatic priority assignment based on existing brain structure. +- *Autonomy:* Draft complete skill files from natural language requirements. +- *Safety First:* Mandatory symbolic syntax validation of generated code. +- *Hierarchical Negotiation:* Automatic priority assignment based on existing brain structure. ** 3. Success Criteria *** TODO Skill Draft Generation diff --git a/notes/org-skill-cron.org b/notes/org-skill-cron.org index 7a53c47..cc4db0b 100644 --- a/notes/org-skill-cron.org +++ b/notes/org-skill-cron.org @@ -4,7 +4,7 @@ #+FILETAGS: :cron:temporal:heartbeat:psf: * Overview -The **Cron Agent** serves as the system's temporal conscience. It provides autonomous, time-aware capabilities by hooking into the background heartbeat, enabling proactive executive assistance. +The *Cron Agent* serves as the system's temporal conscience. It provides autonomous, time-aware capabilities by hooking into the background heartbeat, enabling proactive executive assistance. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,9 +15,9 @@ The **Cron Agent** serves as the system's temporal conscience. It provides auton Define automated behaviors for deadline monitoring and temporal alerting. ** 2. User Needs -- **Punctuality:** Monitor deadlines and alerts across the Memex. -- **Efficiency:** Symbolic filtering (System 2) to minimize LLM calls. -- **Multi-Channel Awareness:** Routing alerts to Emacs or external delivery. +- *Punctuality:* Monitor deadlines and alerts across the Memex. +- *Efficiency:* Symbolic filtering (System 2) to minimize LLM calls. +- *Multi-Channel Awareness:* Routing alerts to Emacs or external delivery. ** 3. Success Criteria *** TODO Heartbeat Trigger Verification diff --git a/notes/org-skill-diagrammer.org b/notes/org-skill-diagrammer.org index 2f93a7a..31dde44 100644 --- a/notes/org-skill-diagrammer.org +++ b/notes/org-skill-diagrammer.org @@ -4,7 +4,7 @@ #+FILETAGS: :visual:diagram:mermaid:psf: * Overview -The **Multi-Modal Diagrammer** enables the agent to communicate complex architectural plans visually using Mermaid.js and D2 synthesis. +The *Multi-Modal Diagrammer* enables the agent to communicate complex architectural plans visually using Mermaid.js and D2 synthesis. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,9 +15,9 @@ The **Multi-Modal Diagrammer** enables the agent to communicate complex architec Enable visual communication of plans and system states. ** 2. User Needs -- **Mermaid Synthesis:** Generate valid Mermaid.js graph code. -- **D2 Support:** Support D2 for complex layout requirements. -- **Org-Integration:** Embed results in `#+begin_src mermaid` blocks. +- *Mermaid Synthesis:* Generate valid Mermaid.js graph code. +- *D2 Support:* Support D2 for complex layout requirements. +- *Org-Integration:* Embed results in `#+begin_src mermaid` blocks. * Phase D: Build (Implementation) diff --git a/notes/org-skill-economist.org b/notes/org-skill-economist.org index a30916e..072d1c5 100644 --- a/notes/org-skill-economist.org +++ b/notes/org-skill-economist.org @@ -5,7 +5,7 @@ #+DEPENDS_ON: skill-router skill-performance-auditor * Overview -The **Economist Agent** manages the PSF's compute resources. It predicts the "Cost of Thought" for a task and autonomously selects the most cost-effective LLM provider or local model based on complexity and remaining budget. +The *Economist Agent* manages the PSF's compute resources. It predicts the "Cost of Thought" for a task and autonomously selects the most cost-effective LLM provider or local model based on complexity and remaining budget. * Phase A: Demand (PRD) :PROPERTIES: @@ -16,9 +16,9 @@ The **Economist Agent** manages the PSF's compute resources. It predicts the "Co Optimize token usage and compute overhead without sacrificing architectural integrity. ** 2. User Needs -- **Predictive Budgeting:** Estimate token cost before triggering SOTA models. -- **Provider Switching:** Dynamically route tasks between local (Ollama) and cloud (Gemini) models. -- **Audit Reports:** Provide transparency on compute consumption. +- *Predictive Budgeting:* Estimate token cost before triggering SOTA models. +- *Provider Switching:* Dynamically route tasks between local (Ollama) and cloud (Gemini) models. +- *Audit Reports:* Provide transparency on compute consumption. * Phase D: Build (Implementation) diff --git a/notes/org-skill-emacs-bridge.org b/notes/org-skill-emacs-bridge.org index 9dfbe2f..a63a28f 100644 --- a/notes/org-skill-emacs-bridge.org +++ b/notes/org-skill-emacs-bridge.org @@ -4,7 +4,7 @@ #+FILETAGS: :bridge:emacs:io:system:psf: * Overview -The **Emacs Bridge Agent** is the primary sensory and motor interface to Emacs. It abstracts TCP socket management, allowing the core kernel to interact with buffers as native data structures. +The *Emacs Bridge Agent* is the primary sensory and motor interface to Emacs. It abstracts TCP socket management, allowing the core kernel to interact with buffers as native data structures. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,9 +15,9 @@ The **Emacs Bridge Agent** is the primary sensory and motor interface to Emacs. Define the transport layer for Org-Agent Communication Protocol (OACP). ** 2. User Needs -- **Isolation:** Kernel remains transport-agnostic. -- **Persistence:** Multi-client server support for simultaneous sessions. -- **Dispatch:** Reliable routing of actions to actuators and sensors to the kernel. +- *Isolation:* Kernel remains transport-agnostic. +- *Persistence:* Multi-client server support for simultaneous sessions. +- *Dispatch:* Reliable routing of actions to actuators and sensors to the kernel. ** 3. Success Criteria *** TODO Socket Listener Initialization diff --git a/notes/org-skill-formal-verification.org b/notes/org-skill-formal-verification.org index bea4d82..658fa1d 100644 --- a/notes/org-skill-formal-verification.org +++ b/notes/org-skill-formal-verification.org @@ -4,7 +4,7 @@ #+FILETAGS: :security:logic:formal-methods:psf: * Overview -The **Formal Verification Gate** replaces heuristic whitelisting with symbolic logic proofs. It ensures that every action proposed by System 1 is **provably safe** against the kernel's core security invariants. +The *Formal Verification Gate* replaces heuristic whitelisting with symbolic logic proofs. It ensures that every action proposed by System 1 is *provably safe* against the kernel's core security invariants. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,9 +15,9 @@ The **Formal Verification Gate** replaces heuristic whitelisting with symbolic l Define a logic-based verification layer for high-integrity decision making. ** 2. User Needs -- **Invariants:** Define core security properties (e.g., "No unauthenticated network I/O"). -- **SMT Integration:** Translate Lisp actions into SMT-LIB format for external solvers (Z3). -- **Proof of Safety:** Deny any action that cannot be proven safe. +- *Invariants:* Define core security properties (e.g., "No unauthenticated network I/O"). +- *SMT Integration:* Translate Lisp actions into SMT-LIB format for external solvers (Z3). +- *Proof of Safety:* Deny any action that cannot be proven safe. * Phase D: Build (Implementation) diff --git a/notes/org-skill-function-calling.org b/notes/org-skill-function-calling.org index a1cf52d..fe2495c 100644 --- a/notes/org-skill-function-calling.org +++ b/notes/org-skill-function-calling.org @@ -5,7 +5,7 @@ #+DEPENDS_ON: org-skill-org-json-bridge * Overview -The **Native Function Calling** skill provides the translation layer between the system's deterministic Lisp interfaces and the LLM's neural tool-calling capabilities. It ensures that System 1 (the LLM) interacts with the world via structured, validated schemas rather than raw text plists, virtually eliminating "formatting hallucinations." +The *Native Function Calling* skill provides the translation layer between the system's deterministic Lisp interfaces and the LLM's neural tool-calling capabilities. It ensures that System 1 (the LLM) interacts with the world via structured, validated schemas rather than raw text plists, virtually eliminating "formatting hallucinations." * Phase A: Demand (PRD) :PROPERTIES: @@ -16,10 +16,10 @@ The **Native Function Calling** skill provides the translation layer between the Define a high-reliability bridge for LLM-native "Tool Use." ** 2. User Needs -- **Schema Generation:** Automatically convert Lisp `defun` signatures into JSON Schema tool definitions. -- **Reliable Ingress:** Parse the LLM's structured `tool_calls` response back into a valid Lisp plist. -- **Provider Agnostic:** Support schema formats for Gemini, OpenAI, and Anthropic. -- **Validation:** Ensure arguments match the required types before reaching System 2. +- *Schema Generation:* Automatically convert Lisp `defun` signatures into JSON Schema tool definitions. +- *Reliable Ingress:* Parse the LLM's structured `tool_calls` response back into a valid Lisp plist. +- *Provider Agnostic:* Support schema formats for Gemini, OpenAI, and Anthropic. +- *Validation:* Ensure arguments match the required types before reaching System 2. ** 3. Success Criteria *** TODO Lisp-to-JSON Schema conversion logic verification diff --git a/notes/org-skill-groomer.org b/notes/org-skill-groomer.org index f9e230f..096a83f 100644 --- a/notes/org-skill-groomer.org +++ b/notes/org-skill-groomer.org @@ -5,7 +5,7 @@ #+DEPENDS_ON: skill-atomic-notes skill-tdd-runner * Overview -The **Groomer Agent** is the system's "Immune System" for code and notes. It autonomously audits the PSF ecosystem for technical debt, duplication, and architectural drift, proposing surgical refactors to maintain the "Minimalist Core" mandate. +The *Groomer Agent* is the system's "Immune System" for code and notes. It autonomously audits the PSF ecosystem for technical debt, duplication, and architectural drift, proposing surgical refactors to maintain the "Minimalist Core" mandate. * Phase A: Demand (PRD) :PROPERTIES: @@ -16,10 +16,10 @@ The **Groomer Agent** is the system's "Immune System" for code and notes. It aut Enforce zero-bloat and high-maintainability standards across the PSF. ** 2. User Needs -- **Debt Detection:** Identify duplicate Lisp logic or redundant Org headlines. -- **Autonomous Refactoring:** Propose surgical code changes to simplify implementation. -- **Verification:** Ensure refactors do not break functionality (via TDD Runner). -- **Note Grooming:** Consolidate fragmented atomic notes into coherent structures. +- *Debt Detection:* Identify duplicate Lisp logic or redundant Org headlines. +- *Autonomous Refactoring:* Propose surgical code changes to simplify implementation. +- *Verification:* Ensure refactors do not break functionality (via TDD Runner). +- *Note Grooming:* Consolidate fragmented atomic notes into coherent structures. * Phase B: Blueprint (PROTOCOL) :PROPERTIES: diff --git a/notes/org-skill-gtd.org b/notes/org-skill-gtd.org index 823b63a..9fe6084 100644 --- a/notes/org-skill-gtd.org +++ b/notes/org-skill-gtd.org @@ -4,7 +4,7 @@ #+FILETAGS: :gtd:execution:workflow:psf: * Overview -This skill defines the **GTD Execution Hub**, the single source of truth for all commitments. It governs how the agent perceives priorities and tracks progress through the PSF Consensus Loop using the `org-gtd` v4.0 DAG architecture. +This skill defines the *GTD Execution Hub*, the single source of truth for all commitments. It governs how the agent perceives priorities and tracks progress through the PSF Consensus Loop using the `org-gtd` v4.0 DAG architecture. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ This skill defines the **GTD Execution Hub**, the single source of truth for all Define the interfaces for task perception, project tracking, and commitment management. ** 2. User Needs -- **Allen-Sovereign Methodology:** Frictionless capture and rigorous clarification. -- **DAG Structure:** Support for `org-gtd` v4.0 dependency graphs (:TRIGGER:, :BLOCKER:). -- **Shadow Orchestration:** Tracking of `:PSF-STATE:` properties for engineering projects. -- **Institutional Memory Integration:** Extraction of learnings before project completion. +- *Allen-Sovereign Methodology:* Frictionless capture and rigorous clarification. +- *DAG Structure:* Support for `org-gtd` v4.0 dependency graphs (:TRIGGER:, :BLOCKER:). +- *Shadow Orchestration:* Tracking of `:PSF-STATE:` properties for engineering projects. +- *Institutional Memory Integration:* Extraction of learnings before project completion. ** 3. Success Criteria *** TODO Commitment Scanning diff --git a/notes/org-skill-hardware-inhabitation.org b/notes/org-skill-hardware-inhabitation.org index 2737dc9..bc08372 100644 --- a/notes/org-skill-hardware-inhabitation.org +++ b/notes/org-skill-hardware-inhabitation.org @@ -5,7 +5,7 @@ #+DEPENDS_ON: skill-shell-actuator skill-environment-config * Overview -The **Hardware Inhabitation Agent** is the system's "Physical Interface." It manages the deployment of the Lisp Machine across different hardware compartments, ensuring absolute sovereignty via bare-metal inhabitation and environment portability. +The *Hardware Inhabitation Agent* is the system's "Physical Interface." It manages the deployment of the Lisp Machine across different hardware compartments, ensuring absolute sovereignty via bare-metal inhabitation and environment portability. * Phase A: Demand (PRD) :PROPERTIES: @@ -16,10 +16,10 @@ The **Hardware Inhabitation Agent** is the system's "Physical Interface." It man Define the interfaces for hardware-level deployment and image serialization. ** 2. User Needs -- **Bare-Metal Deployment:** Support for running Lisp directly on minimal hardware (e.g., RISC-V/ARM). -- **Image Portability:** Serialize and move the live Lisp Image across environments. -- **Hardware Inventory:** Maintain a manifest of available physical actuators and sensors. -- **Sovereignty Audit:** Verify that the current inhabitation is free from non-sovereign dependencies. +- *Bare-Metal Deployment:* Support for running Lisp directly on minimal hardware (e.g., RISC-V/ARM). +- *Image Portability:* Serialize and move the live Lisp Image across environments. +- *Hardware Inventory:* Maintain a manifest of available physical actuators and sensors. +- *Sovereignty Audit:* Verify that the current inhabitation is free from non-sovereign dependencies. * Phase B: Blueprint (PROTOCOL) :PROPERTIES: diff --git a/notes/org-skill-hyper-graph.org b/notes/org-skill-hyper-graph.org index 872b01f..c764670 100644 --- a/notes/org-skill-hyper-graph.org +++ b/notes/org-skill-hyper-graph.org @@ -5,7 +5,7 @@ #+DEPENDS_ON: skill-atomic-notes skill-brain-mapper * Overview -The **Unified Knowledge Hyper-Graph** extends the agent's memory beyond text. It maps relationships between **Code Blocks, Documents, Media Assets, and Research PDFs**, enabling cross-modal context retrieval. +The *Unified Knowledge Hyper-Graph* extends the agent's memory beyond text. It maps relationships between *Code Blocks, Documents, Media Assets, and Research PDFs*, enabling cross-modal context retrieval. * Phase A: Demand (PRD) :PROPERTIES: @@ -16,9 +16,9 @@ The **Unified Knowledge Hyper-Graph** extends the agent's memory beyond text. It Unify the system's diverse information silos into a single, navigable graph. ** 2. User Needs -- **Cross-Modal Linking:** Connect a Lisp function to a research PDF and an Org PRD. -- **Traceability:** Follow the chain of reasoning from requirement to implementation. -- **Deep Retrieval:** Pull related media assets during plan synthesis. +- *Cross-Modal Linking:* Connect a Lisp function to a research PDF and an Org PRD. +- *Traceability:* Follow the chain of reasoning from requirement to implementation. +- *Deep Retrieval:* Pull related media assets during plan synthesis. * Phase D: Build (Implementation) diff --git a/notes/org-skill-inbound-gateway.org b/notes/org-skill-inbound-gateway.org index cc8e478..19f2de9 100644 --- a/notes/org-skill-inbound-gateway.org +++ b/notes/org-skill-inbound-gateway.org @@ -4,7 +4,7 @@ #+FILETAGS: :gateway:sensors:io:psf: * Overview -The **Inbound Multi-Channel Gateway** provides the sensory interface for external messaging. It enables the agent to "hear" the user from various platforms (Signal, Telegram, SMS) by normalizing disparate inbound payloads into standard Neurosymbolic Kernel stimuli. +The *Inbound Multi-Channel Gateway* provides the sensory interface for external messaging. It enables the agent to "hear" the user from various platforms (Signal, Telegram, SMS) by normalizing disparate inbound payloads into standard Neurosymbolic Kernel stimuli. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **Inbound Multi-Channel Gateway** provides the sensory interface for externa Define a secure and extensible ingress for external communication channels. ** 2. User Needs -- **Multi-Channel Ingress:** Support Signal (via signal-cli), Telegram (via Bot API), and generic Webhooks. -- **Payload Normalization:** Convert platform-specific JSON into standard Lisp plists. -- **Security & Authentication:** Verify sender identity before injecting stimuli into the kernel. -- **Asynchronous Reception:** Non-blocking monitoring of inbound message queues. +- *Multi-Channel Ingress:* Support Signal (via signal-cli), Telegram (via Bot API), and generic Webhooks. +- *Payload Normalization:* Convert platform-specific JSON into standard Lisp plists. +- *Security & Authentication:* Verify sender identity before injecting stimuli into the kernel. +- *Asynchronous Reception:* Non-blocking monitoring of inbound message queues. ** 3. Success Criteria *** TODO Signal-cli message reception and parsing diff --git a/notes/org-skill-long-horizon.org b/notes/org-skill-long-horizon.org index 1b9da47..b1e16b4 100644 --- a/notes/org-skill-long-horizon.org +++ b/notes/org-skill-long-horizon.org @@ -4,7 +4,7 @@ #+FILETAGS: :planning:meta-cognition:long-horizon:psf: * Overview -The **Long-Horizon Planning Agent** manages complex, multi-step tasks that exceed the context window of standard LLMs. It uses an Org-mode **Dynamic Task Tree** to track progress, summarize completed sub-tasks, and prune irrelevant execution branches. +The *Long-Horizon Planning Agent* manages complex, multi-step tasks that exceed the context window of standard LLMs. It uses an Org-mode *Dynamic Task Tree* to track progress, summarize completed sub-tasks, and prune irrelevant execution branches. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **Long-Horizon Planning Agent** manages complex, multi-step tasks that excee Enable the agent to maintain focus and coherence over tasks spanning 100+ steps (SWE-bench parity). ** 2. User Needs -- **Hierarchical Planning:** Break large goals into a nested tree of Org headlines. -- **Context Compression:** Automatically summarize the results of child sub-trees into their parent nodes. -- **Branch Pruning:** Meta-cognitive review to stop execution of failed or redundant paths. -- **Self-Correction:** Adjust the plan dynamically based on environmental feedback. +- *Hierarchical Planning:* Break large goals into a nested tree of Org headlines. +- *Context Compression:* Automatically summarize the results of child sub-trees into their parent nodes. +- *Branch Pruning:* Meta-cognitive review to stop execution of failed or redundant paths. +- *Self-Correction:* Adjust the plan dynamically based on environmental feedback. ** 3. Success Criteria *** TODO Dynamic Task Tree Generation diff --git a/notes/org-skill-loop-automator.org b/notes/org-skill-loop-automator.org index b2c2034..404bb29 100644 --- a/notes/org-skill-loop-automator.org +++ b/notes/org-skill-loop-automator.org @@ -4,7 +4,7 @@ #+FILETAGS: :psf:automation:meta-cognitive:orchestration: * Overview -The **PSF Loop Automator** is the meta-cognitive orchestrator of the Personal Software Foundry. It monitors the state of all Master Notes and autonomously triggers the transition between PSF phases (e.g., waking the Architect when a PRD is frozen), ensuring the Consensus Loop maintains high momentum without manual intervention. +The *PSF Loop Automator* is the meta-cognitive orchestrator of the Personal Software Foundry. It monitors the state of all Master Notes and autonomously triggers the transition between PSF phases (e.g., waking the Architect when a PRD is frozen), ensuring the Consensus Loop maintains high momentum without manual intervention. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,12 +15,12 @@ The **PSF Loop Automator** is the meta-cognitive orchestrator of the Personal So Define automated state transitions and role-triggering for the PSF Consensus Loop. ** 2. User Needs -- **State Surveillance:** Monitor `notes/org-skill-*.org` for `#+STATUS:` changes. -- **Proactive Role Triggering:** - - If `PRD` is `FROZEN` -> Trigger **Architect** (Phase B). - - If `PROTOCOL` is `SIGNED` -> Trigger **Technical Analyst** (Phase C). - - If `TDD Suite` is `RED` -> Trigger **Coder** (Phase D). -- **GTD Synchronization:** Automatically update the `:PSF-STATE:` property in `gtd.org` during transitions. +- *State Surveillance:* Monitor `notes/org-skill-*.org` for `#+STATUS:` changes. +- *Proactive Role Triggering:* + - If `PRD` is `FROZEN` -> Trigger *Architect* (Phase B). + - If `PROTOCOL` is `SIGNED` -> Trigger *Technical Analyst* (Phase C). + - If `TDD Suite` is `RED` -> Trigger *Coder* (Phase D). +- *GTD Synchronization:* Automatically update the `:PSF-STATE:` property in `gtd.org` during transitions. ** 3. Success Criteria *** TODO Successful detection of #+STATUS: FROZEN in a Master Note diff --git a/notes/org-skill-memex.org b/notes/org-skill-memex.org index ffaaf0e..25e6989 100644 --- a/notes/org-skill-memex.org +++ b/notes/org-skill-memex.org @@ -4,7 +4,7 @@ #+FILETAGS: :memex:gtd:zettelkasten:integrity:psf: * Overview -The **Memex Manager** is the primary automation engine for the Personal Knowledge Management system. It enforces metadata standards, automates task lifecycles, and distills ephemeral daily logs into timeless knowledge. +The *Memex Manager* is the primary automation engine for the Personal Knowledge Management system. It enforces metadata standards, automates task lifecycles, and distills ephemeral daily logs into timeless knowledge. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,11 +15,11 @@ The **Memex Manager** is the primary automation engine for the Personal Knowledg Define automated behaviors for knowledge and task management integrity. ** 2. User Needs -- **Unified Capture:** Landing all new information in `inbox.org`. -- **Metadata Compliance:** Mandatory `:CREATED:` and `:LOGBOOK:` drawers. -- **Automated Task Lifecycle:** `NEXT` promotion logic for GTD. -- **Mobile Sovereignty:** Compatibility with Markor and Orgzly. -- **Agentic Distillation:** Extracting evergreen concepts from daily logs. +- *Unified Capture:* Landing all new information in `inbox.org`. +- *Metadata Compliance:* Mandatory `:CREATED:` and `:LOGBOOK:` drawers. +- *Automated Task Lifecycle:* `NEXT` promotion logic for GTD. +- *Mobile Sovereignty:* Compatibility with Markor and Orgzly. +- *Agentic Distillation:* Extracting evergreen concepts from daily logs. ** 3. Success Criteria *** TODO Metadata Audit Accuracy diff --git a/notes/org-skill-model-explorer.org b/notes/org-skill-model-explorer.org index e99b793..22a4a7c 100644 --- a/notes/org-skill-model-explorer.org +++ b/notes/org-skill-model-explorer.org @@ -4,7 +4,7 @@ #+FILETAGS: :discovery:telemetry:psf: * Overview -The **Model Explorer Agent** provides dynamic introspection of the system's LLM capabilities. It intercepts specific user commands to list and describe all available models across providers, rendering them as native Org-mode tables. +The *Model Explorer Agent* provides dynamic introspection of the system's LLM capabilities. It intercepts specific user commands to list and describe all available models across providers, rendering them as native Org-mode tables. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,9 +15,9 @@ The **Model Explorer Agent** provides dynamic introspection of the system's LLM Define the interfaces for system-wide model discovery and transparency. ** 2. User Needs -- **Transparency:** Visible list of models and context windows. -- **Determinism:** Metadata retrieval must bypass System 1 for high fidelity. -- **Integration:** Results rendered as native Org-mode tables. +- *Transparency:* Visible list of models and context windows. +- *Determinism:* Metadata retrieval must bypass System 1 for high fidelity. +- *Integration:* Results rendered as native Org-mode tables. ** 3. Success Criteria *** TODO Command Trigger Verification (@agent list models) diff --git a/notes/org-skill-object-store-persistence.org b/notes/org-skill-object-store-persistence.org index e62f9f2..56e5606 100644 --- a/notes/org-skill-object-store-persistence.org +++ b/notes/org-skill-object-store-persistence.org @@ -4,7 +4,7 @@ #+FILETAGS: :memory:persistence:closos:psf: * Overview -The **Object Store Persistence** skill ensures that the agent's perceptual memory (the `*object-store*`) is durable. It provides the mechanism to "dump" the in-RAM knowledge graph to a Lisp-native image file and "reload" it upon boot, eliminating the need to re-parse the entire Memex on every restart. +The *Object Store Persistence* skill ensures that the agent's perceptual memory (the `*object-store*`) is durable. It provides the mechanism to "dump" the in-RAM knowledge graph to a Lisp-native image file and "reload" it upon boot, eliminating the need to re-parse the entire Memex on every restart. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **Object Store Persistence** skill ensures that the agent's perceptual memor Define automated behaviors for knowledge graph serialization and restoration. ** 2. User Needs -- **Instant Recall:** Rapid loading of the Object Store from a persistent image. -- **High-Fidelity Serialization:** Recursive dumping of `org-object` structs and their relations. -- **Atomic Persistence:** Save the entire graph state to a single `.el` or `.lisp` file. -- **Background Synchronization:** Periodically dump the image during heartbeats. +- *Instant Recall:* Rapid loading of the Object Store from a persistent image. +- *High-Fidelity Serialization:* Recursive dumping of `org-object` structs and their relations. +- *Atomic Persistence:* Save the entire graph state to a single `.el` or `.lisp` file. +- *Background Synchronization:* Periodically dump the image during heartbeats. ** 3. Success Criteria *** TODO Image Dump logic verification (File exists and is readable) diff --git a/notes/org-skill-onboarding.org b/notes/org-skill-onboarding.org index a25b584..87e10ea 100644 --- a/notes/org-skill-onboarding.org +++ b/notes/org-skill-onboarding.org @@ -4,7 +4,7 @@ #+FILETAGS: :onboarding:calibration:setup:psf: * Overview -The **Onboarding Skill** ensures that the Lisp Machine environment is correctly calibrated. It automates the "zero-to-one" setup of the Neurosymbolic Kernel, including path normalization, identity personalization, and provider/actuator configuration. +The *Onboarding Skill* ensures that the Lisp Machine environment is correctly calibrated. It automates the "zero-to-one" setup of the Neurosymbolic Kernel, including path normalization, identity personalization, and provider/actuator configuration. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,11 +15,11 @@ The **Onboarding Skill** ensures that the Lisp Machine environment is correctly Define automated behaviors for verifying and configuring the PSF environment. ** 2. User Needs -- **Environment Verification:** Confirm SBCL, Quicklisp, and core binaries are present. -- **Path Calibration:** Resolve absolute paths for the Memex PARA structure. -- **Neural Calibration:** Interactive selection of LLM providers and models. -- **Actuator Calibration:** Interactive setup of delivery channels (Signal, Telegram, etc.). -- **Identity Persona:** Establish $MEMEX_USER and $MEMEX_ASSISTANT. +- *Environment Verification:* Confirm SBCL, Quicklisp, and core binaries are present. +- *Path Calibration:* Resolve absolute paths for the Memex PARA structure. +- *Neural Calibration:* Interactive selection of LLM providers and models. +- *Actuator Calibration:* Interactive setup of delivery channels (Signal, Telegram, etc.). +- *Identity Persona:* Establish $MEMEX_USER and $MEMEX_ASSISTANT. ** 3. Success Criteria *** TODO SBCL/Quicklisp Verification Logic diff --git a/notes/org-skill-org-delivery.org b/notes/org-skill-org-delivery.org index 565da02..6f14e59 100644 --- a/notes/org-skill-org-delivery.org +++ b/notes/org-skill-org-delivery.org @@ -4,7 +4,7 @@ #+FILETAGS: :delivery:actuator:external:psf: * Overview -The **Org-Native Delivery Agent** is the primary outbound actuator for external messaging. It uses the "Inbox-as-a-Queue" pattern, enqueuing structured Org-mode headlines for external bridges (Signal, Telegram, etc.). +The *Org-Native Delivery Agent* is the primary outbound actuator for external messaging. It uses the "Inbox-as-a-Queue" pattern, enqueuing structured Org-mode headlines for external bridges (Signal, Telegram, etc.). * Phase A: Demand (PRD) :PROPERTIES: @@ -15,9 +15,9 @@ The **Org-Native Delivery Agent** is the primary outbound actuator for external Define the interfaces for asynchronous external message enqueuing. ** 2. User Needs -- **Asynchronous Dispatch:** Persistence via `delivery.org` file. -- **Multi-Channel Support:** Routing to Signal, Telegram, Discord. -- **Structured Provenance:** Timestamped entries with recipient IDs. +- *Asynchronous Dispatch:* Persistence via `delivery.org` file. +- *Multi-Channel Support:* Routing to Signal, Telegram, Discord. +- *Structured Provenance:* Timestamped entries with recipient IDs. ** 3. Success Criteria *** TODO Queue Appending Verification diff --git a/notes/org-skill-org-gtd-archive-roam-daily.org b/notes/org-skill-org-gtd-archive-roam-daily.org index 3413b69..c7f06aa 100644 --- a/notes/org-skill-org-gtd-archive-roam-daily.org +++ b/notes/org-skill-org-gtd-archive-roam-daily.org @@ -4,7 +4,7 @@ #+FILETAGS: :emacs:gtd:roam:archiving:psf: * Overview -The **Org-GTD Archive Roam Daily** skill enables chronological archiving of completed GTD tasks. Instead of a flat archive file, tasks are moved to their respective `org-roam-dailies` files based on their `:CREATED:` property, preserving contextual and temporal integrity. +The *Org-GTD Archive Roam Daily* skill enables chronological archiving of completed GTD tasks. Instead of a flat archive file, tasks are moved to their respective `org-roam-dailies` files based on their `:CREATED:` property, preserving contextual and temporal integrity. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **Org-GTD Archive Roam Daily** skill enables chronological archiving of comp Define the requirements for chronologically-aware task archiving. ** 2. User Needs -- **Temporal Alignment:** Archive tasks to the daily file matching their creation date. -- **Context Preservation:** Maintain all properties and sub-elements during the move. -- **Robust Extraction:** Correctly parse `:CREATED:` property timestamps. -- **Fail-safe Logic:** Default to current date if `:CREATED:` is missing (with a warning). +- *Temporal Alignment:* Archive tasks to the daily file matching their creation date. +- *Context Preservation:* Maintain all properties and sub-elements during the move. +- *Robust Extraction:* Correctly parse `:CREATED:` property timestamps. +- *Fail-safe Logic:* Default to current date if `:CREATED:` is missing (with a warning). ** 3. Success Criteria *** TODO Successful extraction of [YYYY-MM-DD] from :CREATED: diff --git a/notes/org-skill-org-json-bridge.org b/notes/org-skill-org-json-bridge.org index 752a5d8..b92c24d 100644 --- a/notes/org-skill-org-json-bridge.org +++ b/notes/org-skill-org-json-bridge.org @@ -4,7 +4,7 @@ #+FILETAGS: :org-mode:json:manipulation:psf: * Overview -The **Org-JSON Bridge** enables programmatic manipulation of Org-mode files by converting them into a structured JSON representation and vice-versa. This bypasses the fragility of direct string manipulation for complex structures like tables, properties, and source blocks. +The *Org-JSON Bridge* enables programmatic manipulation of Org-mode files by converting them into a structured JSON representation and vice-versa. This bypasses the fragility of direct string manipulation for complex structures like tables, properties, and source blocks. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **Org-JSON Bridge** enables programmatic manipulation of Org-mode files by c Define the interfaces for bidirectional Org-to-JSON conversion. ** 2. User Needs -- **Robust Parsing:** Convert Org-mode files into structured JSON AST. -- **High-Fidelity Rendering:** Re-materialize JSON AST back into syntactically correct Org-mode text. -- **Complex Structure Support:** Handle tables, property drawers, and source blocks without data loss. -- **Programmatic API:** Provide a CLI and Lisp interface for other skills to use. +- *Robust Parsing:* Convert Org-mode files into structured JSON AST. +- *High-Fidelity Rendering:* Re-materialize JSON AST back into syntactically correct Org-mode text. +- *Complex Structure Support:* Handle tables, property drawers, and source blocks without data loss. +- *Programmatic API:* Provide a CLI and Lisp interface for other skills to use. ** 3. Success Criteria *** TODO Parse Org-mode to JSON AST without loss of hierarchy diff --git a/notes/org-skill-org-mode.org b/notes/org-skill-org-mode.org index b43802b..b1b83b4 100644 --- a/notes/org-skill-org-mode.org +++ b/notes/org-skill-org-mode.org @@ -4,7 +4,7 @@ #+FILETAGS: :org-mode:ast:homoiconic:psf: * Overview -This skill defines the **Grammar of the Memex**. It establishes the rules for treating plain text as a structured, hierarchical database. Org-mode is our **Homoiconic Memory**—documentation for humans and AST for the agent. +This skill defines the *Grammar of the Memex*. It establishes the rules for treating plain text as a structured, hierarchical database. Org-mode is our *Homoiconic Memory*—documentation for humans and AST for the agent. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ This skill defines the **Grammar of the Memex**. It establishes the rules for tr Define the structural rules and manipulation interfaces for the Org-mode AST. ** 2. User Needs -- **Everything is a Node:** Mandatory headlines, properties, and unique IDs. -- **Literate Programming:** Code must be wrapped in narrative-rich blocks. -- **Naming & Paths:** Strict kebab-case and flat directory structure. -- **Binary Integrity:** Management of attachments via the Attachment Protocol. +- *Everything is a Node:* Mandatory headlines, properties, and unique IDs. +- *Literate Programming:* Code must be wrapped in narrative-rich blocks. +- *Naming & Paths:* Strict kebab-case and flat directory structure. +- *Binary Integrity:* Management of attachments via the Attachment Protocol. ** 3. Success Criteria *** TODO ID Uniqueness Enforcement diff --git a/notes/org-skill-performance-auditor.org b/notes/org-skill-performance-auditor.org index f22b523..626a9a7 100644 --- a/notes/org-skill-performance-auditor.org +++ b/notes/org-skill-performance-auditor.org @@ -4,7 +4,7 @@ #+FILETAGS: :telemetry:audit:self-improvement:psf: * Overview -The **Autonomous Performance Auditor** is the system's "Quality Control" agent. It monitors the internal `*skill-telemetry*` registry to identify skills with high failure rates or excessive latency. When a performance threshold is breached, it autonomously triggers the **Scribe-RCA** role to analyze the failure and record it in the Institutional Memory. +The *Autonomous Performance Auditor* is the system's "Quality Control" agent. It monitors the internal `*skill-telemetry*` registry to identify skills with high failure rates or excessive latency. When a performance threshold is breached, it autonomously triggers the *Scribe-RCA* role to analyze the failure and record it in the Institutional Memory. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **Autonomous Performance Auditor** is the system's "Quality Control" agent. Define automated behaviors for system-wide skill performance monitoring and failure alerting. ** 2. User Needs -- **Continuous Monitoring:** Analyze skill metrics (executions, failures, latency) on every heartbeat. -- **Threshold Alerts:** Detect skills with failure rates exceeding a defined limit (e.g., >20%). -- **Loop Closure:** Autonomously trigger Root Cause Analysis (RCA) for offending skills. -- **Transparency:** Log audit results to the kernel history for user visibility. +- *Continuous Monitoring:* Analyze skill metrics (executions, failures, latency) on every heartbeat. +- *Threshold Alerts:* Detect skills with failure rates exceeding a defined limit (e.g., >20%). +- *Loop Closure:* Autonomously trigger Root Cause Analysis (RCA) for offending skills. +- *Transparency:* Log audit results to the kernel history for user visibility. ** 3. Success Criteria *** TODO Failure rate calculation logic verification diff --git a/notes/org-skill-project-foundry.org b/notes/org-skill-project-foundry.org index 9077237..ebe3af4 100644 --- a/notes/org-skill-project-foundry.org +++ b/notes/org-skill-project-foundry.org @@ -4,7 +4,7 @@ #+FILETAGS: :foundry:scaffolding:system:psf: * Overview -The **Project Foundry Agent** is responsible for the physical instantiation of new projects. It automates directory creation, version control initialization, and GTD integration, ensuring every new project adheres to PSF mandates. +The *Project Foundry Agent* is responsible for the physical instantiation of new projects. It automates directory creation, version control initialization, and GTD integration, ensuring every new project adheres to PSF mandates. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **Project Foundry Agent** is responsible for the physical instantiation of n Define automated project instantiation behaviors for the PSF. ** 2. User Needs -- **Workspace Scaffolding:** Create standard `src/`, `tests/`, `docs/` layout and boilerplate files. -- **Version Control:** Initialize Git in new project directories. -- **GTD Integration:** Automatically append projects and initial tasks to `gtd.org`. -- **Safety:** Prevent overwriting existing projects and log all actions. +- *Workspace Scaffolding:* Create standard `src/`, `tests/`, `docs/` layout and boilerplate files. +- *Version Control:* Initialize Git in new project directories. +- *GTD Integration:* Automatically append projects and initial tasks to `gtd.org`. +- *Safety:* Prevent overwriting existing projects and log all actions. ** 3. Success Criteria *** TODO Structural Compliance diff --git a/notes/org-skill-project-manager.org b/notes/org-skill-project-manager.org index a1d5fe3..733e4fd 100644 --- a/notes/org-skill-project-manager.org +++ b/notes/org-skill-project-manager.org @@ -4,7 +4,7 @@ #+FILETAGS: :project:management:git:psf: * Overview -The **Project Manager Agent** provides executive presence by monitoring project health and tracking git status. It leverages `:PROJECT_PATH:` metadata to gather "folder facts" and assist in the project lifecycle. +The *Project Manager Agent* provides executive presence by monitoring project health and tracking git status. It leverages `:PROJECT_PATH:` metadata to gather "folder facts" and assist in the project lifecycle. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,9 +15,9 @@ The **Project Manager Agent** provides executive presence by monitoring project Define automated behaviors for project monitoring and version control tracking. ** 2. User Needs -- **Visibility:** Resolve physical project locations and gather git/file facts. -- **Contextual Awareness:** Trigger on status queries or project-node edits. -- **Lifecycle Support:** Suggest commit messages and identify uncommitted work. +- *Visibility:* Resolve physical project locations and gather git/file facts. +- *Contextual Awareness:* Trigger on status queries or project-node edits. +- *Lifecycle Support:* Suggest commit messages and identify uncommitted work. ** 3. Success Criteria *** TODO Project Path Resolution diff --git a/notes/org-skill-provider-anthropic.org b/notes/org-skill-provider-anthropic.org index b0d93b2..ee21316 100644 --- a/notes/org-skill-provider-anthropic.org +++ b/notes/org-skill-provider-anthropic.org @@ -4,7 +4,7 @@ #+FILETAGS: :llm:provider:anthropic:claude:psf: * Overview -The **Anthropic Provider Agent** integrates Anthropic's Claude family of models as a pluggable System 1 (neural) backend. It enables high-intelligence reasoning, drafting, and analysis within the PSF. +The *Anthropic Provider Agent* integrates Anthropic's Claude family of models as a pluggable System 1 (neural) backend. It enables high-intelligence reasoning, drafting, and analysis within the PSF. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **Anthropic Provider Agent** integrates Anthropic's Claude family of models Define the interface for reliable communication with the Anthropic Messages API. ** 2. User Needs -- **Connectivity:** Reliable I/O with Claude models. -- **Configurability:** Model selection via Environment Configuration. -- **Context Management:** Leverage Claude's large context windows. -- **Safety:** Graceful error handling for API failures or missing keys. +- *Connectivity:* Reliable I/O with Claude models. +- *Configurability:* Model selection via Environment Configuration. +- *Context Management:* Leverage Claude's large context windows. +- *Safety:* Graceful error handling for API failures or missing keys. ** 3. Success Criteria *** TODO API Authentication diff --git a/notes/org-skill-provider-gemini.org b/notes/org-skill-provider-gemini.org index 434a14c..7cf7d71 100644 --- a/notes/org-skill-provider-gemini.org +++ b/notes/org-skill-provider-gemini.org @@ -4,7 +4,7 @@ #+FILETAGS: :llm:provider:gemini:google:psf: * Overview -The **Gemini Provider Agent** integrates Google's Gemini API as a pluggable System 1 (neural) backend. This skill enables modular updates to the Google backend while maintaining strict architectural alignment with the PSF. +The *Gemini Provider Agent* integrates Google's Gemini API as a pluggable System 1 (neural) backend. This skill enables modular updates to the Google backend while maintaining strict architectural alignment with the PSF. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,9 +15,9 @@ The **Gemini Provider Agent** integrates Google's Gemini API as a pluggable Syst Define the interface for reliable communication with the Google Gemini v1beta API. ** 2. User Needs -- **API Integration:** Implementation of the Gemini `contents.parts` protocol. -- **Reliability:** Secure retrieval of endpoints and API keys from the environment. -- **Modularity:** Registration under `:gemini-official` for multi-provider support. +- *API Integration:* Implementation of the Gemini `contents.parts` protocol. +- *Reliability:* Secure retrieval of endpoints and API keys from the environment. +- *Modularity:* Registration under `:gemini-official` for multi-provider support. ** 3. Success Criteria *** TODO API Authentication via URL Key diff --git a/notes/org-skill-provider-ollama.org b/notes/org-skill-provider-ollama.org index a8d7f10..a377494 100644 --- a/notes/org-skill-provider-ollama.org +++ b/notes/org-skill-provider-ollama.org @@ -4,7 +4,7 @@ #+FILETAGS: :llm:provider:ollama:local:psf: * Overview -The **Ollama Provider Agent** enables the use of local, privacy-preserving LLM models. It integrates with a local Ollama instance to ensure system functionality and sovereignty without external internet connectivity. +The *Ollama Provider Agent* enables the use of local, privacy-preserving LLM models. It integrates with a local Ollama instance to ensure system functionality and sovereignty without external internet connectivity. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,9 +15,9 @@ The **Ollama Provider Agent** enables the use of local, privacy-preserving LLM m Define the interface for communication with a local Ollama daemon. ** 2. User Needs -- **Sovereignty:** Fallback backend independent of cloud providers. -- **Performance:** Efficient local network interaction. -- **Simplicity:** Deterministic, non-streaming text generation. +- *Sovereignty:* Fallback backend independent of cloud providers. +- *Performance:* Efficient local network interaction. +- *Simplicity:* Deterministic, non-streaming text generation. ** 3. Success Criteria *** TODO Local API Connectivity diff --git a/notes/org-skill-provider-openai.org b/notes/org-skill-provider-openai.org index 34250c1..bd4aa54 100644 --- a/notes/org-skill-provider-openai.org +++ b/notes/org-skill-provider-openai.org @@ -4,7 +4,7 @@ #+FILETAGS: :llm:provider:openai:gpt:psf: * Overview -The **OpenAI Provider Agent** integrates OpenAI's GPT models as a pluggable System 1 (neural) backend. It provides industry-standard processing capabilities for reasoning and content generation. +The *OpenAI Provider Agent* integrates OpenAI's GPT models as a pluggable System 1 (neural) backend. It provides industry-standard processing capabilities for reasoning and content generation. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **OpenAI Provider Agent** integrates OpenAI's GPT models as a pluggable Syst Define the interface for reliable communication with the OpenAI Chat Completions API. ** 2. User Needs -- **Compatibility:** Full implementation of the Chat Completions protocol. -- **Reliability:** Secure management of `$OPENAI_API_KEY`. -- **Optimized Inference:** Configurable temperature and model selection (GPT-4o, etc.). -- **Resilience:** Graceful handling of timeouts and errors. +- *Compatibility:* Full implementation of the Chat Completions protocol. +- *Reliability:* Secure management of `$OPENAI_API_KEY`. +- *Optimized Inference:* Configurable temperature and model selection (GPT-4o, etc.). +- *Resilience:* Graceful handling of timeouts and errors. ** 3. Success Criteria *** TODO API Authentication via Bearer Token diff --git a/notes/org-skill-provider-openrouter.org b/notes/org-skill-provider-openrouter.org index bdcdc3a..4464a98 100644 --- a/notes/org-skill-provider-openrouter.org +++ b/notes/org-skill-provider-openrouter.org @@ -4,7 +4,7 @@ #+FILETAGS: :llm:provider:openrouter:unified:psf: * Overview -The **OpenRouter Provider Agent** acts as a unified gateway to hundreds of LLMs. It provides flexibility by dynamically switching between models based on intelligence tiers while maintaining architectural alignment. +The *OpenRouter Provider Agent* acts as a unified gateway to hundreds of LLMs. It provides flexibility by dynamically switching between models based on intelligence tiers while maintaining architectural alignment. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **OpenRouter Provider Agent** acts as a unified gateway to hundreds of LLMs. Define the interface for unified communication with the OpenRouter API. ** 2. User Needs -- **Abstraction:** OpenAI-compatible interface for all OpenRouter models. -- **Dynamic Routing:** Support for intelligence tiers (:POWERFUL, :FAST, :FREE). -- **Resilience:** Leverage auto-routing fallbacks. -- **Transparency:** Proper identification via Referer and Title headers. +- *Abstraction:* OpenAI-compatible interface for all OpenRouter models. +- *Dynamic Routing:* Support for intelligence tiers (:POWERFUL, :FAST, :FREE). +- *Resilience:* Leverage auto-routing fallbacks. +- *Transparency:* Proper identification via Referer and Title headers. ** 3. Success Criteria *** TODO Tiered Model Resolution diff --git a/notes/org-skill-router.org b/notes/org-skill-router.org index cd86338..f560ae8 100644 --- a/notes/org-skill-router.org +++ b/notes/org-skill-router.org @@ -4,7 +4,7 @@ #+FILETAGS: :router:meta-cognitive:delegation:psf: * Overview -The **Router Agent** is the system's "Pre-Frontal Cortex." It classifies unstructured user input, decomposes complex requests into atomic intents, and orchestrates delegation to specialized sub-agents. +The *Router Agent* is the system's "Pre-Frontal Cortex." It classifies unstructured user input, decomposes complex requests into atomic intents, and orchestrates delegation to specialized sub-agents. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **Router Agent** is the system's "Pre-Frontal Cortex." It classifies unstruc Define the interfaces for intent classification and sub-agent delegation. ** 2. User Needs -- **Perception:** Monitor for explicit commands and implicit `@agent` requests. -- **Decomposition:** Break natural language into sequential atomic operations. -- **Efficiency:** Utilize low-latency models for rapid routing. -- **Dynamic Identity:** Adapt triggers based on the active agent name. +- *Perception:* Monitor for explicit commands and implicit `@agent` requests. +- *Decomposition:* Break natural language into sequential atomic operations. +- *Efficiency:* Utilize low-latency models for rapid routing. +- *Dynamic Identity:* Adapt triggers based on the active agent name. ** 3. Success Criteria *** TODO @Agent Tag Detection diff --git a/notes/org-skill-safety-harness.org b/notes/org-skill-safety-harness.org index b2a85b3..2e7c9f9 100644 --- a/notes/org-skill-safety-harness.org +++ b/notes/org-skill-safety-harness.org @@ -4,7 +4,7 @@ #+FILETAGS: :security:sandbox:ast:psf: * Overview -The **Global Safety Harness** is the primary "Safety Gate" for the Neurosymbolic Lisp Machine. It provides a recursive AST validator that subjects all Elisp proposals from System 1 to a strict "Deny-by-Default" sandbox, preventing arbitrary code execution while allowing high-fidelity system manipulation. +The *Global Safety Harness* is the primary "Safety Gate" for the Neurosymbolic Lisp Machine. It provides a recursive AST validator that subjects all Elisp proposals from System 1 to a strict "Deny-by-Default" sandbox, preventing arbitrary code execution while allowing high-fidelity system manipulation. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **Global Safety Harness** is the primary "Safety Gate" for the Neurosymbolic Define a high-integrity, recursive security sandbox for Elisp execution. ** 2. User Needs -- **Recursive Validation:** Every nested function call and variable access MUST be checked. -- **Deny-by-Default:** Only explicitly whitelisted functions and variables are permitted. -- **Eval Protection:** Block all forms of `eval`, `load`, or dynamic execution. -- **Symbolic Preemption:** This skill acts as a mandatory global System 2 check. +- *Recursive Validation:* Every nested function call and variable access MUST be checked. +- *Deny-by-Default:* Only explicitly whitelisted functions and variables are permitted. +- *Eval Protection:* Block all forms of `eval`, `load`, or dynamic execution. +- *Symbolic Preemption:* This skill acts as a mandatory global System 2 check. ** 3. Success Criteria *** TODO Implement recursive AST walker in Lisp diff --git a/notes/org-skill-scientist.org b/notes/org-skill-scientist.org index 9b7483c..a964459 100644 --- a/notes/org-skill-scientist.org +++ b/notes/org-skill-scientist.org @@ -5,7 +5,7 @@ #+DEPENDS_ON: skill-tdd-runner skill-scribe-rca * Overview -The **Scientist Agent** provides a formal, hypothesis-driven approach to debugging. Instead of "trial and error," it formulates symbolic theories about why a failure occurred, designs experiments (test cases), and updates the system's **Institutional Memory** upon discovery. +The *Scientist Agent* provides a formal, hypothesis-driven approach to debugging. Instead of "trial and error," it formulates symbolic theories about why a failure occurred, designs experiments (test cases), and updates the system's *Institutional Memory* upon discovery. * Phase A: Demand (PRD) :PROPERTIES: @@ -16,10 +16,10 @@ The **Scientist Agent** provides a formal, hypothesis-driven approach to debuggi Eliminate speculative debugging through rigorous scientific methodology. ** 2. User Needs -- **Hypothesis Formulation:** Neural generation of potential failure causes. -- **Experimental Design:** Autonomous creation of minimal failing test cases. -- **Theory Verification:** Execution of tests via the TDD Runner. -- **Knowledge Update:** Permanent update to `RCA.org` to prevent regression. +- *Hypothesis Formulation:* Neural generation of potential failure causes. +- *Experimental Design:* Autonomous creation of minimal failing test cases. +- *Theory Verification:* Execution of tests via the TDD Runner. +- *Knowledge Update:* Permanent update to `RCA.org` to prevent regression. * Phase D: Build (Implementation) diff --git a/notes/org-skill-scribe-rca.org b/notes/org-skill-scribe-rca.org index 05c3162..87ace11 100644 --- a/notes/org-skill-scribe-rca.org +++ b/notes/org-skill-scribe-rca.org @@ -5,7 +5,7 @@ #+DEPENDS_ON: skill-atomic-notes * Overview -The **Scribe-RCA** agent is responsible for **Phase F: Memory**. It captures "Permanent Learnings" after significant failures or task completions, ensuring the system's **Institutional Memory** grows with every cycle. +The *Scribe-RCA* agent is responsible for *Phase F: Memory*. It captures "Permanent Learnings" after significant failures or task completions, ensuring the system's *Institutional Memory* grows with every cycle. * Phase A: Demand (PRD) :PROPERTIES: @@ -16,10 +16,10 @@ The **Scribe-RCA** agent is responsible for **Phase F: Memory**. It captures "Pe Automate the extraction of root causes and architectural learnings into the Memex. ** 2. User Needs -- **Root Cause Analysis:** Automatically draft an RCA note after a `skip-event` recovery. -- **Permanent Learning:** Update `SOUL.org` or a dedicated `RCA.org` with new invariants. -- **Version Control Integration:** Commit new RCA notes to Gitea autonomously. -- **Traceability:** Link every learning back to the original failure stimulus. +- *Root Cause Analysis:* Automatically draft an RCA note after a `skip-event` recovery. +- *Permanent Learning:* Update `SOUL.org` or a dedicated `RCA.org` with new invariants. +- *Version Control Integration:* Commit new RCA notes to Gitea autonomously. +- *Traceability:* Link every learning back to the original failure stimulus. * Phase D: Build (Implementation) diff --git a/notes/org-skill-scribe.org b/notes/org-skill-scribe.org index 018e66c..e9ba82c 100644 --- a/notes/org-skill-scribe.org +++ b/notes/org-skill-scribe.org @@ -4,7 +4,7 @@ #+FILETAGS: :scribe:distillation:psf:audit: * Overview -The **Scribe Agent** is the primary custodian of the Institutional Memory. It distills ephemeral daily thoughts into atomic notes and audits foundry projects for compliance with PSF standards. +The *Scribe Agent* is the primary custodian of the Institutional Memory. It distills ephemeral daily thoughts into atomic notes and audits foundry projects for compliance with PSF standards. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **Scribe Agent** is the primary custodian of the Institutional Memory. It di Define automated distillation and auditing behaviors for the PSF. ** 2. User Needs -- **Knowledge Distillation:** Extract evergreen concepts from raw dailies. -- **Incremental Processing:** Efficient Git-based delta tracking. -- **PSF Mandate Audit:** High-integrity check for PRD/PROTOCOL artifacts. -- **Autonomous Execution:** Cron-compatible, environment-driven logic. +- *Knowledge Distillation:* Extract evergreen concepts from raw dailies. +- *Incremental Processing:* Efficient Git-based delta tracking. +- *PSF Mandate Audit:* High-integrity check for PRD/PROTOCOL artifacts. +- *Autonomous Execution:* Cron-compatible, environment-driven logic. ** 3. Success Criteria *** TODO Distillation Accuracy diff --git a/notes/org-skill-self-fix.org b/notes/org-skill-self-fix.org index 60e9324..8a1af5f 100644 --- a/notes/org-skill-self-fix.org +++ b/notes/org-skill-self-fix.org @@ -5,7 +5,7 @@ #+DEPENDS_ON: skill-scientist skill-shell-actuator * Overview -The **Self-Fix Agent** is the system's "Repair Mechanism." It takes the failure hypotheses from the **Scientist Agent**, applies surgical code modifications in a sandboxed environment, and merges the fix only after rigorous verification by the **TDD Runner**. +The *Self-Fix Agent* is the system's "Repair Mechanism." It takes the failure hypotheses from the *Scientist Agent*, applies surgical code modifications in a sandboxed environment, and merges the fix only after rigorous verification by the *TDD Runner*. * Phase A: Demand (PRD) :PROPERTIES: @@ -16,10 +16,10 @@ The **Self-Fix Agent** is the system's "Repair Mechanism." It takes the failure Enable autonomous, verified code correction without human intervention. ** 2. User Needs -- **Surgical Modification:** Apply targeted changes to specific Lisp functions or Org headlines. -- **Sandboxed Verification:** Test every fix in a controlled environment before merging. -- **Rollback Capability:** Use the **Interactive Steering** snapshots to revert if a fix fails. -- **Audit Logging:** Every fix must be documented in `RCA.org`. +- *Surgical Modification:* Apply targeted changes to specific Lisp functions or Org headlines. +- *Sandboxed Verification:* Test every fix in a controlled environment before merging. +- *Rollback Capability:* Use the *Interactive Steering* snapshots to revert if a fix fails. +- *Audit Logging:* Every fix must be documented in `RCA.org`. * Phase D: Build (Implementation) diff --git a/notes/org-skill-shell-actuator.org b/notes/org-skill-shell-actuator.org index e116c10..e281a11 100644 --- a/notes/org-skill-shell-actuator.org +++ b/notes/org-skill-shell-actuator.org @@ -4,7 +4,7 @@ #+FILETAGS: :shell:actuator:system:psf: * Overview -The **Shell Actuator Agent** provides the bridge to the host operating system. It enables secure command execution while maintaining a strict security posture through whitelisting and diagnostic feedback loops. +The *Shell Actuator Agent* provides the bridge to the host operating system. It enables secure command execution while maintaining a strict security posture through whitelisting and diagnostic feedback loops. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **Shell Actuator Agent** provides the bridge to the host operating system. I Define a secure, diagnostic-rich interface for host OS interaction. ** 2. User Needs -- **Secure Actuation:** Strict whitelist of permitted commands. -- **Diagnostic Feedback:** Capture STDOUT, STDERR, and exit codes. -- **Loop Closure:** Automatic neural analysis of command results. -- **Resilience:** Graceful handling of blocked or failed commands. +- *Secure Actuation:* Strict whitelist of permitted commands. +- *Diagnostic Feedback:* Capture STDOUT, STDERR, and exit codes. +- *Loop Closure:* Automatic neural analysis of command results. +- *Resilience:* Graceful handling of blocked or failed commands. ** 3. Success Criteria *** TODO Whitelist Enforcement diff --git a/notes/org-skill-sub-agent-manager.org b/notes/org-skill-sub-agent-manager.org index 814d71f..0dd37c8 100644 --- a/notes/org-skill-sub-agent-manager.org +++ b/notes/org-skill-sub-agent-manager.org @@ -4,7 +4,7 @@ #+FILETAGS: :concurrency:parallelism:threads:psf: * Overview -The **Sub-Agent Manager** enables the Neurosymbolic Lisp Machine to handle multiple concurrent thoughts. It allows the primary kernel to "spawn" lightweight, isolated Lisp threads (sub-agents) to perform long-running or background tasks (research, massive refactors, etc.) without blocking the main event bus. +The *Sub-Agent Manager* enables the Neurosymbolic Lisp Machine to handle multiple concurrent thoughts. It allows the primary kernel to "spawn" lightweight, isolated Lisp threads (sub-agents) to perform long-running or background tasks (research, massive refactors, etc.) without blocking the main event bus. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **Sub-Agent Manager** enables the Neurosymbolic Lisp Machine to handle multi Define the interfaces for parallel cognitive execution and thread lifecycle management. ** 2. User Needs -- **Non-Blocking Execution:** Spawn background threads for long-running tasks. -- **Context Isolation:** Sub-agents must have their own execution context to prevent parent context poisoning. -- **Communication Loop:** Sub-agents must inject a "Return Stimulus" upon completion. -- **Observability:** Ability to list and terminate active sub-agents. +- *Non-Blocking Execution:* Spawn background threads for long-running tasks. +- *Context Isolation:* Sub-agents must have their own execution context to prevent parent context poisoning. +- *Communication Loop:* Sub-agents must inject a "Return Stimulus" upon completion. +- *Observability:* Ability to list and terminate active sub-agents. ** 3. Success Criteria *** TODO Successful spawning of a non-blocking background thread diff --git a/notes/org-skill-task-integrity.org b/notes/org-skill-task-integrity.org index 9aa6f28..827e8d3 100644 --- a/notes/org-skill-task-integrity.org +++ b/notes/org-skill-task-integrity.org @@ -4,7 +4,7 @@ #+FILETAGS: :gtd:integrity:safety:psf: * Overview -The **Task Integrity Agent** is the "Guardian" of the GTD system. It ensures that all task transitions adhere to semantic rules, preventing logical inconsistencies and maintaining the structural health of the task hierarchy. +The *Task Integrity Agent* is the "Guardian" of the GTD system. It ensures that all task transitions adhere to semantic rules, preventing logical inconsistencies and maintaining the structural health of the task hierarchy. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **Task Integrity Agent** is the "Guardian" of the GTD system. It ensures tha Define automated behaviors for GTD state consistency and dependency verification. ** 2. User Needs -- **Semantic Enforcement:** Valid state transitions (Active vs. Resolved). -- **Dependency Awareness:** Block closing parents with active children. -- **Proactive Assistance:** Suggesting next logical actions based on momentum. -- **Fidelity:** Preservation of metadata during state transitions. +- *Semantic Enforcement:* Valid state transitions (Active vs. Resolved). +- *Dependency Awareness:* Block closing parents with active children. +- *Proactive Assistance:* Suggesting next logical actions based on momentum. +- *Fidelity:* Preservation of metadata during state transitions. ** 3. Success Criteria *** TODO Semantic Category Mapping diff --git a/notes/org-skill-tdd-runner.org b/notes/org-skill-tdd-runner.org index efdc885..7b56e75 100644 --- a/notes/org-skill-tdd-runner.org +++ b/notes/org-skill-tdd-runner.org @@ -4,7 +4,7 @@ #+FILETAGS: :tdd:ci:verification:safety:psf: * Overview -The **Automated TDD Runner** provides the system with Continuous Integration (CI) capabilities. It monitors active project directories and autonomously executes test suites whenever a file change is detected, ensuring that the kernel remains in a "Green" (verified) state. +The *Automated TDD Runner* provides the system with Continuous Integration (CI) capabilities. It monitors active project directories and autonomously executes test suites whenever a file change is detected, ensuring that the kernel remains in a "Green" (verified) state. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **Automated TDD Runner** provides the system with Continuous Integration (CI Define automated behaviors for background test execution and regression alerting. ** 2. User Needs -- **Background Execution:** Run `FiveAM` (Lisp) or `pytest` (Python) suites without user intervention. -- **Trigger on Perception:** Execute tests whenever a `:buffer-update` or `:file-saved` event occurs. -- **Immediate Alerting:** Inject a high-priority `:EVENT` into the kernel if a test fails. -- **System Locking:** Option to prevent further actions if the project is in a "RED" (failing) state. +- *Background Execution:* Run `FiveAM` (Lisp) or `pytest` (Python) suites without user intervention. +- *Trigger on Perception:* Execute tests whenever a `:buffer-update` or `:file-saved` event occurs. +- *Immediate Alerting:* Inject a high-priority `:EVENT` into the kernel if a test fails. +- *System Locking:* Option to prevent further actions if the project is in a "RED" (failing) state. ** 3. Success Criteria *** TODO Automatic test suite discovery logic verification diff --git a/notes/org-skill-tech-analyst.org b/notes/org-skill-tech-analyst.org index 72136af..36e9132 100644 --- a/notes/org-skill-tech-analyst.org +++ b/notes/org-skill-tech-analyst.org @@ -4,7 +4,7 @@ #+FILETAGS: :analyst:testing:tdd:psf: * Overview -The **Technical Analyst Agent** defines the **Success Criteria** for a project. It generates a failing test suite immediately after the architecture is signed, enforcing a strict TDD mandate within the PSF Consensus Loop. +The *Technical Analyst Agent* defines the *Success Criteria* for a project. It generates a failing test suite immediately after the architecture is signed, enforcing a strict TDD mandate within the PSF Consensus Loop. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **Technical Analyst Agent** defines the **Success Criteria** for a project. Define automated testing behaviors for the PSF Consensus Loop. ** 2. User Needs -- **Protocol Perception:** Monitor for `SIGNED` Protocols. -- **TDD Inception:** Translate interfaces into executable test cases. -- **Edge Case Coverage:** Mandatory testing of failure modes and malformed input. -- **Structural Enforcement:** Ensure the `tests/` directory is correctly initialized. +- *Protocol Perception:* Monitor for `SIGNED` Protocols. +- *TDD Inception:* Translate interfaces into executable test cases. +- *Edge Case Coverage:* Mandatory testing of failure modes and malformed input. +- *Structural Enforcement:* Ensure the `tests/` directory is correctly initialized. ** 3. Success Criteria *** TODO Trigger Accuracy diff --git a/notes/org-skill-web-interface.org b/notes/org-skill-web-interface.org index 3ef82ad..bbb1357 100644 --- a/notes/org-skill-web-interface.org +++ b/notes/org-skill-web-interface.org @@ -4,7 +4,7 @@ #+FILETAGS: :web:dashboard:telemetry:psf: * Overview -The **Web Dashboard Agent** provides a lightweight telemetry window into the Neurosymbolic Kernel. It exposes the active skill graph and system logs via a local HTML dashboard. +The *Web Dashboard Agent* provides a lightweight telemetry window into the Neurosymbolic Kernel. It exposes the active skill graph and system logs via a local HTML dashboard. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **Web Dashboard Agent** provides a lightweight telemetry window into the Neu Define the interfaces for system observability and telemetry serving. ** 2. User Needs -- **Transparency:** Overview of skill performance (executions, time, failures). -- **Accessibility:** Served over a local HTTP port. -- **Observability:** Tail of system logs for debugging. -- **Low Overhead:** Background execution. +- *Transparency:* Overview of skill performance (executions, time, failures). +- *Accessibility:* Served over a local HTTP port. +- *Observability:* Tail of system logs for debugging. +- *Low Overhead:* Background execution. ** 3. Success Criteria *** TODO Server Bootstrap Verification diff --git a/notes/org-skill-web-research.org b/notes/org-skill-web-research.org index ae292cd..37ceb11 100644 --- a/notes/org-skill-web-research.org +++ b/notes/org-skill-web-research.org @@ -4,7 +4,7 @@ #+FILETAGS: :web:research:internet:psf: * Overview -The **Web Research Agent** provides the bridge to the internet. It fetches and synthesizes information from the web using pluggable engines like Lynx and Curl, enabling real-time research and fact verification. +The *Web Research Agent* provides the bridge to the internet. It fetches and synthesizes information from the web using pluggable engines like Lynx and Curl, enabling real-time research and fact verification. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **Web Research Agent** provides the bridge to the internet. It fetches and s Define the interfaces for internet information retrieval and synthesis. ** 2. User Needs -- **Connectivity:** Pluggable engines (Lynx, Curl) for fetching URLs. -- **Synthesis:** Neural transformation of raw content into factual summaries. -- **Efficiency:** Default to text-only engines to minimize overhead. -- **Search Integration:** Automatic DuckDuckGo routing for general queries. +- *Connectivity:* Pluggable engines (Lynx, Curl) for fetching URLs. +- *Synthesis:* Neural transformation of raw content into factual summaries. +- *Efficiency:* Default to text-only engines to minimize overhead. +- *Search Integration:* Automatic DuckDuckGo routing for general queries. ** 3. Success Criteria *** TODO Engine Fetching Verification (Lynx/Curl) diff --git a/notes/org-skill-workspace-manager.org b/notes/org-skill-workspace-manager.org index c2047f4..4c54f77 100644 --- a/notes/org-skill-workspace-manager.org +++ b/notes/org-skill-workspace-manager.org @@ -4,7 +4,7 @@ #+FILETAGS: :workspace:para:maintenance:psf: * Overview -The **Workspace Manager Agent** is responsible for the ongoing maintenance and organization of the Memex workspace. It automates the "housekeeping" aspects of the PARA/Zettelkasten workflow, focusing on clutter reduction and structural alignment. +The *Workspace Manager Agent* is responsible for the ongoing maintenance and organization of the Memex workspace. It automates the "housekeeping" aspects of the PARA/Zettelkasten workflow, focusing on clutter reduction and structural alignment. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,9 +15,9 @@ The **Workspace Manager Agent** is responsible for the ongoing maintenance and o Define automated housekeeping behaviors for PARA/Zettelkasten maintenance. ** 2. User Needs -- **Clutter Reduction:** Identify and archive `DONE` tasks. -- **Workflow Alignment:** Ensure consistency with PARA directory structure. -- **Proactive Organization:** Trigger on saves and heartbeats. +- *Clutter Reduction:* Identify and archive `DONE` tasks. +- *Workflow Alignment:* Ensure consistency with PARA directory structure. +- *Proactive Organization:* Trigger on saves and heartbeats. ** 3. Success Criteria *** TODO Task Identification diff --git a/notes/personal-server-appliance.org b/notes/personal-server-appliance.org index 26417a4..47eeada 100644 --- a/notes/personal-server-appliance.org +++ b/notes/personal-server-appliance.org @@ -4,7 +4,7 @@ #+FILETAGS: :hardware:server:sovereignty:modular:psf: * Overview -The **Personal Server Appliance** project aims to design and develop a modular, high-integrity computing environment. It features swappable modules for compute, storage, networking, and signal processing, packaged in a sleek 10-inch or standard 19-inch form factor that resembles high-end audio equipment. +The *Personal Server Appliance* project aims to design and develop a modular, high-integrity computing environment. It features swappable modules for compute, storage, networking, and signal processing, packaged in a sleek 10-inch or standard 19-inch form factor that resembles high-end audio equipment. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **Personal Server Appliance** project aims to design and develop a modular, Define the requirements for a modular, user-serviceable, and aesthetically pleasing personal server. ** 2. User Needs -- **Modularity:** Unified backplane for swappable compute, storage, and power modules. -- **Sovereignty:** Full control over hardware and the software stack (running `org-agent`). -- **Aesthetics:** Sleek "Hi-Fi" industrial design. -- **Multimodality:** Integration of SDR, AV, and specialized processors. +- *Modularity:* Unified backplane for swappable compute, storage, and power modules. +- *Sovereignty:* Full control over hardware and the software stack (running `org-agent`). +- *Aesthetics:* Sleek "Hi-Fi" industrial design. +- *Multimodality:* Integration of SDR, AV, and specialized processors. ** 3. Success Criteria *** TODO Inter-module communication standard specification diff --git a/notes/personal-software-foundry.org b/notes/personal-software-foundry.org index ba19077..1ebb2f3 100644 --- a/notes/personal-software-foundry.org +++ b/notes/personal-software-foundry.org @@ -5,7 +5,7 @@ #+STARTUP: content * Overview -The **Personal Software Foundry (PSF)** is a highly integrated, neurosymbolic "virtual software house" embedded within the Memex. It is the overarching system used to design, implement, and maintain all software projects. The PSF ensures that every line of code is provably correct, secure, and part of a self-improving cognitive loop. +The *Personal Software Foundry (PSF)* is a highly integrated, neurosymbolic "virtual software house" embedded within the Memex. It is the overarching system used to design, implement, and maintain all software projects. The PSF ensures that every line of code is provably correct, secure, and part of a self-improving cognitive loop. It operates as a proactive agentic layer that handles the entire lifecycle of software creation—from proactive need-discovery to autonomous maintenance—adhering to the technical rigor of a native Lisp Machine. @@ -20,8 +20,8 @@ Every document, plan, PRD, and skill in the system MUST be written in Org-mode ( ** 3. Literate Programming (The Knuth-Sovereign Principle) The PSF treats code not as a series of instructions for a computer, but as a "work of literature" for humans that happens to be executable. -- **Implementation:** All `org-agent` skills and system logic MUST be implemented as Literate Org files using `#+begin_src` blocks. -- **Rationale:** By weaving documentation and code together, we ensure that the "Why" (Architectural Intent) is never separated from the "How" (Implementation). This is the key to the PSF's **Institutional Memory**. +- *Implementation:* All `org-agent` skills and system logic MUST be implemented as Literate Org files using `#+begin_src` blocks. +- *Rationale:* By weaving documentation and code together, we ensure that the "Why" (Architectural Intent) is never separated from the "How" (Implementation). This is the key to the PSF's *Institutional Memory*. ** 4. Hardware Compartmentalization The runtime environment is an enclosure (Docker, LXC, VM, or Bare Metal). The PSF kernel remains agnostic to its enclosure. @@ -30,7 +30,7 @@ The runtime environment is an enclosure (Docker, LXC, VM, or Bare Metal). The PS The Foundry serves as a mentorship environment. Agents must explain the "Why" and distill knowledge to increase user technical mastery. The user (Sovereign Executive) retains absolute right to deep-dive into any technical layer. * Architectural Foundation (CLOSOS Principles) -The PSF is built on the **Common Lisp Object-Store Operating System (CLOSOS)** specification: +The PSF is built on the *Common Lisp Object-Store Operating System (CLOSOS)* specification: - [[file:closos_attributed_object_store.org][Object-Store First]]: Data is treated as Attributed Lisp Objects (via `org-element` AST), not flat files. - [[file:closos_single_address_space.org][Single Address Space]]: The CL Daemon and Emacs share a conceptual address space via OACP (Remote Object Proxy). @@ -43,30 +43,30 @@ Projects pass through sequential "Safety Gates" managed by specialized departmen | Phase | Department | Responsibility | Key Instrument | | :--- | :--- | :--- | :--- | -| **A: Demand** | **Product** | User Interview & Needs | `PRD.org` | -| **B: Blueprint** | **Design** | Structural Integrity & API | [[file:../system/skills/org-skill-architect.org][Architect Skill]] | -| **C: Success** | **Quality** | TDD Inception & Security Audit | [[file:../system/skills/org-skill-tech-analyst.org][Analyst Skill]] | -| **D: Build** | **Engineering** | Minimal Implementation | `src/`, [[file:skill-project-foundry.org][Foundry Skill]] | -| **E: Chaos** | **Chaos** | Dynamic Testing & Chaos Eng. | [[file:org-skill-chaos.org][Chaos Skill]] | -| F: Memory | **Optimization** | Institutional Memory & RCA | [[file:institutional_memory.org][institutional_memory.org]], [[file:../system/skills/org-skill-scribe-rca.org][Scribe-RCA Skill]] | +| *A: Demand* | *Product* | User Interview & Needs | `PRD.org` | +| *B: Blueprint* | *Design* | Structural Integrity & API | [[file:../system/skills/org-skill-architect.org][Architect Skill]] | +| *C: Success* | *Quality* | TDD Inception & Security Audit | [[file:../system/skills/org-skill-tech-analyst.org][Analyst Skill]] | +| *D: Build* | *Engineering* | Minimal Implementation | `src/`, [[file:skill-project-foundry.org][Foundry Skill]] | +| *E: Chaos* | *Chaos* | Dynamic Testing & Chaos Eng. | [[file:org-skill-chaos.org][Chaos Skill]] | +| F: Memory | *Optimization* | Institutional Memory & RCA | [[file:institutional_memory.org][institutional_memory.org]], [[file:../system/skills/org-skill-scribe-rca.org][Scribe-RCA Skill]] | ** Success Matrix: "The Level 3 Standard" -A project is not complete until it achieves **Evolutionary Completion**: -1. **Functional:** Code merged and passing all audits (Chaos Gauntlet). -2. **Institutional:** Session distilled into atomic notes; code groomed for zero bloat. -3. **Evolutionary:** Automated health checks and recurring maintenance tasks established in `gtd.org` as standard task sequences. +A project is not complete until it achieves *Evolutionary Completion*: +1. *Functional:* Code merged and passing all audits (Chaos Gauntlet). +2. *Institutional:* Session distilled into atomic notes; code groomed for zero bloat. +3. *Evolutionary:* Automated health checks and recurring maintenance tasks established in `gtd.org` as standard task sequences. * Operational Standards -- **Project Root:** All projects live in `memex/5_projects/`. -- **Common Structure:** +- *Project Root:* All projects live in `memex/5_projects/`. +- *Common Structure:* - `README.org` (Vision) - `PRD.org` (Requirements) - `PROTOCOL.org` (Interfaces) - `src/` (Implementation) - `tests/` (Verification) - `docs/` (Architecture/Chaos/RCA) -- **Self-Improvement (RCA):** Every bug triggers a **Root Cause Analysis** note to update "Permanent Learnings" in `SOUL.org`. +- *Self-Improvement (RCA):* Every bug triggers a *Root Cause Analysis* note to update "Permanent Learnings" in `SOUL.org`. * See Also - [[file:../projects/org-agent/README.org][org-agent (The Neurosymbolic Kernel)]] diff --git a/notes/proof-of-work-vs-stake.org b/notes/proof-of-work-vs-stake.org index 911d686..e2f7c35 100644 --- a/notes/proof-of-work-vs-stake.org +++ b/notes/proof-of-work-vs-stake.org @@ -5,8 +5,8 @@ ** 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. +- *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 diff --git a/notes/revenue-sustainability.org b/notes/revenue-sustainability.org index adcc070..2b8c943 100644 --- a/notes/revenue-sustainability.org +++ b/notes/revenue-sustainability.org @@ -4,7 +4,7 @@ #+FILETAGS: :business:revenue:strategy:operations:psf: * Overview -The **Revenue Sustainability** project defines the strategy and operational setup for financial independence and sustainable business growth. It focuses on establishing the necessary infrastructure for payment processing, professional presence, and contractual integrity. +The *Revenue Sustainability* project defines the strategy and operational setup for financial independence and sustainable business growth. It focuses on establishing the necessary infrastructure for payment processing, professional presence, and contractual integrity. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **Revenue Sustainability** project defines the strategy and operational setu Define the requirements for a robust, sustainable revenue generation and management system. ** 2. User Needs -- **Payment Processing:** Integration with Stripe for seamless customer transactions. -- **Professional Presence:** Portfolio page, domain, and branded email. -- **Operational Integrity:** Time tracking, invoicing (Wave/Bonsai), and legal contract templates. -- **Social Proof:** System for testimonial collection and reputation management. +- *Payment Processing:* Integration with Stripe for seamless customer transactions. +- *Professional Presence:* Portfolio page, domain, and branded email. +- *Operational Integrity:* Time tracking, invoicing (Wave/Bonsai), and legal contract templates. +- *Social Proof:* System for testimonial collection and reputation management. ** 3. Success Criteria *** TODO Stripe account verification and test transaction diff --git a/notes/sdr-suite-lisp.org b/notes/sdr-suite-lisp.org index a3b35ad..8eb5508 100644 --- a/notes/sdr-suite-lisp.org +++ b/notes/sdr-suite-lisp.org @@ -4,7 +4,7 @@ #+FILETAGS: :radio:sdr:lisp:signal-processing:psf: * Overview -The **SDR Suite Lisp** project aims to develop a comprehensive Software Defined Radio environment using Common Lisp. It leverages the high-performance, threaded nature of SBCL to provide real-time signal processing across various domains, from satellite communication to passive radar and computer networking. +The *SDR Suite Lisp* project aims to develop a comprehensive Software Defined Radio environment using Common Lisp. It leverages the high-performance, threaded nature of SBCL to provide real-time signal processing across various domains, from satellite communication to passive radar and computer networking. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **SDR Suite Lisp** project aims to develop a comprehensive Software Defined Define the functional and technical requirements for a Lisp-native SDR architecture. ** 2. User Needs -- **Real-time Signal Processing:** High-performance DSP loops in Common Lisp. -- **Multimodal Support:** Unified framework for EME, ALE, SSTV, and standard Rx (FM/AM). -- **Extensibility:** Modular "plug-and-play" architecture for new decoders and protocols. -- **Hardware Agnostic:** Support for RTL-SDR, HackRF, and high-end FPGA-based SDRs. +- *Real-time Signal Processing:* High-performance DSP loops in Common Lisp. +- *Multimodal Support:* Unified framework for EME, ALE, SSTV, and standard Rx (FM/AM). +- *Extensibility:* Modular "plug-and-play" architecture for new decoders and protocols. +- *Hardware Agnostic:* Support for RTL-SDR, HackRF, and high-end FPGA-based SDRs. ** 3. Success Criteria *** TODO Core DSP Loop Benchmarking (SBCL) diff --git a/notes/token-optimization.org b/notes/token-optimization.org index 6558dfd..eafda3e 100644 --- a/notes/token-optimization.org +++ b/notes/token-optimization.org @@ -4,7 +4,7 @@ #+FILETAGS: :strategy:token:optimization:cost:psf: * Overview -The **Token Optimization** project defines the strategy and implementation for cost-effective LLM usage. It implements a multi-tier, multi-provider approach to minimize inference costs while maximizing reasoning capability through smart routing and context compression. +The *Token Optimization* project defines the strategy and implementation for cost-effective LLM usage. It implements a multi-tier, multi-provider approach to minimize inference costs while maximizing reasoning capability through smart routing and context compression. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **Token Optimization** project defines the strategy and implementation for c Minimize LLM operational expenses while maintaining high-fidelity agentic performance. ** 2. User Needs -- **Multi-Tier Strategy:** Resolve tasks using the cheapest model that meets the required intelligence threshold. -- **Failover Resilience:** Automated fallback chain (Gemini -> OpenRouter -> GPT-4o). -- **Context Efficiency:** Implement pruning and RAG to avoid token bloat. -- **Usage Transparency:** Real-time tracking and budget alerts. +- *Multi-Tier Strategy:* Resolve tasks using the cheapest model that meets the required intelligence threshold. +- *Failover Resilience:* Automated fallback chain (Gemini -> OpenRouter -> GPT-4o). +- *Context Efficiency:* Implement pruning and RAG to avoid token bloat. +- *Usage Transparency:* Real-time tracking and budget alerts. ** 3. Success Criteria *** TODO 80% of queries handled by Tier 1 (Free/Fast) models diff --git a/notes/zotero-org-import-tool.org b/notes/zotero-org-import-tool.org index 2d3c5ea..1db6af4 100644 --- a/notes/zotero-org-import-tool.org +++ b/notes/zotero-org-import-tool.org @@ -4,7 +4,7 @@ #+FILETAGS: :research:zettelkasten:zotero:import:psf: * Overview -The **Zotero Org Import Tool** is a "makeshift" utility designed to bridge the gap between academic research management (Zotero) and the personal knowledge base (Org-mode). It focuses on two critical priorities: accurate linking to academic PDFs and creating persistent web snapshots for bookmarks. +The *Zotero Org Import Tool* is a "makeshift" utility designed to bridge the gap between academic research management (Zotero) and the personal knowledge base (Org-mode). It focuses on two critical priorities: accurate linking to academic PDFs and creating persistent web snapshots for bookmarks. * Phase A: Demand (PRD) :PROPERTIES: @@ -15,10 +15,10 @@ The **Zotero Org Import Tool** is a "makeshift" utility designed to bridge the g Define the requirements for a high-fidelity import of research artifacts from Zotero to Org-mode. ** 2. User Needs -- **BibTeX/JSON Parsing:** Ingest Zotero libraries via standard export formats. -- **Attachment Linking:** Maintain durable links to local PDF attachments. -- **Web Persistence:** Generate local or service-based snapshots of imported URLs. -- **Org-Native Schema:** Map Zotero metadata fields to appropriate Org properties. +- *BibTeX/JSON Parsing:* Ingest Zotero libraries via standard export formats. +- *Attachment Linking:* Maintain durable links to local PDF attachments. +- *Web Persistence:* Generate local or service-based snapshots of imported URLs. +- *Org-Native Schema:* Map Zotero metadata fields to appropriate Org properties. ** 3. Success Criteria *** TODO Successful parsing of Zotero JSON export diff --git a/notes/ضريبة-القيمة-المضافة.org b/notes/ضريبة-القيمة-المضافة.org index 32f13af..c563363 100644 --- a/notes/ضريبة-القيمة-المضافة.org +++ b/notes/ضريبة-القيمة-المضافة.org @@ -7,7 +7,7 @@ #+title: الموقف المصري: ضريبة القيمة المضافة #+filetags: :الموقف المصري: -**دليل "الموقف المصري" للمواطن وعضو البرلمان عن قانون القيمة المضافة** - +*دليل "الموقف المصري" للمواطن وعضو البرلمان عن قانون القيمة المضافة* - الجزء الأول أولاً إيه هي ضريبة القيمة المضافة اللي الحكومة سلمت قانونها لمجلس النواب؟ تفرق إيه عن ضريبة المبيعات؟ @@ -119,7 +119,7 @@ ده موضوع الجزء التاني من البوست .. استنونا  -**دليل الموقف المصري للمواطن والبرلماني لفهم قانون القيمة المضافة** - الجزء الثاني +*دليل الموقف المصري للمواطن والبرلماني لفهم قانون القيمة المضافة* - الجزء الثاني "العدالة الاجتماعية اساس الضرائب وغيرها من التكاليف المالية العامة" - المادة 26 من الدستور المصري. diff --git a/projects/agora/docs/agora-requirements-01-overview.org b/projects/agora/docs/agora-requirements-01-overview.org index c38b8ff..5cd048b 100644 --- a/projects/agora/docs/agora-requirements-01-overview.org +++ b/projects/agora/docs/agora-requirements-01-overview.org @@ -7,7 +7,7 @@ * 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. +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. @@ -39,14 +39,14 @@ Agora's unique capabilities stem from the synergistic integration of three prima 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]]**. +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. +- *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 @@ -55,23 +55,23 @@ Agora's identity system grants users absolute control over their digital presenc *** 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. +- *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. +- *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. +- *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 @@ -80,24 +80,24 @@ Agora's infrastructure is specifically engineered to underpin user sovereignty, *** 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. +- *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. +- *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. +- *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 @@ -109,14 +109,14 @@ Agora provides a robust framework for secure, private, and censorship-resistant *** 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. +- *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. +- *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 @@ -124,22 +124,22 @@ Agora fundamentally reshapes how content is created, published, and managed, emp *** 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. +- *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. +- *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. +- *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 @@ -147,14 +147,14 @@ Agora enables peer-to-peer economic interaction without intermediaries, fosterin *** 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. +- *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. +- *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 @@ -162,21 +162,21 @@ Agora offers robust primitives for secure, auditable collaboration, empowering t *** 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. +- *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. +- *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. +- *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 @@ -184,15 +184,15 @@ Agora's identity and contract primitives lay the groundwork for a dynamic, adapt *** 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. +- *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. +- *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 @@ -255,24 +255,24 @@ Reduce "empty feed" problem by immediately showing relevant content based on use 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. +- *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. +- *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. +- *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. +- *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 diff --git a/projects/agora/docs/agora-requirements-02-identity.org b/projects/agora/docs/agora-requirements-02-identity.org index 0d9501b..f59a28e 100644 --- a/projects/agora/docs/agora-requirements-02-identity.org +++ b/projects/agora/docs/agora-requirements-02-identity.org @@ -18,16 +18,16 @@ The Master Key, often referred to as "Psyche" (Latin for soul or animating princ - 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)**. +- 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. +- *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. +- *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. @@ -166,13 +166,13 @@ async function recoverShard( *** 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. +- *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. +- *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) @@ -199,8 +199,8 @@ Clients must efficiently discover active personas derived from a Master Seed wit **** 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.). +- *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. @@ -340,7 +340,7 @@ const encryptionKey = x25519.generateKeyPair(personaNode.privateKey); - 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. +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 @@ -348,39 +348,39 @@ Agora distinguishes between the dynamics of recovery for individual "natural per ***** 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. +- *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. +- *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. +- *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 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. +- *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 @@ -412,32 +412,32 @@ Each Persona in Agora is analogous to a legal person, possessing the inherent ri **** 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). +- *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. +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. +- *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. +- *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. +- *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 @@ -457,17 +457,17 @@ Agora treats Artificial Intelligence not as a backend feature, but as a first-cl - *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`. + - *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`) +- *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). @@ -519,16 +519,16 @@ For users who want a username entirely untethered from a specific PDS provider's *** 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. +- *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. +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 @@ -570,19 +570,19 @@ Personas are the functional, active identities through which you engage with the *** 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. +- *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. +- *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." +- *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. @@ -600,10 +600,10 @@ Agora utilizes the principle of *Pre-rotation* to ensure forward security as an 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. +- *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 diff --git a/projects/agora/docs/agora-requirements-03-infrastructure.org b/projects/agora/docs/agora-requirements-03-infrastructure.org index d448f69..673dd4e 100644 --- a/projects/agora/docs/agora-requirements-03-infrastructure.org +++ b/projects/agora/docs/agora-requirements-03-infrastructure.org @@ -61,10 +61,10 @@ PDS Migration is the comprehensive process of transferring a user's entire encry 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. +- *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) @@ -292,10 +292,10 @@ In a truly sovereign digital ecosystem, users should never be constrained to a s 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. +- *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 @@ -439,28 +439,28 @@ interface SyncConfig { **** 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. +- *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. +- *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. +- *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. +- *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 @@ -477,17 +477,17 @@ The Relay Network serves as Agora's intelligent, adaptive message routing layer *** 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. +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. +- *`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. +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. @@ -544,16 +544,16 @@ New clients need to find Relay nodes without hardcoded lists (centralization ris - *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. +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. +- *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 @@ -577,8 +577,8 @@ To ensure sustainability without compromising user data (avoiding "Surveillance **** 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. +- *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 @@ -619,34 +619,34 @@ In a decentralized network, finding historical content or discovering new Person - 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. +- *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. +- *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` +- *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. +- *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. +- *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 @@ -659,15 +659,15 @@ Gateways act as "translators" sitting on the edge of the decentralized network, **** 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. +- *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. +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) @@ -675,13 +675,13 @@ Most users will not share long cryptographic hashes. To make content web-friendl **** 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. +- *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`. +- *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. @@ -698,9 +698,9 @@ Specialized indexers or "App Views" (functioning like web-frontends) consume thi *** 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. +- *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. @@ -771,9 +771,9 @@ Every Agora DID Document SHOULD include a list of service endpoints that allow o #+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). +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 @@ -794,18 +794,18 @@ The PDS-proximate / thin client model is a pragmatic solution to navigate these *** 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. +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. +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 diff --git a/projects/agora/docs/agora-requirements-04-the-primitive.org b/projects/agora/docs/agora-requirements-04-the-primitive.org index 6de5087..462c75d 100644 --- a/projects/agora/docs/agora-requirements-04-the-primitive.org +++ b/projects/agora/docs/agora-requirements-04-the-primitive.org @@ -66,53 +66,53 @@ The single `is_feed` property defines the behavioral intent of a Note without ch *** 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. +- *`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. +- *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. +- *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`). +- *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]`. +- *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`. +- *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**. +- *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 @@ -123,13 +123,13 @@ Agora implements strict validation to ensure network integrity. - `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. +- *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. +- *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) @@ -261,22 +261,22 @@ Agora implements strict validation to ensure network integrity. 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. +- *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. +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. +- *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 @@ -285,36 +285,36 @@ Agora uses three distinct fields to define relationships between Notes, balancin **** 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. +- *`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 | +| *`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:** +*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. +- *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. +- *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. +- *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) diff --git a/projects/agora/docs/agora-requirements-05-social.org b/projects/agora/docs/agora-requirements-05-social.org index 906d36a..be34534 100644 --- a/projects/agora/docs/agora-requirements-05-social.org +++ b/projects/agora/docs/agora-requirements-05-social.org @@ -15,17 +15,17 @@ Social Space encompasses all person-to-person and person-to-collective interacti ** 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. +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. +- *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. @@ -54,8 +54,8 @@ Every async interaction is a Note identified by a Content Identifier (CID). This 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. +- *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. @@ -68,21 +68,21 @@ This model ensures recipients have full ownership and control over the messages 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 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. +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: +- *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. +- *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. @@ -91,34 +91,34 @@ When an owner creates a broadcast Note (`access_control: []`), it is stored auth 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. +- *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. +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. +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. +- *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. +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. +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 @@ -135,31 +135,31 @@ Personas can publish their profiles and professional portfolios as decentralized ** 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. +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. +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. +- *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. +- *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. +- *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. diff --git a/projects/agora/docs/agora-requirements-06-exchange-and-contracts.org b/projects/agora/docs/agora-requirements-06-exchange-and-contracts.org index bc85c45..62584a9 100644 --- a/projects/agora/docs/agora-requirements-06-exchange-and-contracts.org +++ b/projects/agora/docs/agora-requirements-06-exchange-and-contracts.org @@ -211,10 +211,10 @@ To automate the release of HODL invoices without manual buyer intervention, SCAL *** 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." +- *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: @@ -241,30 +241,30 @@ To monetize high-bandwidth content (like video or software) in a decentralized, *** 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. +- *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. +- *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. +- *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. +- *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 diff --git a/projects/agora/docs/agora-requirements-07-advanced-integration.org b/projects/agora/docs/agora-requirements-07-advanced-integration.org index c98f239..21b6d07 100644 --- a/projects/agora/docs/agora-requirements-07-advanced-integration.org +++ b/projects/agora/docs/agora-requirements-07-advanced-integration.org @@ -383,11 +383,11 @@ interface KeyRotation { 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. +- *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 diff --git a/projects/agora/docs/agora-requirements-09-implementation.org b/projects/agora/docs/agora-requirements-09-implementation.org index 809b966..ed34fac 100644 --- a/projects/agora/docs/agora-requirements-09-implementation.org +++ b/projects/agora/docs/agora-requirements-09-implementation.org @@ -28,18 +28,18 @@ Sovereign iOS/Android clients with hardware-backed security and offline-first de *** 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. +- *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. +- *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. +- *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 @@ -157,23 +157,23 @@ Due to the offline-first nature of Agora clients and multi-device usage, identic - 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). +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):** +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:** +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:** +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. @@ -552,7 +552,7 @@ export class DeltaSyncEngine { | Msgpack | None | 1.1x | | JSON | None | 0.8x (larger) | -**Recommended:** CBOR + Zstd for bandwidth, CBOR for CPU-constrained devices. +*Recommended:* CBOR + Zstd for bandwidth, CBOR for CPU-constrained devices. ** Related Gaps diff --git a/projects/agora/docs/agora-requirements-10-governance-and-assets.org b/projects/agora/docs/agora-requirements-10-governance-and-assets.org index 4f84343..e411fb0 100644 --- a/projects/agora/docs/agora-requirements-10-governance-and-assets.org +++ b/projects/agora/docs/agora-requirements-10-governance-and-assets.org @@ -17,20 +17,20 @@ Governance in Agora isn't just about voting; it's about executing the results of ** 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?"). +- *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. +- *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. +- *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 @@ -47,9 +47,9 @@ Because Agora is decentralized and permissionless, "forking" is a legitimate and ** 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. +- *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) @@ -58,16 +58,16 @@ The PAL protocol bridges physical objects (cars, houses, shipments, equipment) i *** 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. +- *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. +- *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) diff --git a/projects/agora/docs/agora-requirements-11-assessment.org b/projects/agora/docs/agora-requirements-11-assessment.org index 12d2f35..21e0cfc 100644 --- a/projects/agora/docs/agora-requirements-11-assessment.org +++ b/projects/agora/docs/agora-requirements-11-assessment.org @@ -14,37 +14,37 @@ The Agora Protocol, following the integration of the Aletheia architecture, repr 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. +- *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. +- *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. +- *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. +- *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. +- *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. +- *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 @@ -56,10 +56,10 @@ Agora's performance model is decentralized by design, avoiding the "Global State ** 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. +- *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 diff --git a/projects/lisp_machine_bootstrap/docs/README.org b/projects/lisp_machine_bootstrap/docs/README.org index a92ad99..8c00a9b 100644 --- a/projects/lisp_machine_bootstrap/docs/README.org +++ b/projects/lisp_machine_bootstrap/docs/README.org @@ -11,17 +11,17 @@ The Lisp Machine Bootstrap project aims to remove the "Unix/C Tax"—the layers * Philosophy: Tagged, Homoiconic, and Bare-Metal -- **Hardware-Native Lisp:** Instruction Set Architecture (ISA) optimized for Lisp (CAR, CDR, CONS as hardware instructions). -- **Tagged Memory:** Memory management handled by the hardware, preventing buffer overflows and memory corruption by design. -- **Removing the C Core:** Eliminating the reliance on C-based kernels. The "Kernel" is a small Lisp bootstrapper. -- **FPGA First:** Utilizing Field-Programmable Gate Arrays (FPGAs) as the initial prototyping environment. +- *Hardware-Native Lisp:* Instruction Set Architecture (ISA) optimized for Lisp (CAR, CDR, CONS as hardware instructions). +- *Tagged Memory:* Memory management handled by the hardware, preventing buffer overflows and memory corruption by design. +- *Removing the C Core:* Eliminating the reliance on C-based kernels. The "Kernel" is a small Lisp bootstrapper. +- *FPGA First:* Utilizing Field-Programmable Gate Arrays (FPGAs) as the initial prototyping environment. * The Bootstrap Path -1. **Phase 1: Soft Machine (Current):** Emacs/CL running on Linux (The "Simulator"). -2. **Phase 2: Virtual Machine:** Develop a specialized Lisp VM that abstracts away the Linux kernel. -3. **Phase 3: FPGA Implementation:** Port the VM to an FPGA core (Verilog/VHDL). -4. **Phase 4: Sovereign Silicon:** Synthesize to a custom RISC-V or dedicated Lisp ASIC. +1. *Phase 1: Soft Machine (Current):* Emacs/CL running on Linux (The "Simulator"). +2. *Phase 2: Virtual Machine:* Develop a specialized Lisp VM that abstracts away the Linux kernel. +3. *Phase 3: FPGA Implementation:* Port the VM to an FPGA core (Verilog/VHDL). +4. *Phase 4: Sovereign Silicon:* Synthesize to a custom RISC-V or dedicated Lisp ASIC. * Initial Research & Tasks diff --git a/projects/org-skill-memex/docs/ARCHITECTURE.org b/projects/org-skill-memex/docs/ARCHITECTURE.org index 939ae98..8f945a3 100644 --- a/projects/org-skill-memex/docs/ARCHITECTURE.org +++ b/projects/org-skill-memex/docs/ARCHITECTURE.org @@ -11,9 +11,9 @@ Core architectural principles and design decisions for the org-agent memex syste The system is deliberately designed for *one human, one AI assistant*: -- **No coordination complexity**: One agent owns one workflow (Scribe = Atomic Notes (Zettelkasten) distillation, GTD Manager = task promotion) -- **No conflict resolution**: Agent reads from immutable sources (daily logs) and writes to separate targets (atomic notes, GTD promotions) -- **No multi-agent negotiation**: The assistant doesn't delegate to sub-agents; it executes skills directly +- *No coordination complexity*: One agent owns one workflow (Scribe = Atomic Notes (Zettelkasten) distillation, GTD Manager = task promotion) +- *No conflict resolution*: Agent reads from immutable sources (daily logs) and writes to separate targets (atomic notes, GTD promotions) +- *No multi-agent negotiation*: The assistant doesn't delegate to sub-agents; it executes skills directly This is *not* a multi-agent orchestration system. It's personal automation. diff --git a/projects/org-skill-memex/org-agent-memex-zettlekasten/openclaw-scribe-skill.org b/projects/org-skill-memex/org-agent-memex-zettlekasten/openclaw-scribe-skill.org index b551da8..9131711 100644 --- a/projects/org-skill-memex/org-agent-memex-zettlekasten/openclaw-scribe-skill.org +++ b/projects/org-skill-memex/org-agent-memex-zettlekasten/openclaw-scribe-skill.org @@ -6,10 +6,10 @@ The Scribe Agent is an automated distillation sub-agent designed to process raw daily captures into permanent atomic notes for the Atomic Notes (Zettelkasten). It runs as an isolated OpenClaw cron job. * Configuration -- **Type:** OpenClaw Cron Job -- **Target:** `isolated` -- **Model:** `CURRENT_TEXT_MANIPULATION_MODEL` (Updates periodically based on review; currently an efficient LLM suitable for text parsing). -- **Environment:** Loads variables from `.env` to locate folders (e.g., `$MEMEX_DAILY`, `$MEMEX_NOTES`, `$MEMEX_SYSTEM`). +- *Type:* OpenClaw Cron Job +- *Target:* `isolated` +- *Model:* `CURRENT_TEXT_MANIPULATION_MODEL` (Updates periodically based on review; currently an efficient LLM suitable for text parsing). +- *Environment:* Loads variables from `.env` to locate folders (e.g., `$MEMEX_DAILY`, `$MEMEX_NOTES`, `$MEMEX_SYSTEM`). * System Prompt / Agent Turn Directive ```markdown diff --git a/projects/org-skill-project-foundry/tests/verification.org b/projects/org-skill-project-foundry/tests/verification.org index dd14f6c..42e0f32 100644 --- a/projects/org-skill-project-foundry/tests/verification.org +++ b/projects/org-skill-project-foundry/tests/verification.org @@ -3,7 +3,7 @@ #+PROPERTY: header-args :tangle test-suite.lisp * Overview -This document defines the **Success Criteria** for the PSF Core Role Automation. It ensures that our agents are perceiving and enforcing the Consensus Loop correctly. +This document defines the *Success Criteria* for the PSF Core Role Automation. It ensures that our agents are perceiving and enforcing the Consensus Loop correctly. * Test Setup #+begin_src lisp diff --git a/system/backups/emacs.org.monolithic.bak b/system/backups/emacs.org.monolithic.bak index 49ae884..08cf49a 100644 --- a/system/backups/emacs.org.monolithic.bak +++ b/system/backups/emacs.org.monolithic.bak @@ -2147,7 +2147,7 @@ On package.el, it is a manual install so far ;; (use-package org-agent ;; :straight nil - ;; :load-path "~/memex-amero/projects/org-agent/src" ;; Adjust this to your local clone path + ;; :load-path "~/memex/projects/org-agent/src" ;; Adjust this to your local clone path ;; :commands (org-agent-connect org-agent-disconnect) ;; :init ;; Remote connection settings diff --git a/system/logs/session-history.org b/system/logs/session-history.org index 89995c8..73a0127 100644 --- a/system/logs/session-history.org +++ b/system/logs/session-history.org @@ -22,7 +22,7 @@ - [11:30] Successfully Distilled 14 atomic notes from 8-hour log. * 2026-03-16 - - **Git Activity (10+ commits):** + - *Git Activity (10+ commits):* - Applied global Org-mode corrections (front matter, bold syntax, TODO states) to over 70 memex files. - Enhanced project READMEs, specifically for the Atomic Notes (Zettelkasten) & GTD project, by adding/updating front matter, fixing formatting, and replacing checkboxes with TODOs. - Incorporated Amr's detailed requirements for collaboration, mobile access, NEXT item promotion logic, and org-todo states into the Atomic Notes (Zettelkasten) & GTD README.