Hey folks, thought I’d write up a post containing a question I first posed over on bsky a few weeks ago regarding service proxying and spaces.
Note: this post mentions the bluesky microblogging modality a lot - other modalities will encounter this, but the bulk of my focus day-to-day is bluesky
As it stands, the Bluesky app (+forks), and (all?) non social-app Bluesky clients use service proxying through the PDS to make calls to the AppView - this happens for both public data (ie getPostThread, etc), and the current ‘AppView local’ private data (drafts and bookmarks).
For anyone not familiar, I work on Parakeet, which is a ground-up Rust reimplementation of the Bluesky AppView. I was looking through the permissioned data proposals to try get a very experimental private data implementation working in it. The thing that jumped out to me was that syncing private data seems to rely on having oauth credentials - this is no issue when the frontend is issuing reads/writes directly (like for a hypothetical preferences space), as they will hold the token. In the current client stack using service proxying, however, the AppView doesn’t hold oauth tokens that it can use to turn into space credentials to sync data[1].
This has positives and negatives, in my eyes.
- Firstly, it would mean migrating clients[2] over to oauth’ing against AppViews[3] and issuing direct XRPCs to that, instead of going through the PDS - I’m concerned that this binds clients and AppViews together (but this is an argument to be made someplace else).
- My main concern is that it cuts AppViews that only use service proxying off from touching permissioned data - given how likely it is that drafts, bookmarks, mutes, and preferences would be migrated over, I think this is an issue and a step back (albeit in theory - it’s not like I can sync mutes from bluesky to blacksky without active client assistance at the moment).
- Then again with how, for example, Witchsky works currently - where the user can arbitrarily switch their AppView endpoint - doing anything but binding the client and backend doing the syncing could mean that the space function for controlling allowed oauth clients is moot. This is not what we want.
Anyways, I thought I’d bring it up and see, as I couldn’t see anyone else had asked about this yet.
Technically, the client could push a credential back to the AppView with an XRPC call. This is probably not a good idea! [4] ↩︎
or, those that want to support spaces ↩︎
and there’s quite a chunk of migration work there too! ↩︎
It also means that they can’t continuously sync but this i not why this is a bad idea ↩︎