Post

at proto now makes a lot more sense to me, great episode! (But, now that I understand the architecture a bit better, the whole thing sounds wildly inefficient to me. Maybe that's just the cost of decentralization? idk)

What part do you think is inefficient? According to atproto.com/guides/the-a... even a full network relay is relatively cheap and that's with millions of users. I'd even argue that multiple apps using the same lexicons make it much more efficient than alternative designs.

The example Dan gave: a user has 1m followers. How do I query this data? From what I understand, I first need to acquire a copy of the relevant data at given time and store that in my own database, then listen for changes via the firehose stream and apply those to my database. Correct?

This was a nice chat and @danabra.mov has a way of vulgarizing and communicating what atproto is and isn't. Good follow-ups would be discussions regarding the interoperability that the system allows 🧵1/5

(2/5) It's not just about where you host your user's repo (which PDS you use), but you can mix and match any layer of the stack. You can use mu.social with the bsky backend or the skeets app with either that or the Blacksky backend and have similar experiences to bsky.app

(3/5) The above also allowed users of the Skeets app which were using the Blacksky AppView (backend) were not at all affected by the Bluesky outages earlier this year. They could still post, read, interact with all the data in the atmosphere.

“we can just do whatever” (33:05)