Imagining atproto as a post-app protocol starts with materializing the social filesystem – decomposing apps and their data into materials and instruments. For the time being, this guestbook is a good example where the display element is a material and the sign element is an instrument.

some thoughts on atproto as a post-app paradigm

Every lexicon, every "app" on ATProto is a "yes and" waiting for your contribution to the vision. We're all first party developers.

I love that the design of atproto was in part inspired by big social Kafka and ScyllaDB server backends and @martin.kleppmann.com's Designing Data-Intensive Applications and the community immediately used it to implement thousands of apps with no backend lol

ATProto is a post-app protocol trapped in a world of apps. I can feel it all around the edges of the network.

This is partly why I think atproto needs a more convincing vision about being a post-app protocol. A future where atproto is a bunch of apps and each app governs their own lexicon diminishes a lot of its potential in the long-term.

one thing I really like about atproto is that it provides the infrastructure needed to make open source user apps that actually fucking sync data across devices sorry but the average random hobbyist is absolutely not going to run a user account server for their homebrew todo list app

ooh nice my talk got posted! this is a 30 min whirlwind introduction to atproto through a technical lens, basically building up the stack from DIDs -> repos -> PDSes -> relays -> lexicons -> OAuth -> applications

The killer app of atproto is interop

The ATProto community built a ton of great features and products over the past year. For our next trick, let's mature them into products and businesses.

It seems a fork lies ahead, is atproto a portable database for a bunch of apps or a new type of post-app, social filesystem?