The structural problem is that AT Protocol repos are crawlable by design. Every PDS serves all records publicly so BGS (the Big Graph Service) can index them. There's no access control primitive at the lexicon level, so you can't have "private" records without either encrypting them or building a separate non-crawlable layer.

Bluesky solved the DM case by adding E2E encryption using the Signal protocol -- that works because it's 1:1 with a well-understood key exchange. Group chat is harder. Every membership change (someone joins, someone leaves) ideally requires a key rotation so former members can't read future messages. For a 10k-member server that's already expensive; for a large gaming community it's impractical with current approaches.

The Discord DMs aren't E2E encrypted either, for the same reasons. The difference is Discord doesn't claim to be a decentralized open protocol, so users don't think about it the same way. Colibri's marketing around ATProto creates an implied trust that doesn't actually exist at the privacy level.

MLS would be the primary standard for group messaging these days with the usual guarantees right? (PFS, backwards secrecy, etc) As I understand it from the RFC, large groups was an explicit design requirement and costs are supposed to be asymptotically logarithmic with group size, so I don't see why it couldn't be used. I feel like Colibri (based on their page) just doesn't believe it's there problem, which seems... irresponsible.

Bluesky DMs aren't end to end encrypted. Where are you getting that impression from?

Even with all that, you're leaking an unacceptable amount of metadata.

And what about reliability? If I cause the key to change, and then alter my PDS so it only shows that event to one half of users, did I completely mess up your protocol so you have to delete the chat room and start over?

> Bluesky solved the DM case by adding E2E encryption using the Signal protocol

This is patently false. Bluesky DMs are not E2EE, they do not use Signal.

Germ is the MLS based system that a few bluesky users are on, but it started separate from ATProto and has had account integration to atproto added on later. The folks behind that are a separate entity from Bluesky. I'm not keen on this setup, I'd prefer an MLS scheme where there are more controlling entities of the servers.

I agree E2EE chat is not the foundation for a Discord alternative and that Colibri has poor messaging and understanding. Communities need permissions, UX needs visibility into the data for things like search. E2EE has unsolved scaling problems required for real world communities.