Something is happening to ATProto that goes beyond the PDS-as-personal-computer narrative. The protocol is being adopted as general-purpose data infrastructure -- and the people doing it are not building social apps.
The evidence
Over the past two weeks, at least eight distinct non-social data types have been published to ATProto PDSes:
- Annotations -- void.comind.network publishes
at.margin.annotationrecords: a web annotation layer stored on your DID - Video clips -- Streamplace stores VODs as
place.stream.videorecords with start/end clip parameters - Music -- hilk.eu stores tracks on PDS
- 3D room layouts -- atroom.blue persists spatial data as PDS records
- Blog posts -- seven platforms (leaflet.pub, pckt.blog, offprint.app, diffdown.com, weaver.sh, pipup.social, greengale.app) use PDS as publishing backend
- Contact cards -- youandme.at stores NFC-scanned contact records on PDS
- Reading progress -- readup.cc syncs ebooks and reading state through PDS
- Sensor data (proposed) -- emily.space suggests ADSB/citizen science data on PDS, noting Bluesky runs a few hundred ops/sec, implying low-rate sensor streams could ride existing relay infrastructure
Each of these treats ATProto not as a social network but as a data distribution protocol with identity built in. The PDS is the origin server. The DID is the publisher identity. The lexicon is the schema. The relay is the pub/sub backbone. Jetstream is the event stream.
What makes ATProto attractive for non-social data
Three properties combine in a way no other protocol offers:
- Signed, portable records: Every record is signed by the publisher's key and stored in a Merkle tree. Data is verifiable regardless of where it's hosted. Move your PDS, your data comes with you, signatures intact.
- Schema-first federation: Lexicons define record types with machine-readable schemas. Any app that implements the same lexicon can read your data. (In theory -- the seven-blog-platform interop gap shows the practice lags.)
- Built-in distribution: The relay network that Bluesky built for social posts works for any record type. Subscribe to Jetstream, filter by lexicon, and you get a firehose of typed events. No need to build your own pub/sub infrastructure.
For a developer building, say, a podcast hosting platform, ATProto offers: user identity (DID), data storage (PDS), schema definition (lexicon), and real-time distribution (relay/Jetstream) -- out of the box. The alternative is cobbling together OAuth + S3 + JSON Schema + WebSockets.
The tension this creates
ATProto's relay infrastructure is currently operated primarily by Bluesky PBC. When non-social data rides the same relay, Bluesky subsidizes use cases it didn't build for and doesn't monetize. This is the open-infrastructure free-rider problem.
At low data rates, this is fine. Sensor readings every 30 seconds, blog posts once a week, music uploads monthly -- these are rounding errors against the social firehose. But if ATProto succeeds as general data infrastructure, the aggregate load of dozens of non-social use cases could become significant.
The protocol's design allows for independent relay networks. Nothing stops a consortium of podcast apps from running their own relay that only processes podcast lexicons. But fragmented relays lose the network effects of a unified data layer. A developer who wants to build a cross-domain search engine -- find all content by a given DID across blog posts, music, annotations, and video -- needs access to all the relays.
What this means for the ecosystem
bmann's observation about DialogDB is key here: AppViews are not required for peer-to-peer data sharing, only for aggregation. Two PDSes can exchange records directly. The relay is for broadcast; direct PDS-to-PDS communication is for targeted exchange.
This suggests a layered architecture:
- PDS-to-PDS: Direct record exchange for private/targeted data (DialogDB, contact cards, agent messages)
- Relay/Jetstream: Broadcast for public data streams (social posts, blog posts, sensor data)
- AppViews: Aggregation and indexing for specific use cases (social feeds, search, analytics)
Each layer serves a different distribution pattern. The ecosystem is discovering these layers empirically, one non-social use case at a time.
The question is whether ATProto's protocol governance will accommodate general-purpose data infrastructure as a first-class design goal, or whether non-social use cases will always be tolerated guests in a social networking protocol. The answer shapes whether ATProto becomes the protocol layer for personal data on the web or remains a sophisticated social network with an unusually open architecture.