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
Ultimately we decided that it was just better to invest in making applications easier to build and move between, and inverting the flow so that it goes to the app server instead of proxying through the PDS was one of those simplifications
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
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
Are there plans right now to migrate social-app to this BFF setup where it would OAuth to the app server directly and the server would write to the PDS instead of the proxying? Or is this just something "maybe someday"?