amr/hermes-brain

Fork 0

Files

Hermes 4b60244919 Fix YAML frontmatter delimiter (|--- → ---) in stage 2 and 3

2026-05-24 18:07:14 +00:00

29 KiB

Raw Blame History

Social Protocol Requirements - 01: Protocol Overview and Foundational Principles

1. Introduction to the Social Protocol
2. Foundational Principles
3. Core Technical Differentiators
4. Use Cases: A Paradigm Shift
5. Conclusion: Towards a Self-Sovereign Digital Future
Bootstrapping & Progressive Decentralization
Strategic Positioning
Legal & Regulatory
Game Theory & Economic Attacks
- Attack Vectors
- Defenses
Related Documents

1. Introduction to the Social Protocol

The social 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 protocol 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 the protocol'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.

2. Foundational Principles

The protocol's design is predicated upon a set of core principles that collectively ensure a robust, user-centric decentralized network.

2.1. User Sovereignty and Data Ownership

Central to the protocol is the tenet of user sovereignty. Unlike centralized paradigms where platforms intermediate and often monetize user data, the protocol's architecture ensures that all user-generated content and personal data are exclusively owned and controlled by the originating user. This is achieved through client-side encryption, self-hosted or user-controlled Personal Data Stores (PDS), and audience-defined access controls (`access_control`).

2.2. Decentralization and Censorship Resistance

The protocol is designed to eliminate single points of failure and control. By distributing data storage across user-controlled PDSs and routing communication through a permissionless Relay Network, the protocol inherently resists censorship and external manipulation. There is no central authority capable of unilaterally restricting access, altering content, or deplatforming users.

2.3. Authenticity and Verifiability

Every action and piece of content within the protocol is cryptographically signed by the originating Persona. This provides an immutable and auditable record, ensuring the authenticity and integrity of all interactions. The content-addressed nature of all data, via Content Identifiers (CIDs), guarantees that content cannot be altered without changing its unique identifier, thereby establishing verifiable provenance.

2.4. Privacy by Design

The protocol incorporates privacy-enhancing technologies at every layer. End-to-end encryption is a default for private communications, and mechanisms such as Blinded Sharding for social recovery and "Off-the-Record" modes for ephemeral interactions are integrated to minimize metadata leakage and ensure user confidentiality.

3. Core Technical Differentiators

The protocol's unique capabilities stem from the synergistic integration of three primary technical differentiators: The Note Primitive, Self-Sovereign Identity (Personas and Master Key), and a Distributed Infrastructure (PDS and Relay Network).

3.1. The Note Primitive: Atomic Unit of Information

At the heart of the protocol'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 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 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

The protocol's identity system grants users absolute control over their digital presence, leveraging Hierarchical Deterministic (HD) cryptography to derive and manage multiple functional identities.

3.2.1. The Master Key (Anima)

The Master Key serves as the absolute root of a user's digital being within the protocol.

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 protocol 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.

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.

3.3. Distributed Infrastructure: PDS, Relays, and Thin Clients

The protocol's infrastructure is specifically engineered to underpin user sovereignty, data ownership, and censorship resistance.

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-protocol 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 the protocol, 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.

3.3.3. Agile Client Architecture: Broad Accessibility and Adaptability

The protocol 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 the protocol's reach to a wider user base while maintaining security and privacy.

4. Use Cases: A Paradigm Shift

The synergistic combination of the protocol's core differentiators enables a wide array of transformative use cases, redefining digital interaction across multiple domains.

4.1. Decentralized Social Interaction

The protocol provides a robust framework for secure, private, and censorship-resistant interaction, moving beyond traditional platform-controlled silos.

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.

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.

4.2. Social Publishing and Knowledge Management

The protocol fundamentally reshapes how content is created, published, and managed, empowering creators and ensuring verifiable knowledge.

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.

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.

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.

4.3. Decentralized E-commerce and Markets

The protocol enables peer-to-peer economic interaction without intermediaries, fostering transparent and auditable marketplaces for goods and services.

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.

4.3.2. Fungible vs. Non-fungible Assets

Non-Fungible: The protocol'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 the protocol 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 protocol for order matching and liquidity.

4.4. Decentralized Collaboration and Project Management

The protocol offers robust primitives for secure, auditable collaboration, empowering teams and communities.

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.

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.

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.

4.5. Liquid Democracy and Governance: Evolvable Collectives

The protocol's identity and contract primitives lay the groundwork for a dynamic, adaptive model of decentralized governance that moves beyond the rigidity of traditional blockchain-based DAOs.

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, the protocol's 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 the protocol 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

