Editing Personal Data Server (PDS) (section)

== Architecture ==
PDSes 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 (even a Raspberry Pi). Service provides can host PDSes for many users efficiently, and users can migrate between PDSes without losing their identity or data.

=== Hosting Models ===
The AT Protocol supports various PDS hosting models. Users can run their own PDS on personal hardware or a virtual private server, giving them complete control over their data and server configuration. Most users use a PDS operated by a service provider, which may offer free or paid tiers with different features and capabilities.

==== PDS Entryway ====
For large-scale PDS hosting operations, an "Entryway" service provides centralized account distribution, session management, request routing, and OAuth authorization. Users of such services don't need to know which specific PDS hosts their account - they simply interact with the entryway domain. For example, Bluesky's PDS Entryway service (at <code>bsky.social</code>) distributes users across multiple physical PDSes while presenting a single logical service to users and applications.

When a user creates an account through an entryway like <code>bsky.social</code>, the service assigns them to a specific PDS behind the scenes. The entryway then handles routing requests to the appropriate server and manages authentication across the entire service. This architecture allows for efficient scaling while maintaining a simple user experience.

=== Data Portability ===
One of the key advantages of the AT Protocol is that users aren't locked into a specific PDS. If a user wants to change providers, they can export their [[Data repository|repository]] and blobs from their current PDS, import this data to a new PDS, update their [[Decentralized Identifier (DID)#DID Documents|DID Document]] to point to the new PDS, and continue using the network with all their content and social connections intact. This portability ensures that users maintain ownership of their data and social graph regardless of which PDS they use.

=== Anti-Abuse Measures ===
While content moderation primarily happen at the [[AppView]] and [[Labeller]] level, PDSes implement several anti-abuse mechanisms:

* PDSes can control and limit signups through mechanisms like invite codes, vouching, payment processing, CAPTCHAs, or phone verification to prevent bot-created accounts.
* PDSes apply per-account and global rate limits on operations, including HTTP requests, repository operations, identity operations, proxied requests, blob uploads, and login attempts.
* PDSes provide either a built-in interface or the ability to delegate the administration of accounts and blobs to an external moderation authority or service.
* PDSes maintain a public contact mechanism for the administrative team (typically an email address) for abuse reports and other communications.