Decentralized Web Node (DWN)

At its core, a DWN functions as a user-owned data repository. It stores verifiable credentials, encrypted messages, and application state in a structured format. Data is organized into collections and records, with access controlled by the user's Decentralized Identifier (DID). This architecture enables data portability and interoperability across different services without relying on centralized servers.

DWNs communicate via a permissioned, encrypted messaging protocol. Applications send JSON-based messages (e.g., CollectionsWrite, CollectionsQuery) to a user's DWN endpoint. The protocol ensures:

• Authentication: Messages are signed by the sender's DID.
• Authorization: Access is granted via explicit protocols and permission grants.
• Reliability: Messages can be relayed through intermediary nodes, ensuring delivery even if the target DWN is offline.

Interoperability is governed by publicly defined protocols. A protocol is a specification that outlines:

• Allowed message types and their data schemas.
• Roles (e.g., author, recipient).
• Data indexing rules for querying. For example, a chat protocol defines how to write and query messages, while a credential protocol defines how to issue and store Verifiable Credentials. This allows any compliant app to interact with the data.

DWNs are intrinsically linked to Decentralized Identifiers (DIDs). A user's DID document contains the service endpoint pointing to their DWN. The DWN itself is controlled by the cryptographic keys associated with that DID. This creates a self-sovereign identity system where:

• The DID is the immutable identifier.
• The DWN is the mutable, user-controlled data plane.
• All data operations are authorized by DID-based signatures.

DWNs enable social apps where users own their social graph and content. A user's DWN can store:

• Profile data (name, bio, avatar).
• Posts and reactions as signed records.
• Follow lists as collections of DIDs. Apps like Bluesky (using the AT Protocol) employ similar concepts, allowing users to migrate their entire social presence between different client applications by changing the relay service for their DWN, not their data.

A primary use case within the Web5 framework is managing Verifiable Credentials (VCs). A DWN acts as a holder's wallet, securely storing VCs issued by organizations (e.g., a driver's license). The user can then present cryptographically verifiable proofs from their DWN to relying parties (e.g., a car rental service). This decouples credential issuance, storage, and verification, eliminating centralized identity providers.

DWNs act as a Personal Data Store (PDS) or vault for sensitive information, giving users granular control. Key use cases include:

• Health Data Interoperability: Securely store and share EHR fragments (immunization records, lab results) with healthcare providers on-demand.
• Data Monetization: Users can grant temporary, auditable access to specific datasets (e.g., fitness data) for research, revoking it at any time.
• Unified Data Access: Aggregate data from various IoT devices and services into a single, user-owned repository.

Instead of relying on centralized cloud servers, dApps can use a user's DWN as their personal backend. This enables:

• Serverless by design: Application state and user data are persisted directly to the user's node.
• Enhanced privacy: Sensitive data never leaves the user's control; apps query the DWN with user permission.
• Data persistence: User data survives even if the dApp's frontend or company disappears.
• Cross-device sync: DWNs synchronize data across a user's devices, providing a seamless experience.

DWNs provide an immutable, owner-controlled audit trail for physical assets and sensor data. This is critical for:

• Provenance Tracking: Each participant in a supply chain (manufacturer, shipper, retailer) can write verifiable event records (e.g., "temperature exceeded") to a product's DWN-based ledger.
• Device Identity: IoT devices can have their own DIDs and DWNs, autonomously publishing tamper-evident sensor readings.
• Auditable Compliance: Regulators or buyers can be granted permissioned access to verify the entire history stored across multiple participants' nodes.

A DWN is a self-sovereign data store that operates as a network participant. Its architecture is built on a few key principles:

• Decentralized Identifiers (DIDs): Each node is controlled by a DID, not a centralized server.
• Event Log: Data is stored as a cryptographically verifiable log of messages.
• Permissioned Access: Data is accessed via explicit grants using Object Capabilities.
• Interoperable Protocols: Nodes communicate using standard protocols like HTTP(S) and WebSockets.

Data in a DWN is organized into Collections and Records, not traditional databases.

• Collections: Logical groupings of related data (e.g., healthRecords, credentials).
• Records: Individual data entries within a collection, each with a unique ID and version history.
• Schemas: Data conforms to JSON Schemas for interoperability.
• Selective Disclosure: Users can share specific records or even portions of records without exposing their entire data store.

All interactions with a DWN occur through signed messages, creating an auditable event log.

• Message Types: Includes CollectionsWrite, CollectionsQuery, PermissionsRequest.
• Protocols: Specific interaction patterns (e.g., a credential issuance protocol) define the sequence and rules for messages.
• State Verification: The current state of any record is derived by replaying its message history, ensuring verifiable provenance.

A DWN can be implemented in various environments, giving users control over their data's location.

• Personal Server: User runs a node on their own hardware (e.g., Raspberry Pi).
• Cloud Hosting: User provisions a node with a hosting provider they choose.
• Mobile/Edge: Light clients can run on mobile devices.
• Interchangeability: Users can migrate their DWN between hosts without losing data or changing their identifier (DID).

DWNs differ fundamentally from other data storage paradigms.

• vs. Centralized Servers: Data is owned by the user, not the application provider.
• vs. IPFS/Filecoin: DWNs are for structured, mutable, queryable data with access control, not just static file storage.
• vs. Blockchain (on-chain): Data is stored off-chain for cost and privacy; only minimal proofs or pointers may be anchored on-chain. The blockchain acts as a trust root for DIDs, not the data store itself.

A Decentralized Web Node is the personal data store for a Decentralized Identifier (DID). While the DID is the globally resolvable identifier (like did:key:z6Mk...), the DWN is the private, user-controlled server where the DID subject's data—such as verifiable credentials, encrypted messages, and schemas—is stored and managed. The DID Document often contains a service endpoint pointing to the owner's DWN.

DWNs are the primary storage and exchange mechanism for W3C Verifiable Credentials. They enable:

• Storage: Securely holding issued VCs in a user's private data store.
• Selective Disclosure: Allowing users to present specific claims from stored VCs without revealing the entire credential or their DWN.
• Credential Exchange: Facinating protocols like Presentations and Issuance through encrypted DWN message protocols.

While both are decentralized data systems, they serve different layers. IPFS is a content-addressed protocol for public, immutable file storage. A DWN is an identity-addressed, mutable, private data store for a specific entity. However, they can interoperate: a DWN might store only a Content Identifier (CID) pointer on IPFS for a large file, keeping the actual data off-chain while maintaining control over the reference.

A service endpoint is a key entry in a DID Document that tells other entities how to interact with the DID subject. For DWNs, a DIDCommMessaging or DecentralizedWebNode service endpoint is declared, providing the network address and routing information. This is how peers discover and establish encrypted communication channels with a specific user's node, enabling the DIDComm v2 protocol.

DWNs don't just store raw data; they store data objects conforming to published schemas. These schemas (e.g., https://schema.org/Person) define the structure of records. The DWN's internal protocol layer enforces that data writes adhere to these schemas and associated permissions. This creates a consistent, queryable data lake for applications, enabling interoperability across different apps using the same user-owned node.

DIDComm v2 is a secure, peer-to-peer messaging protocol built for the DID ecosystem. A DWN acts as the message box for DIDComm. Encrypted messages are routed to a recipient's DWN service endpoint and stored as a data record. The recipient's agent can then process these messages asynchronously. This enables private communication, credential offers, and protocol coordination without relying on centralized servers.