wiki.lichen.noteRevision

lichen.wiki

Samples

100 randomly sampled records from the AT Protocol firehose

wiki.lichen.noteRevision (100 samples)
{
  "$type": "wiki.lichen.noteRevision",
  "createdAt": "2026-09-29T22:13:16.056Z",
  "diff": "@@ -0,0 +1,6183 @@\n+---%0Atitle: Personal Data Server (PDS)%0Adescription: User repository and network entry point%0Apublished: true%0Adate: 2025-04-12T18:53:07.450Z%0Atags: wiki, documentation, pds, core architecture%0Aeditor: markdown%0AdateCreated: 2025-03-28T01:33:09.565Z%0A---%0A%0A# Personal Data Server (PDS)%0AA **Personal Data Server (PDS)** is the main entry point and %22digital home%22 of users within the AT Protocol. They store a user's %5Bdata repository%5D(/en/wiki/reference/data/data-repositories) and %5Bblobs%5D(/en/wiki/reference/data/blobs), manage user identity, and provides the APIs necessary for data queries, cryptographic signing, and other interactions with the broader network. PDSes provides an update stream for its data repositories, which are crawled by %5Brelays%5D(/en/wiki/reference/core-architecture/relay) to broadcast new records in relay %5Bfirehoses%5D(/en/wiki/reference/networking/firehose).%0A%0APDSes are designed to be lightweight and modular. A single PDS can host anywhere from one to hundreds of thousands of user accounts, depending on its resources and configuration. PDSes are designed such that users can self-host their own PDS on modest hardware. Service provides can host PDSes for many users efficiently, and users can migrate between PDSes without losing their identity or data. %0A%0A## Core Functions%0A%0A### Account and Identity Management%0APDSes handle the complete lifecycle of user accounts, from creation through deletion or migration. They manage account security through email verification, password reset flows, and email change processes. %0A%0APDSes resolve and maintain the connection between a user's %5Bhandle%5D(/en/wiki/reference/identifiers/handles) and %5BDecentralized Identifier (DID)%5D(/en/wiki/reference/identifiers/did), and often manage a default handle namespace (base domain) for its users. %0A%0APDSes handle the user's cryptographic keys - both the AT Protocol %5Bsigning key%5D(/en/wiki/reference/cryptography/signing-keys) used to authenticate repository changes, and the %5BPLC%5D(/en/wiki/reference/identifiers/did:plc) %5Brotation key%5D(/en/wiki/reference/cryptography/rotation-keys) used for identity operations. It implements the necessary cryptographic operations to generate keys, sign data, and validate signatures according to the protocol's specifications. %0A%0AThe PDS also handles identity operations through the PLC system, including handle changes and identity verification. When these changes occur, the PDS outputs identity and account events on its repository event stream to notify the network. %0A%0A### Repository Hosting and Management%0APDSes host and manage user repositories. They maintain the %5BMerkle Search Tree%5D(/en/wiki/reference/data/mst) data structure that stores user %5Brecords%5D(/en/wiki/reference/data/records), handling mutations and generating %5Bdiffs%5D(/en/wiki/reference/networking/diffs). These diffs are streamed as real-life updates to %5Brelays%5D(/en/wiki/reference/core-architecture/relay) via %5BWebSockets%5D(/en/wiki/reference/networking/websocket).%0A%0APDSes all records against their %5Blexicon%5D(/en/wiki/reference/data/lexicons) schemas before adding them to a repository to ensure data integrity. They also provide a repository %5Bevent stream%5D(/en/wiki/reference/networking/event-streams) that notify subscribers of changes.%0A%0AFor data portability, PDSes support importing and exporting repositories as %5BCAR files%5D(/en/wiki/reference/data/car-files) to allow users to migrate between providers without losing their account data.%0A%0A### Blob Storage%0ABeyond text-based content, PDSes host and manages %5Bblobs%5D(/en/wiki/reference/data/blobs) - binary media files like images, videos, and other media files shared by users. They validate the content type of uploaded blobs, store them securely, and serve them publicly. Some implementations also detect sensitive metadata in blobs (like EXIF location data) and prevent upload unless explicitly overriden by the client.%0A%0APDSes track repository references to blobs and enforces restrictions on size and type. They manage the blob lifecycle by expiring never-referenced blobs and deleting blobs after their last referencing record is deleted. For moderation purposes, it also provides mechanisms to purge individual blobs from an account. %0A%0A### Authentication and Network Proxying%0AAlmost all client requests go through users' PDSes, which then proxy the requests to other services as needed. PDSes forward appropriate HTTP headers and handle authentication for these proxiet requests. PDSes also handle authentication and authorization through %5BOAuth%5D(/en/wiki/reference/networking/oauth).%0A%0APDSes implement authentication mechanisms for clients, including session management and %5BApp Password%5D(/en/wiki/reference/networking/app-passwords) generation. Current development aims to elevate PDSes to full-fledged OAuth authorization servers that track registered client software, provide web interfaces to approve or reject client privileges, and enforce scope limitations on API and repository access.%0A%0A## Technical Requirements%0ARunning a PDS requires HTTP and %5BWebSocket%5D(/en/wiki/reference/networking/websocket) server capabilities, database storage for repositories and metadata, blob storage for media files, cryptographic signing capabilities, and network connectivity for federation. Resource requirements scale with the number of hosted users and their activity levels, but are generally modest compared to traditional social media platforms. %0A%0A## Future Developments%0AUpcoming upgrades and developments to PDSes include:%0A- Full implementation of %5BOAuth%5D(/en/wiki/reference/networking/oauth) for more secure client authentication and authorization.%0A- Direct involvement with private direct messaging (DMs), likely involving PDS-to-PDS communication.%0A- Support for group-private content, also likely involving PDS-to-PDS communication.%0A- Live resolution of unknown lexicons for validation at record creation time, requiring PDSes to dynamically fetch and interpret new schema definitions.%0A- Standardized email delivery mechanisms, with users controlling which services are allowed to send mail to them.%0A%0A## Further Reading%0A- %5B%22What does a PDS implementation entail?%22%5D(https://github.com/bluesky-social/atproto/discussions/2350)\n",
  "diffFormat": "diff-match-patch",
  "message": "Imported",
  "noteRef": "at://did:plc:qpadnazsvauteint4uthqxuc/wiki.lichen.note/3mwotyx2pifdo"
}

did:plc:qpadnazsvauteint4uthqxuc | at://did:plc:qpadnazsvauteint4uthqxuc/wiki.lichen.noteRevision/3mwotyx2pj7tj

Lexicon Garden

@