chore: unify bold syntax to single asterisk in .org files and update legacy memex-amero references

This commit is contained in:
2026-04-01 12:37:45 -04:00
parent 42eaf91953
commit 5fd8614bad
10 changed files with 377 additions and 377 deletions

View File

@@ -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)