So MLS DMs for nostr need a ciphersuite implemented to use secp256k1, assumedly using OpenMLS traits? Then the actual client impl for MLS itself? nostr:nprofile1qqspwwwexlwgcrrnwz4zwkze8rq3ncjug8mvgsd96dxx6wzs8ccndmcpzemhxue69uhk2er9dchxummnw3ezumrpdejz7qtxwaehxw309anxjmr5v4ezumn0wd68ytnhd9hx2tmwwp6kyvt6w46kz6nyxa6nxumc8pu82wfj09shvwt2wau8qu3cxvukxuesdd3nxufkws6nvanyx46njufsxvehsmtgwd4nvcejw43n7cnjdaskgcmpwd6r6arjw4jszxrhwden5te0dehhxarj9enx6apwwa5h5tnzd9az77vr4lw
Also feels like client impl shouldn't leverage main nsec for any of it. Maybe just inititalizing a group? But then have client manage ephemeral keys at a client level for individual chats. Also, have a lot of questions around group admin stuffs. But maybe that's all in the MLS spec I havent read yet...
Yes, that's right. To run a secp256k1 ciphersuite we'd need two things. 1. An update to the OpenMLS implementation of the MLS spec (because it can't accept custom ciphersuites at the moment). 2. An update to the OpenMLS RustCrypto library (which is the crypto traits that are needed for the OpenMLS library). OR a brand new implementation of the crypto traits. You don't need the user's main nsec for much in how the NIP_104 spec is written. There is a need to sign a few events but not many and nothing that is inside the MLS stuff.
Does 2 need to come first?
Is anyone actively working on implementing this yet?