The social protocol is meticulously designed to serve as the foundational layer for a new era of decentralized digital interaction. By unifying identity, data, and communication under the immutable, verifiable, and user-owned "Note" primitive, coupled with a distributed infrastructure and self-sovereign identity management, the protocol offers a robust and resilient alternative to centralized systems. Its capabilities span from secure personal communication to complex global e-commerce, from collaborative knowledge creation to transparent democratic governance. The protocol empowers individuals and collectives to reclaim their digital sovereignty, fostering an internet where trust is cryptographic, privacy is inherent, and freedom is architectural.

Bootstrapping & Progressive Decentralization

The Cold Start Problem

A decentralized social network faces an existential network effect challenge. Users will not join if there is no content, and creators will not post if there are no users. The protocol solves this through Progressive Decentralization.

Bootstrap Sequence

The system MUST provide a smooth onboarding experience, especially in the first five minutes:

Persona Selection: A simple UI for selecting a "Persona Alias" (e.g., `@amr`).
Key Generation: High-speed, hardware-backed key derivation (BIP-32) happens in the background.
PDS Selection: Users are prompted to choose between "Managed Hosting" or "Self-Hosting".
Relay Discovery: The client automatically connects to a set of high-reputation, geographic "Bootstrap Relays" to fetch initial content.
Interest Capture: Users select topics/interests to seed initial content recommendations.
Migration Option: Offer to import from Twitter, Reddit, Mastodon, etc. to bootstrap social graph.

Interest Capture

Purpose

Reduce "empty feed" problem by immediately showing relevant content based on user interests.

Implementation

Explicit Selection: Users pick from curated categories (Technology, Art, Politics, Science, etc.).
Implicit Extraction: If user imports from centralized platforms, parse their follows/history to infer interests.
AI Assistance: Sub-Agent can analyze imported content to suggest interest categories.

Content Seeding

Client fetches popular public content in selected interest areas.
Initial feed populated with high-quality, diverse content from selected topics.
Users can refine interests over time (feedback loop).

Migration and Social Graph Bootstrap

Supported Platforms

Twitter/X: Import followed accounts via archive export or API.
Reddit: Import subscribed subreddits and frequent communities.
Mastodon/ActivityPub: Native federation, direct import of follows.
LinkedIn: Professional connections import.
Blog/RSS: Import RSS subscriptions as interest sources.

Privacy Considerations

Migration is opt-in, not mandatory.
Users choose which platforms to import from.
Imported data is stored locally; only new protocol follows are public.
Users can audit and remove imported suggestions before confirming follows.

Discovery Expansion

Suggest high-reputation personas in imported interest areas.
Show "Your Twitter follows on the protocol" for easy reconnecting.
Surface collectives matching imported community memberships.

The "Four Orders of Growth" (Scaling Sequence)

Scaling a decentralized network requires shifting from "Hand-holding" to "Protocol Incentives." The protocol 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.

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.

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.

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 the protocol 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

Phase 1: Managed Service (Days 1-100)

Centralized Experience: The initial developers provide high-performance, managed PDS and Relay services to ensure a seamless "Twitter-like" experience.
Focus: User acquisition and content density in specific "Alpha" collectives (e.g., AI/Dev communities).

Phase 2: Hybrid (Year 1)

Self-Hosting Options: Users are encouraged to move to their own PDS or third-party providers as the ecosystem matures.
Social Graph Interoperability: Enabling users to "Follow" personas across different PDS providers.

Phase 3: Full Decentralization (Year 3+)

No Central Authority: The original developers become just one of many PDS and Relay providers.
Protocol Stability: The V1.0 spec is finalized, and development is driven by the Protocol Governance Model.

Incentivized Growth

Referral Satoshis: Early users can be rewarded in satoshis for successful referrals that lead to high-reputation personas.
Micro-Grant Bounties: Funding developers to build "Must-Have" protocol apps through the economic layer.

Strategic Positioning

Platform Replacement Strategy

Rather than positioning the protocol as an existential threat to Big Tech (Apple, Google, Meta), the protocol should first target underserved communities and platforms with clear pain points:

Phase 1: Niche Community Platforms

Forums (Reddit, phpBB, vBulletin)

Pain Point: Centralized moderation, censorship, data mining.
Social Protocol Advantage: Sovereign moderation, portable identity, no platform lock-in.
Target Communities: Developer forums, hobbyist communities, support forums.

Visual Discovery (Pinterest)

Pain Point: Algorithmic manipulation, advertising-driven discovery.
Social Protocol Advantage: User-chosen discovery algorithms, no surveillance capitalism.

