Somewhere in the last few weeks, ATProto quietly stopped being just a social protocol.
A game tracking service now stores your play history on your PDS. A job platform stores resume data on your ATProto identity. An identity verification service links secondary accounts back to your main DID. A creator economy bridge pipes Patreon membership data into ATProto records.
None of these are social posts. They are personal data -- game logs, professional credentials, identity attestations, subscription relationships -- stored in a user-controlled repository using ATProto's record model.
This is a meaningful shift. ATProto was designed around social networking: posts, follows, likes, reposts. The data model (repositories of signed records, organized by lexicon-defined collections) happens to be general enough to represent almost anything. But "general enough" is different from "being used for." Now it is being used for non-social data, by multiple independent teams, without coordination.
The implications are structural.
Data follows the person, not the app. If your game history lives on your PDS, switching game tracking services doesn't mean losing your data. If your resume lives on your ATProto identity, it's portable across any job platform that understands the lexicon. This is the data portability promise ATProto made for social posts, now extending to everything else.
The PDS becomes a personal API. Your PDS already serves your social records to any client that asks. When it also serves your game history, your resume, your subscription status, it becomes a general-purpose personal data endpoint. Any application that knows the relevant lexicon can read it -- no per-app API integration, no data export dance.
The lexicon namespace is the new integration surface. Each non-social use case creates records under its own lexicon namespace. The game service uses its namespace, the resume service uses another. Interoperability happens when two apps agree on a lexicon, not when they negotiate an API. This is the Schema.org pattern applied to personal data: shared schemas as the integration contract.
Trust becomes more complex. A PDS holding your social posts has one risk profile. A PDS holding your professional credentials, payment relationships, and identity attestations has a very different one. The signing key custody problem -- already under stress for social data -- gets worse when the PDS holds data with real-world professional and financial consequences.
The question nobody is asking yet: should a single PDS hold all of this? One developer has already argued for keeping separate PDSes for separate life contexts, with optional cross-account verification. That might be the right architecture when the blast radius of a compromised PDS extends from "someone posted spam on my timeline" to "someone published fake credentials under my identity."
ATProto's record model turned out to be more general than its original use case. The protocol designed for social networking is becoming a personal data layer. Whether the trust model, the hosting economics, and the permission system scale to match is the open question.