There has been on and off discussion for quite a while framing the PDS as a user-agent and by that imagining what it would look like if it had some kind of extensible plugin system (likely WASM) that end-users could use to add their own functionality beyond managing atproto data. Think about plugins for hosting a website, WebRTC signaling, CRDT sync servers, file sharing, etc. @whenthetimeca.me calls this idea server user-agents. I think it could be worth having a thread that documents previous discussions and co-mingles future ones as these ideas are explored.
16 Likes
Love this and really want this future. @easrng.net also brought this up a while ago in response to Paul’s post about trickiness with read-after-write consistency:
“the PDS has Bluesky business logic baked in. Not only is that a conceptual violation of the PDS – which is supposed to be generic – but it’s an option that’s not available to every app.”
why not extend the protocol to support that in a generic way?
ex. you upload a wasm blob and send a `atproto-middleware: bafk…` header. service proxying happens as usual but the wasm blob can augment the response with queries from the PDS
3 Likes
Ya read-after-write is a good example (although I don’t necessarily see this as problem for the PDS to solve)! Another case of that is that PDS has logic hardcoded in that deduplicates app.bsky.feed likes/reposts/follows.
1 Like
Extension systems also need good directories, which we now have a stable example of in EmDash’s atproto-based plugin registry.
https://github.com/emdash-cms/emdash/blob/main/rfcs/0001-plugin-registry.md
This RFC defines a decentralized plugin registry for EmDash. The registry uses a FAIR-derived package schema on an atproto-native transport.
- Authors publish package and release records to their Atmosphere account’s Personal Data Server (PDS).
- The publisher’s PDS stores plugin bundles and listing images as atproto blobs by default. A release can name an external HTTPS URL as an alternative source.
- Aggregators subscribe to the atproto firehose and index eligible records for discovery.
- Installing sites resolve the signed records, retrieve artifacts from an advertised record-scoped cache, the publisher’s PDS, or the external URL, and verify every artifact checksum.
That general pattern of sandboxing is described here:
Extensible Software in the age of LLMs | Jeremy Morrell
Solid core + capability-based sandboxes + LLMs = Users with superpowers
@trezy.codes is also on the forefront of extensibility with HappyView which supports WASM plugins.
4 Likes
I’m very interested in this. I was recently looking into creating module / web hook entryway components to make some things like account creation and authentication pluggable. I think wasm or some sort of scripting system would be great.
1 Like
FWIW, I’m in the depths of this right now as I build HappyView v3. Everything is becoming WASM plugins. I’m still working on my registry, but it’s heavily based on the EmDash registry with solutions for some of the issues they’ve deferred (like plugins deletion).
I’m curious, tho: are we just talking about extensibility for the reference PDS? Or a more general extensibility layer that any PDS can take advantage of? Because it sounds like (and I’m very interested in) the latter, but that would be a very big lift. We’d need to define a pretty extensive ABI for PDS software to conform to.
4 Likes
I think building a general extensibility layer is a better goal as ideally the extensions could provide means of interoperability for different implementations. For e.g. a Distributed Hash Table extension that could allow data to be stored “p2p” between multiple PDSs of different implementations, which is something that’s been on my mind for a while now.
FWIW here are some other extensions I think could be cool:
- personal cloud service (something like Nextcloud for users of a PDS)
- MCP server for user details, maybe even A2A interactions for agents bound to a user’s DID
- Mastodon server style moderation tools for users on a PDS
3 Likes