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