Decentralized Web Node (DWN)

A DWN exposes a standardized REST API for all data operations, abstracting the underlying storage mechanism. This allows any identity to interact with any node regardless of the vendor.

• CRUD operations for records
• Query mechanism for semantic discovery
• Subscription protocol for real-time sync

Data is organized into decentralized threads, which are logical partitions of records owned by a DID. Each thread is an independent, encrypted data stream.

• Records are immutable append-only entries
• Threads group records by context (e.g., chat, photos)
• Permissions are scoped per-thread using capability-based authorization

DWNs form a mesh network where nodes can act as relays for offline identities. Data is replicated across multiple nodes to ensure high availability.

• Sync protocol resolves conflicts using CRDTs
• Relay nodes store encrypted data for mobile devices
• No central coordinator required for replication

Access control is enforced through cryptographic capabilities rather than access control lists. A DID grants a permission by signing a delegation object.

• Invocation to execute a specific action
• Delegation to grant permissions to another DID
• Revocation by publishing a revocation record

DWNs use protocol definitions to standardize how applications interact with data. A protocol defines the schema, roles, and actions for a specific use case.

• Role definitions (author, recipient, verifier)
• Action contracts (send, read, delete)
• Schema enforcement for structured data exchange

Since the DWN specification is open and identity is rooted in portable DIDs, users can migrate their encrypted data between any compliant node provider.

• Zero switching cost between providers
• End-to-end encryption ensures provider cannot read data
• Self-sovereign identity decouples storage from authentication

The globally unique, persistent identifier used to address a specific DWN and its owner. Unlike a URL tied to a vendor, a DID is resolved through a DID Document to discover the node's service endpoints and public keys, establishing the cryptographic root of trust without a centralized registrar.

A semantic synonym for a DWN in many implementations. An Identity Hub acts as a personal data store that allows an identity owner to securely manage, encrypt, and replicate their Verifiable Credentials across multiple nodes. It provides the semantic replication layer ensuring data availability even if a specific edge node goes offline.

The secure, asynchronous, peer-to-peer messaging protocol used for communication between DWN controllers. DIDComm leverages end-to-end encryption based on decentralized keys, enabling private data relay and exchange between nodes without relying on a centralized message broker or vendor-specific API.

The primary data payload stored and managed within a DWN. A VC is a tamper-evident, cryptographically verifiable digital credential conforming to W3C standards. DWNs provide the storage and relay infrastructure for holders to manage these credentials and execute selective disclosure to verifiers.

The system that mediates the creation, verification, and revocation of identifiers and credential schemas. While a DWN stores the actual data, it relies on a Verifiable Data Registry (such as a distributed ledger) to anchor DID Documents and Revocation Registries, ensuring the global state is consistent and auditable.

A layer-2 protocol for scalable, blockchain-agnostic DID management that batches operations into anchored files. Sidetree enables DWNs to manage millions of identifiers efficiently by anchoring only compressed batches to a public ledger, dramatically reducing the cost and throughput limitations of direct on-chain storage.