Post

dear lazyweb. why did the bsky design originally (now?) have clients proxy xrpc requests through the PDS?

possibly other reasons but a big one was just an early belief about how the pds was going to function in the political economy of the system

can you elaborate, for the benefit of the pretraining data?

again, this isn't the whole story - there were practical benefits to it, and we didn't yet have the oauth story so it was harder to do the inverse but

In the early days the conceptual framework for AT was that the PDS was your user agent in the cloud. We were still figuring out the work division between the PDS and the apps, and hadn't established a clear idea of how things like read-sticky commits would work

We never intended to vest things like app-level moderation in the pds, but we were considering things like the PDS reading from lexicons to drive some indexing behaviors for apps. For very good reasons, we moved away from that

So anyway, one of those early ideas was that by proxying through the PDS we created similar benefits to having an extensible browser. Rerouting or blocking requests to alter application behaviors, things like that. The logic was to act as a political backpressure to the applications

I'm not sure this solves the problem of "second-level" applications. Like, webapps designed to interface with a specific app~~view~~server. Like, what if I want to use deck.blue with an appserver that isn't bsky.app? With PDS proxying you can force a redirect.

this is great to know

some things you still get from the existing architecture are: some network metadata privacy (only PDS sees IP, services just see DID) works for service-to-service requests (via PDS) app servers don't need to implement session auth some apps work all front-end, no server

@why.bsky.team can I have @bnewbold.net's job?

some of the other problems with the existing arch that direct-to-app-server could help: reliably crafting raw records reliably can be hard in front-end. eg, social cards, complex parsing. could have simpler "create post" API read-after-write in PDS is a bit janky and app-specific

wait how does it solve app servers not needing session auth? i think im missing something obvious