some thoughts on atproto as a post-app paradigm

Been thinking about how we could support access-controlled blobs in ATProtocol. Right now, all blobs are public - anyone can fetch them with a CID. But what if we could gate them? #atproto #atdev 🧵

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?

I suspect we’ll see a bunch of apps that leverage atproto’s did:plc identity layer but store data out of band.

new proof of concept: ATProtoCall! video calling over atproto with just static files and no dedicated signaling or streaming infrastructure.

new proof of concept: ATProtoCall! video calling over atproto with just static files and no dedicated signaling or streaming infrastructure.

My take on the "explaining atproto" discourse is that all the UX/filesystem/etc metaphors are still very verbose and that you can explain the same idea in a lot less words: It separates data from apps, so any app can use data from any other app. That fits in a tweet, with other sentences around it.

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.

An ATProto-aware blob proxy! What a sensational idea. github.com/Blooym/porxie