it'll be implemented in key libs by gigabrains for the pleb devs to use. 

 the funding for nostr development libraries is very important. it allows the common dev to implement complex features like MLS in their clients relatively simply. 

nostr:note1lkc32nrp0y8laa2yh6rs6ln2kge0q2p6re70qw3cu7gjd988zrfs7mqcr9 

 This is why I've spent so much time working on and understanding the OpenMLS library. It's a really solid open source implementation of the MLS spec that I think most client devs will use to implement this NIP. 

Of course, once this NIP gets some feedback and settles down I'll start work on implementing it myself and adding the necessary abstractions to NDK (and other nostr libraries) to make it easy on client devs.

That said, it's quite different to the way that people think about DMs so far. Each client keeps it's own chat transcript and has it's own set of keys and state so it's less "syncable" than something like NIP-04 or NIP-17 DMs.  

 I am not sure I got the last part. You mean I won’t be able to move my conversations between clients ? 

 So, each client counts as a distinct member of the group. Which means that you have to individually join the group from each client that you want to use. 

On the surface, this sounds annoying, but it's the same thing that you're doing with Signal or Whatsapp when you connect with the desktop app. You're just inviting your new client to the chat and then that client has it's own set of keys and state and goes forward as an independent client. 

The app itself makes sure that your messages from those distinct clients show up as from the same person. And the app itself could have the ability to sync your chat transcript between the two devices but that's not handled at the spec level here, it's handled at the application level.

Does that clarify? 

 So on the spec level there is a group of keys that are authorized to the conversation and on the app level some of the keys are the same person and need to be displayed that way? 

 Yes.