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