This is the fifth in a series of weekly updates detailing progress on bringing MLS ...

This is a long form article, you can read it in https://habla.news/a/naddr1qvzqqqr4gupzq9eemymaerqvwdc25f6ctyuvzx0zt3qld3zp5hf5cmfc2qlrzdh0qqxnzdejxvurqv33xvurydf5xr6m0l

This is the fifth in a series of weekly updates detailing progress on bringing MLS protocol DMs and group messaging to Nostr.

Previous Updates

Progress this week

I’m back from a few weeks of family holiday this week and feeling super productive. The major news this week is that I’ve posted the draft NIP to the NIPs repository for how to implement MLS messaging on Nostr. I’ve gotten feedback on the doc from several other Nostr devs but I’m absolutely looking for more feedback from the community.

I’ve also made progress on the dependencies that I was working on before my holidays. Info below.

The NIP

I won’t review the entire proposed NIP here but I wanted to call out one tradeoff that I thought hard about.

In my original proposal, which only supported one-to-one direct messages, all messages between the two parties were sent as NIP-59 gift-wrapped events. This helps to hide metadata but it creates problems of it’s own. Notably, it’s very possible to DDoS Nostr clients with meaningless gift-wrap events since clients must decrypt and unwrap each event to even understand if it’s something that is important to them.

Aside from those problems, gift-wrapping messages to an entire group would be very impractical. It would require the client sending a message to individually gift-wrap the message individually to all other participants in a group.

The tradeoff I’ve come up with is to use a public event, kind:445, tagged with the group ID, so that all participants in the group can easily query for messages from each of the groups that they are a part of. The content field of these event is encrypted using the MLS ratchet keys and thus is only able to be decrypted by members of the group. These events are published using an ephemeral key so that the number and identity of the group members is obfuscated.

This means that observers have a relative idea of the level of activity in a given group but don’t know exactly how many or who is in the group. In addition, it’s easy within the MLS spec to rotate the group ID over time.

Would love to hear thoughts on how people feel about that tradeoff.

HPKE-RS

My PR to add support for secp256k1 is stuck because of bad test vectors for the secp256k1 curve. I’ve been working on generating new vectors that will be usable by other HPKE implementations as well. Huge thanks to @dan for the help on this.

OpenMLS & Ciphersuites

As mentioned in the previous updated, I’ve spoken with the OpenMLS team about how to better support custom ciphersuites. I’ve started to work on the expansive refactor in OpenMLS to make this possible but it’s going to take a while.

One major decision that has come from this is that I’ve decided that the NIP will not require a single custom ciphersuite (built around Schnorr signatures on the secp256k1 curve). Instead, clients can decide which ciphersuites they want to support and are able to implement this NIP immediately with the current OpenMLS version.

I will continue to work on refactoring the OpenMLS library to ensure that it supports custom ciphersuites and to build a custom Crypto Provider focused on the Nostr crypto primitives and I expect that, long-term, many Nostr clients will prefer to support only that ciphersuite to reduce the dependency surface area of their apps.

Onward and Upward