chore: unify bold syntax to single asterisk in .org files and update legacy memex-amero references
This commit is contained in:
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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)
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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)
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user