to reiterate on this, an AppView server should NOT be interposed between the user and the PDS: the client and PDS are in the user sphere of trust, but the service is adversarial. the PDS is the most important write sink and should be primary, since an app can't be trusted to not shut off PDS writes
mary🐇
doesn't mean i shouldn't try. mary.my.id/musings/atproto-and-oauth
Mar 18, 2025 at 7:27 PM
PDS: review existing oauth scopes via connected apps list · Issue #4838 · bluesky-social/atproto
Scenario I want to stay on top of which apps are messing with what in my PDS. To do so, it's not enough to just make a granular Goldilocks decision once per app. (The more apps I use, the fewer...
We probably need to rename the AppView
It should be called an API server, App server, or backend.
Some W users experienced problems today because W was relying on Bluesky’s AppView. When their AppView went down, parts of W went down with it. Our own AppView was already under development and it kept working. So we’ve now switched W over to our own AppView, currently serving verified users only.
I think there could be a genuine use case for PDS proxying and modifying requests lurking with app preferences.
The disconnect between the social filesystem and web pages. - Chris's Corner
blog.chrisshank.me
𝕮 • Chris Shank
A proposal for opening AT URIs
Rehashing this... if the main concern for atproto clients writing directly to the PDS is not having optimistic writes, then I don't get why we'd want to move towards a app server architecture as opposed to a local-first one. Are there other examples when server side computation is necessary?
The politics of purely client-side apps
pfrazee.leaflet.pubthe single most important part of atproto is the PDS as a user-controlled auth and storage layer to which clients can connect directly. death to appviews
Authenticated Transfer Enables Orchestration - nekomimi
blog.nekomimi.pet
