Comparing Solid to ATProto PDS

Hi! Sorry if this is off topic, but I haven’t been able to find anything online directly comparing the two.

Both technologies seem to be built around the idea of users having control of their data which applications connect to.

Does anyone have experience with atproto that can speak to the different tradeoffs they’ve made and where each choice would be more appropriate?

Thanks!

1 Like

I haven’t used ATProto, but the most obvious difference from what I’ve read is that everything in ATProto is public. Private messages in Bluesky, for example, are implemented using a different technology and these are not stored in the PDS.

So that would already be a pretty clear distinction, if you need private data, ATProto is not the best solution. Indeed, I would say anything that is not social in nature is not well suited to ATProto (others may disagree). Conversely, and even though Solid has “social” in its name (SOcial LInked Data), I think Solid is better for personal and private applications. In practice, social apps are being built with things like ATProto or ActivityPub (Mastodon, Pixelfed, etc.).

3 Likes

note that in ATP, a PDS holds 1 or more keys per user, but uses them to sign all data before it gets pulled from relays and appviews. there is no stable interface for apps to request access to those keys, request signatures from them (for verifiable presentations or for arbitrary digests/inputs), private data, etc.

there is a lively (somewhat optimistic) developer community building on atproto that have hacked together “private data” capabilities by forking the PDS and adding private buckets, etc., but there is no forward-commitment to these still working if ATProto is iterated in any way, or if bsky the app’s interface to PDSs change… so it’s kind of “pending community governance” whether PDSs will ever (in a stable way, much less standardized way) allow:

  • arbitrary signing (here is a thing, sign over it)
  • protocol-structured signing (if you have a VC that matches this query, sign a VP over it)
  • custom DID doc properties (i.e. additional keys and endpoints)

For all I know, this post will age like fresh milk and all these interfaces will get stabilized (and, ideally, standardized!) by year’s end. But until they do, building an ATP-enabled Pod or a Solid-enabled PDS will be… a lot of work.

3 Likes

I very strongly disagree. To note some of the existing uses of Solid which go way beyond personal information - the Solid Resources Catalog, a number of medical apps, enterprise apps in architecture and other domains, environmental monitoring apps, INRIA’s work on local food chain resources, transportation apps and many more. These are social but are not social media, two very different things.

3 Likes