Post

The #ATmosphereConf last weekend was 🔥🔥🔥 One amazing breakout was on E2EE Messaging—a topic I’m passionate about bringing to life on ATproto. To align the community, I wrote a vision paper on E2EE Messaging for ATproto. Check it out and let’s push this forward together!👇 whtwnd.com/boscolo.co/3...

whtwnd.comA Vision for End-to-End Encrypted Messaging on ATproto | chrisbA Vision for End-to-End Encrypted Messaging on ATproto End-to-end encrypted (E2EE) messaging built on ATproto could become the open, decentralized alternative to WhatsApp—free from lock-in, surveilla...

13 reposts58 likes

We'd love to be a part of that working group, we've done quite a bit of thinking here and really aligned with all of your principles and goals - as well as our latest updates with Passkeys allows us to work across any DIDs and networks.

@expede.wtf what are your thoughts on making a derivative version of MLS that replaces TreeKEM with BeeKEM? For human-to-human messaging BeeKEM group size align more with SMS/Signal/WhatsApp use cases than MLS goals. Is the BeeKEM code base suitable for this? Do you know anyone working on this?

The big difference is that BeeKEM can handle concurrent updates *to causally consistent data* but also you can never delete op history. Its perf also smoothly degrades with # concurrent updates, roughly O(concurrent + log memberCount)

Thanks @expede.wtf! There is a real tension in the community—that not everyone sees yet—between the desire to stick with MLS due to it being an IETF standard with open source reference libraries like OpenMLS, and the desire to use a protocol that doesn't introduce centralizing forces to ATproto.⚖️

IMO with PDSes, even federated, you could use stock MLS in a meaningfully decentralized way. As you say: it closes the door on some features by forcing changes to happen only when online, which is a bummer (no local first or P2P networking in the woods)