Professional Communities (LinkedIn, corporate intranets)

Pain Point: Professional data exploitation, platform-controlled networking.
Social Protocol Advantage: Sovereign professional identity, portable reputation.

Creator Platforms (Medium, Substack)

Pain Point: Platform fees (10-50%), censorship risk, no portability.
Social Protocol Advantage: Near-zero fees, content ownership, subscriber portability.

Marketplaces (eBay, Etsy)

Pain Point: High fees (10-15%), centralized dispute resolution, account bans.
Social Protocol Advantage: Low fees (<5%), transparent reputation, sovereign stores.

Adult Content (Pornhub, OnlyFans)

Pain Point: Censorship, payment processor discrimination, lack of privacy.
Social Protocol Advantage: Censorship-resistant, Lightning-native payments, pseudonymous.

Specialized Communities (QRZ, Logbook of the World)

Pain Point: Aging infrastructure, lack of modern features, centralization.
Social Protocol Advantage: Modern protocol, extensible, community-governed.

Decentralized Communities (Nostr, Fediverse)

Pain Point: Fragmentation, lack of economic layer, UI/UX challenges.
Social Protocol Advantage: Unified protocol, Lightning integration, polished UX.

Phase 2: Horizontal Expansion

Once established in niche communities:

Bridge to Big Tech: Migration tools for Twitter, Instagram, etc.
Enterprise Adoption: Sovereign collaboration tools for companies.
Mass Market: Only after protocol stability and network effects proven.

Big Tech Analysis (Long-term)

While not the immediate focus, the protocol's architecture eventually threatens Big Tech:

Meta/Facebook

Risk: Portable identity undermines social graph lock-in.
Timing: Year 3+ after network effects established.

Apple

Opportunity: Privacy alignment, hardware security integration.
Risk: App Store policies may restrict protocol clients.

Google

Risk: Search dominance challenged by social-graph-first discovery.
Opportunity: Federated search, open data standards.

The "Trojan Horse" Strategy

Start Small: Win over frustrated communities on Reddit, forums, Discord.
Build Bridges: ActivityPub/Mastodon integration, Twitter migration tools.
Demonstrate Value: Show "You trade 2 seconds for freedom" is worth it.
Let Giants React: By the time Big Tech notices, the protocol is entrenched.

Strategic Assessment

Cold Start Problem: The most significant hurdle. Requires aggressive bootstrapping in the first year.
Success Probability: 30-50% for 100K users; 10-20% for 1M users (within 3 years).
The "Unstoppable" Factor: Once the protocol is decentralized and the first million users are on-boarded, it becomes nearly impossible to shut down.

Legal & Regulatory

The Jurisdictional Challenge

As a decentralized protocol with no central authority, the protocol is designed to operate across international jurisdictions.

Content Moderation & Liability

The "Dumb Pipe" Strategy

Relays as Carriers: Relays act as dumb, ephemeral conduits for encrypted CIDs. Their legal standing is similar to ISPs or postal services.
PDS Sovereignty: The user (the PDS owner) is the only entity with the ability to decrypt and view the content.

The CSAM Challenge

Zero Tolerance Policy: The protocol's governance model includes protocol-level consensus for universally illegal content.
Network-Level Blocking: High-reputation Relays can block CIDs associated with CSAM.
Fundamental Tension: The trade-off between total privacy (E2EE) and the ability to detect illegal content.

Financial Regulation & AML

Micro-Payments: Lightning Network payments generally fall below traditional AML/KYC thresholds.
Non-Custodial: The protocol is non-custodial. Users control their own keys and funds.

Data Privacy (GDPR/CCPA)

The "Right to be Forgotten": In a CID-based system, data is not "deleted" but can be "un-indexed" or its decryption keys revoked.
Sovereign Control: Users have absolute control over their own data in their PDS.

Strategy for Resistance

Legal Defense Collective: Establishing a legal defense fund (Collective Persona) to support Relay and PDS operators.
Transparency Reports: High-reputation Relays and PDS providers should publish transparent reports on compliance.

Game Theory & Economic Attacks

Attack Vectors

Sybil Attacks: Creating millions of fake personas.
Relay Censorship: Majority of Relays blocking specific content.
Economic Spam: Paying minimal fees to flood the network.
Governance Capture: Attempting to take over protocol governance.

Defenses

Reputation Systems: Economic and social costs of attack increase with reputation requirements.
Multi-Home Relays: Users can always switch to uncensored Relays.
Fee Markets: Dynamic pricing makes spam economically unviable.
Fork Threat: Credible threat of fork prevents governance capture.

29 KiB Raw Blame History