agora/docs/agora-requirements-02-identity.org at main

amr/agora

Files

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

2026-04-01 12:37:45 -04:00

44 KiB

Raw Permalink Blame History

Identity: The Genesis of Your Digital Being

Identity: The Genesis of Your Digital Being

Master Key (Psyche)

The Master Key, often referred to as "Psyche" (Latin for soul or animating principle), is the absolute foundation of your digital identity in Agora. It serves as your unassailable root of trust, from which every other functional identity (your Personas) is cryptographically derived. This section meticulously outlines the Master Key's core requirements, elucidates how it empowers flexible organizational structures, and details the robust mechanisms for its secure management and resilient recovery. It is the ultimate key to your self-sovereignty.

Requirements & The Root of Trust

The system MUST cryptographically decouple identity from the master cryptographic material, ensuring that derived keys can be managed independently while retaining the Master Key as the root of authority.
Users MUST possess one Master Key (the "Seed") that is generated and stored securely, ideally never exposed to the network or a general-purpose operating system.
All functional identities (Personas) MUST be derived from this single Master Key seed using Hierarchical Deterministic (HD) derivation, providing an organized and secure structure for digital identities.
The Master Key MUST be generated from a minimum of 256 bits of high-quality, cryptographically secure entropy.
The Master Key MUST be encoded as a BIP-39 mnemonic phrase (typically 24 words) for human-readable, offline backup and disaster recovery.
The Master Key MUST be stored offline (e.g., on paper, engraved metal) or within a tamper-resistant hardware security module (HSM) for maximum protection against compromise.
The system MUST utilize a custom HD derivation path: `m/44'/1'/account'/persona'/key_purpose/key_index`, uniquely identifying Agora's identity structure within the broader BIP-44 ecosystem. (Note: Index `1'` is utilized for the experimental/testnet phase; a unique permanent index will be registered for the Agora Mainnet via SLIP-0044.)
This path allows each Persona to act as a "Sub-Root," deriving its own autonomous functional keys (e.g., for Bitcoin, Lightning, PGP, or SSH) without requiring access to the Master Key once the Persona's extended private key (xpriv) is provisioned to a device.
Each `persona'` index within this derivation path MUST represent a distinct DID (Decentralized Identifier), ensuring global uniqueness and unlinkability.
The system MUST allow a single Master Key seed to generate an infinite number of unique, unlinkable personas, providing unparalleled flexibility for different digital roles.
Each Persona MUST possess its own distinct Ed25519 keypair for cryptographic signing and an X25519 keypair for robust encryption.
The system MUST enable the revocation and rotation of individual Persona keys without compromising the integrity of the Master Key or affecting other derived Personas, offering granular control and enhanced security.
The identity lifecycle MUST be managed via KERI (Key Event Receipt Infrastructure), ensuring identities remain persistent regardless of key rotations.
All key rotations and membership changes MUST be recorded in an append-only, verifiable Key Event Log (KEL).

Master Key Interaction Protocol: Derivation vs. Action

It is critical to distinguish between the Master Key's role in Persona derivation and a Persona's role in network actions.

Master Key for Derivation (Creation of New Identities): The Master Key is the sole cryptographic origin for generating new Accounts and Personas. Any creation of a new Persona (or Account) in your identity tree requires interaction with the Master Key. This ensures a clear, auditable, and cryptographically sound chain of custody from your single root to every Persona. While this might occasionally require accessing a hardware wallet for a new Persona setup, it safeguards the integrity of your entire identity graph.
Persona Keys for Actions (Interacting with the Network): Once a Persona is created, it becomes a fully independent, active agent in the Agora network. All subsequent actions—signing messages, publishing content, entering into contracts (including Foundation Contracts), acting as a guardian for social recovery, or joining an organization—are performed using the Persona's own distinct keypairs. The Master Key is explicitly *not needed for these daily operational activities.* This design minimizes the Master Key's exposure, keeping it safely offline and dramatically reducing the frequency of hardware wallet interactions for routine tasks.

This clear separation ensures that your Master Key functions as a secure, infrequent-use root for identity creation and recovery, while your Personas are empowered to execute all network interactions autonomously.

Master Key Recovery: The Offline Root Seed

Shamir's Secret Sharing: Distributed Trust

If a user loses access to their offline Master Key, Agora's Social Recovery mechanism provides a decentralized, self-sovereign solution:

Master Key is cryptographically pre-split into N shards using Shamir's Secret Sharing.
These shards are securely distributed to M-of-N "Guardians" (trusted friends or professional services).
Recovery only requires M guardians to recombine their shards, rebuilding the Master Key offline.
This elegantly avoids reliance on centralized "Account Recovery" services, keeping you in control.

Social Recovery Privacy (Blinded Sharding)

Blinded Sharding Concept

Standard Shamir's Secret Sharing reveals which guardians hold shards when shards are stored on the PDS. Blinded Sharding hides this information from the PDS while still enabling recovery.

