hermes-brain/ideas/passepartout-social-protocol/requirements-05-social.org

Social Protocol Requirements - 05: Social Space

• Social Space: Where Human Connection Becomes Sovereign
  • Concept
  • Asynchronous Communication (Correspondence & Messaging)
    • The Mailbox (PDS as Proxy)
    • Contextual Isolation
  • The Unified Note Primitive
    • Flag Definitions & Storage Models
    • Ephemeral Content
    • Structural Integrity
  • Directed Communication (Copy-on-Send Model)
    • Audience & Attention
    • Mechanism
    • Data Ownership
  • Social Publishing: Feeds & Streams
    • Concept: Feed vs. Stream
    • The "Lens" Architecture (Polymorphic UI)
    • Mechanism
    • Owner Control
    • Content Types
  • Synchronous Communication (Live Voice & Video)
    • Decentralized Signaling
    • Off-the-Record (OTR) Mode
  • Encryption & Metadata Privacy
    • Double Ratchet Algorithm (Signal Protocol)
    • Metadata Masking (Onion Routing)
  • Profiles
    • Concept
    • Requirements
    • Profile as Static Site
  • The Attention Marketplace (The Information Router)
    • Pluggable Feed Generation (PFG)
    • The Algorithm Marketplace
    • Decentralized Moderation (Competitive Labeling)
    • Circular Economy: Following as Investment
    • Decentralized Moderation (Stackable Labelers)
  • Social Governance & Moderation
    • Multi-layered Moderation
  • Related Documents

Social Space: Where Human Connection Becomes Sovereign

The Social Space is where Social Protocol's revolutionary architecture transforms how humans connect, communicate, and transact. Unlike traditional platforms that own your relationships and monetize your attention, the protocol puts you in complete control of your social graph. Every interaction—from a casual conversation to a binding commercial contract—is self-owned, cryptographically secured, and entirely under your sovereignty. This is social interaction reimagined for a decentralized future.

Concept

Social Space encompasses all person-to-person and person-to-collective interaction in the protocol: public and private, asynchronous and real-time. All social interaction is mediated by Notes and contracts running on the Exchange layer.

Asynchronous Communication (Correspondence & Messaging)

Asynchronous communication in the protocol 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.

Contextual Isolation

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

The Unified Note Primitive

All asynchronous interaction in the protocol—whether a public post or a private message—is built upon the same "Note" primitive. The behavior and visibility of a Note are defined by cryptographic signatures and a set of standardized metadata flags.

Flag Definitions & Storage Models

Flag	Meaning	Storage Model
`access_control: []`	Broadcast (Public)	Reference-on-Send (authoritative on owner's PDS)
`access_control: [DIDs]`	Restricted (Private)	Copy-on-Send (authoritative on each recipient's PDS)
`is_feed: true`	Chronological entry (Post/Update)	Varies (e.g., public feed items are Reference-on-Send)
`is_feed: false`	Static resource (Page/Wiki)	Reference-on-Send

Ephemeral Content

Notes where `ephemeral_duration > 0` are automatically garbage-collected by the PDS and dropped from routing tables by Relays after the duration expires.

Structural Integrity

Every async interaction is a Note identified by a Content Identifier (CID). This ensures that the history of a conversation or content stream is immutable and cryptographically verifiable.

Directed Communication (Copy-on-Send Model)

For Notes intended for specific recipients (e.g., 1-on-1 messages, group chats), the protocol 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.

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.

Data Ownership

This model ensures recipients have full ownership and control over the messages they receive. Access to the Note is independent of the sender's PDS status after the initial send.

Social Publishing: Feeds & Streams

For content intended for a broad audience (e.g., social posts, public articles, project wikis), the protocol 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 "Lens" Architecture (Polymorphic UI)

Because all data in the protocol 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:

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

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.

Owner Control

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.

Synchronous Communication (Live Voice & Video)

For real-time calls, the protocol 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 the protocol, 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.

Encryption & Metadata Privacy

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

Metadata Masking (Onion Routing)

To hide traffic patterns from network observers, the protocol 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

Concept

A Profile is a public-facing presentation of a Persona. The protocol supports multiple Profiles per Persona (e.g., a "Public Developer" profile and a "Private Family" profile).

Requirements

• Each Profile MUST be a Note (CID) with public visibility.
• Profiles MUST be discoverable via the Naming Registry.
• Profile updates create new CIDs, preserving a verifiable history of the identity's presentation.

Profile as Static Site

Personas can publish their profiles and professional portfolios as decentralized static websites using the native hosting model (see Infrastructure). Protocol-aware browsers render these natively from CIDs, while legacy browsers access them via Gateways with automated SSL and domain mapping.

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 the protocol, the Algorithm Layer is reimagined as an open Information Router. By moving the algorithm out of the central server and into an open market, the protocol 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.

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.

Decentralized Moderation (Competitive Labeling)

Moderation in the protocol 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.

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.

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.

Social Governance & Moderation

Multi-layered Moderation

1. Individual: Publisher controls their own content and PDS.

2. Community (Social Governance): Collective rules enforced via governance modules (GEM).

   • Global Blocklists: Communities can vote on shared moderation policies. If a quorum (e.g., 70% of an NGO's members) flags a specific DID as a "Spam Bot," that DID is automatically added to a Global Blocklist and hidden from all participating members' feeds.
   • Curated Feeds: A community can vote to "Pin" certain content creators to a shared "Featured" feed, effectively acting as a decentralized editorial board.
3. Algorithm: User-chosen filtering and sorting via PFG and Competitive Labeling.
4. Network: Protocol-level consensus for universally illegal content (e.g., CSAM).

Related Documents

• 06: Exchange and Contracts - Economic layer and human connection formalization.
• 02: Identity - Personas and Master Keys.
• 03: Infrastructure - PDS and Relays.