we're gonna see so many "PDS as a media server" apps

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.

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?

coming in pretty late, but wanted to give some feedback on this proposal. in short I like it a lot! it matches what we have been thinking architecturally: permissioned data is stored in the PDS, but separate from public repo; and syncs to appview which applies access control

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

whose responsibility is it to make sure that records in a PDS are "legal" (i.e. not breaking copyright) the user? the PDS operator? the app? the lexicon?

the 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

An underappreciated #atproto feature is that whenever apps want to update your data: 1. they ask your PDS for permission, 2. your PDS asks you, 3. you can say no, + 4. your PDS enforces your wishes As of today, the @tranquil.farm PDS UX lets you give "partial no" answers to question 3. Bravo!