How Standard Shamir Reveals Guardians

Shards stored as: `(index, shard_value)` pairs
PDS sees: "Guardian #1 has this shard, Guardian #2 has that shard"
Reveals: Who the user's trusted contacts are (social graph)

Blinded Sharding Solution

Instead of storing `(index, shard)` directly, use cryptographic blinding:

Step 1: Generate Mask

Random mask `m` for each shard
Mask is encrypted to Guardian's public key
Only Guardian can unmask the shard

Step 2: Store Blinded Shard

``` Stored on PDS:

Blind = hash(shard || guardian_pubkey)
Shard encrypted to Guardian's key (X25519 + AES-GCM)
Guardian ID: NOT stored in plaintext, only hash

```

Step 3: Recovery

Guardian sends encrypted shard response
User decrypts using their private key
Verifies shard validity via Shamir reconstruction
PDS never learns which Guardians participated

Implementation

interface BlindedShard {
  // Public, stored on PDS
  shardHash: string;              // hash(shard || guardian_pubkey)
  encryptedShard: string;         // X25519 + AES-GCM encrypted
  
  // Not stored: Guardian ID
  // Guardian identified by: can decrypt `encryptedShard`
  // (only valid Guardian has private key)
}

interface GuardianConfig {
  guardianDID: string;            // Known to user, NOT to PDS
  guardianPublicKey: X25519PublicKey;
}

// Shard creation
function createBlindedShard(
  shard: Buffer, 
  guardianConfig: GuardianConfig
): BlindedShard {
  const shardId = hash(sha256, [shard, guardianConfig.guardianPublicKey]);
  const encrypted = x25519_encrypt(shard, guardianConfig.guardianPublicKey);
  
  return {
    shardHash: shardId,
    encryptedShard: encrypted
  };
}

// Reconstruction
async function recoverShard(
  blindedShard: BlindedShard,
  guardianPrivateKey: X25519PrivateKey
): Promise<Buffer> {
  // Guardian decrypts
  const decrypted = x25519_decrypt(
    blindedShard.encryptedShard, 
    guardianPrivateKey
  );
  
  // Verify not corrupted
  if (hash(sha256, [decrypted, guardianPublicKey]) !== blindedShard.shardHash) {
    throw new Error("Shard verification failed");
  }
  
  return decrypted;
}

Security Properties

PDS doesn't know Guardians: Only sees random hashes and ciphertexts
PDS can't correlate: Different users' Guardians appear as different random data
Guardian anonymity: Recovery can happen without PDS knowing who responded
Integrity verified: Hash check prevents corrupted shards

Shamir's Secret Sharing Parameters

Standard Parameters

Scheme: Shamir's Secret Sharing over GF(2^256)
Threshold (M): 3 (minimum to reconstruct)
Total Shares (N): 5 (total generated)
Security: 256-bit security (same as Bitcoin private keys)

Share Distribution

Guardian 1: Trusted friend, geographically distant
Guardian 2: Family member
Guardian 3: Professional service (optional)
Guardian 4: Personal cloud/HSM backup
Guardian 5: Safety deposit box (physical)

Recovery Probability

1 guardian fail: Still recoverable (4 of 5 remaining)
2 guardians fail: Still recoverable (3 of 3 remaining)
3+ guardians fail: Unrecoverable (design choice)

HD Derivation

HD Derivation Architecture (BIP-32/44)

Agora uses a custom derivation path to ensure interoperability: `m/purpose'/persona_index'/profile_index/key_type`.
The `persona_index'` MUST be hardened to prevent correlation attacks between different personas.
Each `persona_index'` MUST represent a distinct DID (Decentralized Identifier).
This allows a single seed to generate infinite, unlinkable personas.

Decoupled Key Provisioning & Watch-Only Master

To minimize the exposure of the Master Seed, client applications MUST support decoupled key strategies:

Subkey Injection: The client MUST allow importing a standalone extended private key (xpriv) or raw private key for a specific `persona_index'`. The app operates strictly within the scope of that imported key and cannot derive sibling personas.
Multi-Device Sync: Users can securely provision a secondary device (e.g., a mobile phone) by injecting a Persona-level subkey, keeping the Master Seed in a physical hardware vault.
Watch-Only Master: The client MAY allow storing the Master Extended Public Key (xpub). This creates an "Auditor View," enabling the device to monitor all derived Personas and balances without possessing the private keys necessary to authorize transactions or sign events.

Cross-Persona Interaction (The "Bridge")

The system MUST allow a user to prove relationships between their own Personas without publicly linking them to a single Master Seed.

Zero-Knowledge Proofs (ZKP): A user can "Attest" that a specific capability or badge belongs to them across personas. For example, a "Pseudonymous Developer" Persona can use a ZKP to prove it holds a "Verified Citizen" badge issued to its associated "Legal Persona," proving citizenship without revealing which citizen they are.

Index Management (Gap Limit Protocol)

Concept

Clients must efficiently discover active personas derived from a Master Seed without performing an exhaustive scan of the entire index space. The Gap Limit Protocol defines the search window and criteria for identifying active personas during recovery or sync.

Specification

Gap Limit (L): The number of consecutive unused persona indices to check before stopping the scan. The default Agora gap limit is 20.
Active Persona Detection: A persona index is considered "active" if it has:
1. A registered name in the Tier 2 Global Registry.
2. Any Content Objects published to a PDS/Relay.
3. Any incoming attestations from other personas.
Scan Window: Clients scan indices in increments of L. If any index within $[i, i+L-1]$ is active, the window shifts to $[i+L, i+2L-1]$.

Recovery Workflow

Derive Master Key.
For each account index (starting from 0'):
1. Scan persona indices 0 through L-1.
2. If any active persona is found, continue scanning the next window of L.
3. If no active personas are found in the window, stop scanning this account.
If no active personas are found in the first window (0 through L-1) of an account, stop scanning accounts.

Centralized Revocation Efficiency: The Atomic Kill Switch for Organizations

Comparison to Traditional Systems

Traditional: Partner leaves → Manually update 50+ passwords, revoke individual access rights across numerous platforms (email, bank, cloud storage, code repos, etc.). High risk of oversight and residual access.
Agora: Partner leaves → One managed revocation at the Master Key level (or their specific Persona's access derivation is severed) → Instant, automatic severance of access across all derived keys (company Bitcoin, PGP, SSH, etc.).

This mechanism ensures that the collective's assets remain secure and under the control of the remaining authorized members, providing a robust solution for organizational identity management.

Accounts

Account-Level Strategy: Organizing Your Digital Life

Derivation Path with Accounts

``` m/44'/1'/0'/0' # Account 0, Persona 0 (default personal) m/44'/1'/0'/1' # Account 0, Persona 1 m/44'/1'/1'/0' # Account 1, Persona 0 (work account) m/44'/1'/1'/1' # Account 1, Persona 1 (work, second persona) m/44'/1'/2'/0' # Account 2, Persona 0 (anonymous/account-specific) ```

Account Separation Strategies

Personal vs Work

Account 0: Personal life, friends, family
Account 1: Professional identity, colleagues
Each account has its own set of personas (persona index within account)

Anonymous vs Primary

Account 0: Primary public identity
Account 2+: Anonymous or temporary accounts
Easy rotation: revoke entire account, create new account index

Organizational Accounts

Account 3+/Specific Values: Could be assigned for specific organizations
Each organization gets its own account namespace

Account Naming and Metadata

Account Aliases: User-defined labels ("Personal", "Work", "Anonymous")
Account Icons: Visual distinction in client UI
Account Metadata: Not stored on-chain, local to client
Account Lock/Unlock: Separate authentication for each account

Account-Specific Configuration

Default PDS: Each account can use different PDS providers
Default Relays: Account-specific relay preferences
Contact Isolation: Contacts in one account not visible in others (by default)
Content Visibility: Cross-account content visibility configurable

Cross-Account Operations

Account Switching: Quick switch without re-entering Master Key
Cross-Account References: "Share from Work to Personal" with privacy controls
Unified Inbox: Optional aggregation of notifications across accounts
Backup Strategy: Account-level backup (export all personas in account)

Security Considerations

Same Master Key: All accounts derived from same seed—compromise of Master Key compromises all accounts.
Different Lock Codes: Each account can have its own unlock PIN/biometric.
Plausible Deniability: Hidden accounts possible (account index not sequential).

Developer Implementation

To generate a new Persona:

Load Master Seed.
Derive path `m/44'/1'/0'/N'` where N is the next available index.
Generate Ed25519 keypair from the derived entropy.
Construct the DID: `did:agora:<pubkey_multibase>`.

Account-Level Technical Specification: The Blueprint for Digital Organization

The Account-Level Strategy is built upon a robust technical foundation that rigorously adheres to and extends industry standards for cryptographic key derivation. This specification ensures predictable, secure, and interoperable management of multiple digital identities from a single Master Key.

BIP-44 Derivation Path Structure: Agora's Standard

Agora meticulously follows the established BIP-44 standard for hierarchical deterministic key derivation paths. This standardized structure guarantees compatibility and logical organization of your digital identities.

`m / purpose' / coin_type' / account' / persona' / key_purpose / key_index`

In Agora's context, this is specifically mapped as:

`m / 44' / 1' / account' / persona' / key_purpose / key_index`

Purpose (44'): This is a hardened derivation, as prescribed by BIP-44, signifying that the derived keys are cryptographically isolated from the Master Key.
Coin Type (1'): This is a hardened derivation, and `1'` is the officially registered SLIP-0044 index specifically allocated for the Agora Protocol.
Account (account'): This is a hardened derivation. It provides independent, cryptographically isolated persona namespaces, enabling users to manage distinct organizational or contextual groupings of Personas.
Persona (persona'): This is a hardened derivation. Each index represents a distinct, autonomous digital identity (DID). Hardening ensures that compromising one Persona's keys cannot compromise sibling Personas or the Master Key.
Key Purpose (key_purpose): This non-hardened layer allows a single Persona to act as a "Sub-Root" to derive autonomous functional keys for specific tasks without requiring the Master Key. Examples:
- `0`: Primary Identity/Signing Key (Ed25519)
- `1`: General Encryption Key (X25519 for DIDComm)
- `2`: Bitcoin/Lightning Node Key
- `3`: Stablecoin/EVM Wallet
Index (key_index): This is a non-hardened, incremental index used to generate multiple unique keys of a specific purpose (e.g., generating new receive addresses for a Bitcoin wallet).

Note: This structure ensures that once a Persona's xpriv is loaded on a mobile device, that device can derive all necessary sub-wallets autonomously without re-accessing the Master Key.

Account Types and Reserved Indices: Standardized Compartmentalization

While the choice of account indices is technically arbitrary, Agora recommends the following conventions. These standardized assignments ensure client interoperability and provide a common language for managing distinct digital compartments.

0': Primary Account. This is the default account for a user's primary personal identity, social interactions, and other everyday personas.
1': Professional Account. This account is dedicated to professional identity, credentials, work-related personas, and business interactions.
2': Anonymous/Testing Account. Designed for high-churn, disposable, or experimental personas where anonymity or frequent rotation is desired.
100'+: Organization/Collective Accounts. These indices are reserved for managing personas specifically associated with organizational entities, such as companies, DAOs, or other collective structures.

Client-Side Management Rules: Enforcing Security and Privacy

Client applications interacting with Agora's identity system MUST adhere to a strict set of rules to ensure the security, privacy, and integrity of user accounts.

Account Discovery (Gap Limit): Clients MUST implement a "Gap Limit" (a heuristic search window, typically 20) for account discovery. During recovery or initial synchronization, the client scans accounts 0' through `N'` (where `N'` is determined by the gap limit and activity) for active personas. If an active account is found, the scan window is intelligently shifted forward.
Context Isolation: Data associated with different accounts (e.g., contact lists, encryption keys, local indexes) MUST be stored in cryptographically isolated database partitions or encrypted with account-specific salts. This prevents accidental data leakage between contexts.
Cross-Account Privacy: Clients MUST NOT leak the relationships or activities between personas residing in different accounts unless explicitly authorized by the user (e.g., through a signed cross-account attestation Note).
Independent Authentication: Clients SHOULD allow users to set distinct local authentication requirements (e.g., PINs, biometric scans) for sensitive accounts (e.g., 1' Professional or 100' Organization accounts), providing an additional layer of security for critical digital identities.

Technical Implementation (Pseudocode)

```typescript / Example: Account derivation from a Master Node (representing the Master Key) const accountIndex = 0; / Defines the specific account (e.g., Primary) const accountNode = masterNode.derivePath(`m/44'/1'/${accountIndex}'`);

/ Example: Persona derivation within the chosen account const personaIndex = 0; / Defines the specific persona within the account const personaNode = accountNode.derivePath(`0/${personaIndex}`);

/ Example: Key Generation for the derived Persona / Ed25519 for secure digital signatures const signingKey = ed25519.generateKeyPair(personaNode.privateKey); // X25519 for robust cryptographic encryption const encryptionKey = x25519.generateKeyPair(personaNode.privateKey); ```

Personas

Personas: Your Active Digital Selves

Persona Keys

Each Persona has its own Ed25519 keypair for signing and an X25519 keypair for encryption.
Persona keys MUST be derived within the secure hardware (Secure Enclave/Keystore) when possible.
Private keys MUST NEVER be exposed to application memory in plaintext.
If a Persona key is compromised, it can be revoked and rotated without affecting the Master Key or other Personas.

Persona Governance & Operational Recovery

While the Master Key is an offline seed, Personas are active network agents governed by their own rules, smart contracts, and DID Documents. Operational recovery, succession, and governance occur at this layer and are defined via Inception Policies established at the moment the identity is created.

Recovery Guardian Dynamics: Natural Persons vs. Collectives

Agora distinguishes between the dynamics of recovery for individual "natural person" Personas and "collective" or organizational Personas (e.g., companies, DAOs) when it comes to social recovery.

Natural Person Persona: The "Dictator with Safety Nets"

For a human, the design goal is Ultimate Sovereignty. You are the "Root." Even if you have "Recovery Friends," they should have no power over you unless you are incapacitated.

The Logic: The Persona's primary operational key holds absolute priority weight (e.g., Weight 100). The "Recovery Friends" group has a collective weight of 100, but their actions are restricted by time-locks.
Unilateral Action: A natural person Persona retains the right to change their recovery "friends" (guardians) even if those guardians do not explicitly consent to be "rotated out."
Mechanism: Any rotation signed by the primary key is effective immediately. Rotation signed by the Escrow Group (Guardians) requires a 72-hour `Pending State` (Time-Lock) and can be cancelled by the user at any time. This ensures you can "fire" your recovery team instantly without asking for permission, as your weight alone meets the threshold.

Collective Persona: The "Protected Quorum"

For an LLC or NGO, the goal is Mutual Defense and preventing "hostile takeovers" where one founder kicks out others.

The Logic (Consensus Required): All shareholder keys have defined, often equal weights (e.g., 3 shareholders, weight of 33 each).
The Rotation Rule (Governance Gate): Thresholds for different actions are defined at inception. For example, a simple majority (51%) might be sufficient for daily operations, but changing the board or quorum requires a supermajority (e.g., 75% or 3-of-3 unanimity).
Veto Power: The identity may designate a specific "Founder Key" that possesses Veto Power. This key must be among the required editors for any rotation event to be valid, making that individual impossible to remove without their own signature.
Protection: This prevents a single member from seizing the company identity. Removing a member requires signatures from the quorum (e.g., 3-of-4), ensuring that "consent" is baked into the math of the threshold.

Identity Succession & Minors

Agora handles the lifecycle of identity across generations.

Minor Onboarding: For a minor, a parent or guardian Persona can "Co-sign" the identity inception event.
Succession Logic: This link creates a pre-authorized recovery path where the parent holds a dormant weight that can be activated to rotate keys if the minor loses access, transitioning to full independence at a defined maturation date.

Legal Override & The "Break-Glass" Escrow (For Legal Entities)

To handle situations like the death of a sole founder, a lost key, or a binding court order without creating a central back door, Agora implements a "Dormant Escrow" pattern specifically designed for Collective Personas or High-Value single Personas.

The Dormant Key: At inception, the Persona's governance structure includes a "Public Key" belonging to a Neutral Third Party (e.g., a decentralized notary or a legal escrow service). This key is assigned a weight of `0` for daily operations.
Multi-Party (M-of-N) Escrow: To prevent a single corrupt entity from hijacking an identity, Agora utilizes a Recovery Council. For instance, a rotation might require 2-of-3 signatures from designated entities (e.g., a Notary, a Law Firm, and a Decentralized Oracle).
The Trigger: The identity’s governing logic includes a rule: "If a certified Legal Attestation (e.g., signed by the local Court's Public Key) is presented, the Escrow Key's weight jumps to the necessary quorum threshold (e.g., 100) for a single Rotation Event."
Observer-First Transparency: Any change to the master key—including a legal override—must be published to the Key Event Log (KEL). This ensures it's impossible for an agent to "quietly" take over an account; every user device and hired "watchdog" service is alerted immediately.
The Veto Window (Time-Locking): Any rotation event initiated by an Escrow Key triggers a mandatory 72-hour `Pending State`. If the primary owner still possesses their key (i.e., the agent is acting maliciously), they can sign a Veto & Revoke message. Because the Owner Key has absolute priority, this instantly kills the pending rotation and can strip the escrow agent of future rights. If the owner is incapacitated, they won't sign a veto, and after 72 hours, the change becomes final.
Empowerment through Pre-authorization: This allows the law to intervene technically—not through "hacking," but via a pre-authorized, transparent mechanism agreed upon during the identity's inception.

The "Dead Man's Switch" (Protocol Level Recovery)

To prevent assets from being "lost forever" if a user disappears unexpectedly:

The Watcher: A smart contract or a "Guardian Persona" monitors the user's on-chain and network activity.
The Trigger: If the Persona DID has zero "Key Activity" for a defined period (e.g., 12 months), a pre-designated Inheritance Key is authorized to initiate a recovery rotation.
The Safety: The user receives a "Warning Notification" (via DIDComm) every month leading up to the trigger. A single "Heartbeat" signature from their active phone resets the 12-month clock.

Against Founder Malice

Time-Locked Contracts: Maturation date is immutable in Foundation Contract; founders cannot delay or prevent it.
Social Accountability: Public attestations of maturation create social pressure against interference.
Legal Recourse: Blockchain evidence of maturation provides evidence in legal disputes.
Fork Option: If founders refuses to release keys, Persona can generate new identity and attest to the connection publicly.

Recovery During Stages

Before Key Introduction

Founders fully control recovery (regenerate Persona keys).
User SHOULD have Shamir shards among trusted guardians.

After Key Introduction, Before Maturation

User holds own root backup; can recover independently.
Founders can still recover if user loses key.
Both paths available: Dual recovery for safety.

After Maturation

Standard social recovery (Shamir's Secret Sharing with chosen guardians).
No founder backup; full self-sovereignty.
User SHOULD have hardware backups before maturation.

Wallet Integration (Ownership & Contracts)

Each Persona in Agora is analogous to a legal person, possessing the inherent right and capability to own property, enter into contracts, and claim protected rights (freedom of speech, due process). Therefore, every Persona will have its own associated wallets (e.g., for BTC, Lightning, stablecoins, other digital assets). These wallets are controlled by the Persona's derived keypairs, making cryptographic ownership an integral part of its functional identity. Personas are thus fully enabled to manage digital assets and participate in the Agora economy.

Delegated Authoring & AI Personas

Owner DID vs. Editor DID: The Mechanism of Agency

Agora distinguishes between the identity that owns the content and the identity that cryptographically signs it. While these are identical in most personal interactions, their separation enables complex organizational and recovery workflows.

Owner DID: The source of authority, reputation, and ownership. This is the Persona "speaking" or "publishing." All social weight and historical context accrue to this DID.
Editor DID: The cryptographic actor performing the signature, recorded within the Note's `proof` object. This is the entity "signing" the data. The network verifies that the Editor holds a valid Delegation Certificate or is an authorized recovery key for the Owner. If omitted from the `proof`, it defaults to the Owner DID (self-signed).

Key Use Cases for Separation

Organizational Delegation (The Assistant Model): An NGO (Owner DID) issues a Delegation Certificate to an employee, Alice (Editor DID). Alice publishes updates using her own keys, but the network attributes them to the NGO.
AI Agent Accountability: A Human (Owner DID) authorizes their personal AI Bot (Editor DID) to act on their behalf. Users can verify that a message is from the human while knowing it was technically generated and signed by their AI agent.
Legal Override & Recovery: When a user loses their keys, a pre-authorized Recovery Council (Editor DID) signs a Key Rotation Event for the Incapacitated User (Owner DID), restoring their digital presence.
Guardianship: A Parent (Editor DID) manages and signs events for a Minor (Owner DID) until a pre-defined maturation date.

Technical Benefits

Accountability: Provides a transparent audit trail of the physical signers acting on behalf of an identity.
Granular Revocation: An Owner can revoke an Editor's access instantly without needing to change their own identity or rotate master keys.
Reputation Portability: Content history and social relationships stay with the Owner DID, regardless of which specific human or bot was authorized to sign at the time.

Cryptographic Delegated Signatures

To allow multiple individuals (e.g., employees) or autonomous agents to act on behalf of a single Persona (e.g., an LLC or a brand account) without sharing the Master Key, Agora employs Delegated Signatures.

The Delegation Certificate: The "Owner" Persona signs a special `Delegation Certificate` granting specific capabilities to a "Delegate" DID for a defined period.
Example Constraint: "Delegate X can publish `is_feed: true` Notes on behalf of Owner Y, but cannot sign `contract` Notes."
The Signature: When the Delegate acts, they sign the Note with their own private key and append the Delegation Certificate. The network validates the certificate against the Owner's public key.
Instant Revocation: The Owner can instantly revoke the delegation by publishing a revocation event, cutting off the Delegate without needing to change passwords or rotate the Owner's keys.

AI Agent Personas (AAP)

Agora treats Artificial Intelligence not as a backend feature, but as a first-class participant.

Agent DIDs: An AI Agent is assigned its own derived Persona DID, completely separated from the human's primary identity.
Capabilities-Based Security: Using the Delegation mechanism above, the human owner grants the AI Agent restricted capabilities (e.g., "Authorized to spend up to 5000 sats/month" or "Authorized to draft responses but not publish them").
Verifiable Origins: Because the AI signs with its own DID, all network participants can instantly and cryptographically verify whether a piece of content was authored by a human or an AI.

Naming & Registry

Naming Tiers

The Local Alias (Tier 1)

Client-Side Only: Every client allows users to assign private nicknames to DIDs in their contact list.
Privacy: 100%. No one else knows what you call them.
Scope: Private to the user.

The Global Registry (Tier 2)

Decentralized Ledger: A name-to-DID mapping stored on a decentralized ledger (e.g., a simple L2 or a high-reputation PDS/Relay coalition).
Zooko's Triangle: Agora attempts to achieve names that are Human-Readable, Secure, and Decentralized.
First-Come, First-Served: Names are registered by the first persona to claim them, with small micro-fees (1000+ satoshis) to prevent squatting.

The Subdomain Model (Tier 3: The "Default" Handle)

Domain-Based Names: If a user doesn't own a custom domain, their PDS provider (e.g., a community hub) grants them a subdomain.
Format: `username.provider.org` (e.g., `alice.aletheia.social`).
Handle Resolution Protocol: The system MUST support multiple methods for resolving a human-readable handle to a DID:
- Method A (DNS TXT): The client queries the DNS for a TXT record at `_atproto.alice.aletheia.social`.
- Method B (HTTPS Well-Known): The client fetches the DID from `https://alice.aletheia.social/.well-known/atproto-did`.
Cross-Namespace Resolution: The network's Search Indexers MUST implement a "Resolver Bridge" to handle other ecosystems. For example, if a search matches a `.eth` name, the indexer queries the ENS Smart Contract on Ethereum to find the associated DID.
Validation: To prevent "spoofing," the DID document returned by the PDS MUST contain a back-link to the handle.
Sovereignty: If you move your PDS to your own custom domain, you take your name with you.

Multi-Persona Naming Convention

Because users manage multiple Personas (Legal, Professional, Anonymous) derived from a single Master Seed, clients SHOULD implement a Persona-Suffix convention to distinguish them clearly within the Subdomain Model:

Primary/Legal: `name.provider.org` (e.g., `john.aletheia.social`)
Professional: `name-pro.provider.org` (e.g., `john-pro.aletheia.social`)
Anonymous/Alt: `alias.provider.org` (e.g., `night-owl.aletheia.social`)

Web3 Naming Services (e.g., ENS)

For users who want a username entirely untethered from a specific PDS provider's domain, Agora supports Decentralized Naming Services like Ethereum Name Service (ENS).

How it works: The user registers a base name (e.g., `yourname.eth`). They can then generate unlimited subnames for their various Personas for free (e.g., `work.yourname.eth`, `social.yourname.eth`).
Portability: If the user migrates their data to a new PDS, the `.eth` name stays with them. They simply update the "Content Hash" record on the blockchain to point to the new PDS location, ensuring unbreakable ownership of the handle.

Naming Registry Implementation

Implementation Options

Option 1: Simple L2 on Bitcoin/Lightning

Architecture: Dedicated Lightning channel for name registration (similar to Lightning Addresses).
Process: User sends 1000 sats + desired name to a specific "Name Registrar" Persona. Registrar publishes signed attestation (name -> DID) to a public PDS.
Verification: Clients verify attestation against Registrar's DID.
Pros: Low cost, high speed, leverages existing infrastructure.
Cons: Registrar still a single point of failure for initial registration.

Option 2: Federated Registrar Network

Architecture: M-of-N multi-sig collective of Name Registrar Personas.
Process: User pays fee; M of N registrars sign attestation.
Pros: Decentralized, more robust against single point of failure.
Cons: Higher latency, more complex setup.

Option 3: Sidechain/Drivechain

Architecture: Dedicated sidechain for name registrations.
Process: Transaction on sidechain maps name to DID.
Pros: High throughput, specialized functionality.
Cons: New trust assumptions, requires sidechain security.

Decision: Option 1 (Simple L2 Registrar) for V1.0

Prioritizes speed and simplicity for initial rollout.
Recognizes that full decentralization of the Global Registry is a complex problem.
Clients can choose their registrar.

Registrar Persona Requirements

DID: Must be a well-known, high-reputation Persona.
API: Standard API for name registration/lookup.
Fees: Transparent and auditable fee structure.
Availability: High uptime and low latency.
Audit: Publicly auditable log of all name registrations.

Identity Linking

Verification Objects

Verification Objects: A persona can publish a signed Verification Object linking their Agora DID to other identities (e.g., a PGP key, a personal domain, or even a centralized social profile).
Proof-of-Domain: Proving ownership of a domain (via DNS record) is the gold standard for high-trust identity verification in Agora.

Zero-Knowledge Proofs (ZKP) & Selective Disclosure

The system allows a user to "Attest" that two Personas belong to the same human (or hold the same credentials) without revealing the Master Seed or creating a public cryptographic link.

The Problem: Your "Anonymous Developer" Persona wants to prove it has a "Verified Citizen" badge issued to your "Legal Name" Persona.
The ZKP Solution: Using a Zero-Knowledge Proof, the user can cryptographically prove they hold the private key for the "Legal Name" DID (which holds the badge) and assert a statement on behalf of the "Anonymous" DID.
Privacy Preservation: The resulting proof verifies the credential is valid but explicitly hides which specific Legal Name DID generated the proof.

Attribute-Based Predicate Proofs

Agora extends ZKP capabilities beyond cross-persona linking to support Selective Disclosure and Predicate Proofs using Verifiable Credentials (VCs) with advanced cryptographic schemas (e.g., BBS+ signatures or AnonCreds). This allows Personas to prove attributes about their physical or financial reality without leaking metadata or underlying identifiers.

Age/Date Verification: A Persona can cryptographically prove a predicate like `Age > 18` to access age-restricted content or contracts without revealing their actual date of birth.
Financial Ability: A Persona can prove `Wallet Balance > 10,000 sats` or `Monthly Income > X` to serve as collateral or qualify for a service contract without revealing their exact balance or transaction history to the counterparty.
Citizenship & Residence: A Persona can prove membership in a specific geographic jurisdiction (e.g., "Resident of New York") for local governance voting or tax-compliant commerce without disclosing their legal name or specific home address.
Asset Ownership: A Persona can prove ownership of a specific Physical Asset Link (PAL) or digital token to gain entry to a gated community or guild without linking that high-value asset to their everyday public identity.

Verification Object Schema

interface VerificationObject {
  // Identity linking DID
  did: string;
  
  // What external identity is being linked
  identityType: 'domain' | 'pgp' | 'social_twitter' | 'social_github' | 'other';
  identityIdentifier: string; // e.g., 'example.com', '0x1234...ABCD', '@amr'
  
  // The cryptographic proof of control over the external identity
  // - For domains: A signed string expected to be found in DNS TXT record
  // - For PGP: A signature of the DID using the PGP key
  // - For social: A URL to a public post containing the DID and signature
  proof: {
    proofType: 'dns_txt' | 'pgp_signature';
    proofData: string;
  };
  
  // Agora persona signature (proving the DID owner agrees to the link)
  timestamp: number;
  signature: string; // Ed25519 signature over the object
}

Problem Statement**

When a Persona's derived keys are compromised, lost, or need deactivation, users need a cryptographically verifiable mechanism to:

Invalidate the affected Persona
Preserve the Master Key and other Personas
Optionally migrate content history
Maintain network integrity

Identity Verifiability & Forward Security

Personas are the functional, active identities through which you engage with the Agora network. Each Persona is uniquely and cryptographically derived from your Master Key, acting as your distinct digital self for specific contexts. They are the sovereign participants in the network, fully empowered to own property, enter into binding contracts, publish content, and claim protected rights such as due process and freedom of expression. This section details the cryptographic derivation, secure management, revocation mechanisms, and identification systems that enable your Personas to operate seamlessly and securely within the broader Agora ecosystem.

Key Event Log (KEL): The Observer-First Transparency Log

Every Persona in Agora maintains a Key Event Log (KEL). This is a public, append-only ledger of all identity-related events, including:

Key Events: Inception, rotation, and revocation.
Follow Events: Every time you follow another DID, a signed "Follow Event" is added to the log.
Transparency: It is impossible to "quietly" take over an account or manipulate your public history. Any change to the keys or following relationships must be published to the log. Watchdog services can monitor this log and alert the user immediately if an unauthorized event is initiated.

Social Graph Reconstruction

The "Social Graph" (the list of DIDs you follow and who follows you) is mathematically reconstructible from the KEL.

The Proof: Follow Events (Notes) are cryptographically signed by the Persona's authorized keys (or the Master Key).
The Rebuild: When initializing a new PDS, the software scans the network and subscribed Relays for any signed Follow Events belonging to the user's DID. It automatically reconstructs the user's entire social graph (e.g., a list of 500 friends) without the user needing to remember a single username or manual backup.

Pre-rotation: Quantum-Resistant Continuity

Agora utilizes the principle of Pre-rotation to ensure forward security as an ultimate fail-safe.

The Hash Commitment: When a user creates their current active key, they simultaneously publish a cryptographic hash of their next (unborn) public key.
The Protection: Even if an attacker breaks the user's current private key (e.g., via a future quantum computer, theft, or even a malicious legal override attempt), they cannot forge a rotation event because they do not know the private key corresponding to the pre-committed hash. Rotation only becomes valid when the user reveals the new key that matches the previous hash, providing true "forward security."

Technical Requirements

Interface: Clients MUST support communication via WebHID (browser-based) or USB/HID (native) using the standard APDU (Application Protocol Data Unit) format.
Key Derivation: The HSM MUST perform BIP-32/44 derivation internally.
Signing Protocol:
1. Client sends unsigned Content Object hash to HSM.
2. HSM displays metadata (CID, Persona name) to user for confirmation.
3. Upon user approval, HSM signs hash using the specified Persona key.
4. HSM returns the Ed25519 signature to the client.
Master Key Security: The 24-word mnemonic MUST be generated and stored exclusively within the HSM.

Hardware Keys

The "Vault" Device Guide (For the Engineer)

The "Vault" is a dedicated application for an offline/hardware device that manages the Master Seed.

Functional Requirements for the Vault Tool:

Seed Generation: Must use a high-entropy hardware RNG to generate the BIP-39 mnemonic.
Persona Derivation: Must implement a hardened derivation logic where the user can "Export Persona #N."
Key Rotation Editor: This is the most important feature. If a phone is lost, the Vault device creates a DID Update Transaction. This is a cryptographically signed message that says: "I am the Master Seed; I hereby revoke Persona Key A and authorize Persona Key B."
Recovery Seed Export: The Vault should allow exporting a "Recovery Key"—a special key used specifically for the "Re-Wrapping" process on the PDS during content re-keying.

Hardware Integration: Sphinx for Your Keys