This is the fourth in a series of weekly updates detailing progress on bringing MLS protocol DMs and group messaging to Nostr.
Previous Updates
Progress this week
The dependency train continues to roll. This week I was in touch with the maintainers of both OpenMLS and the hkpe-rs library and have pushed my changes forward in both areas. I’ve also gotten closer to understanding the wire format and relay requirements for the NIP I’m working on.
To be honest, the progress feels pretty slow at the moment but I’ve seen this story often enough to know that I’m on the right track. To be clear, my goal here is do this right and make it as easy as possible for Nostr devs to implement MLS based messaging across all of Nostr. That necessarily requires ensuring that all the implementation libraries support the right pieces and that our NIP is clean and well thought through (no one likes a shed full of bikes).
HPKE-RS
My PR to add support for secp256k1 is moving. I’ve been adding tests this week and fixing a few issues. Once this is merged, I’ll update my secp256k1-based library as well. One unfortunate roadblock has been a lack of solid test vectors - this has eaten some time.
OpenMLS Nostr Crypto
I had a short call with the OpenMLS maintainer team this week and was able to clarify what I’m trying to do and how they see it fitting in best. I was also able to get a better idea about how clients will need to process incoming messages. One interesting highlight: Messages have to be processed in the right order. Otherwise it’s impossible to keep the ratchet tree in the correct state. My left-curve solution to this for now is to use both created at (as a dumb first pass at sorting) + a hash of the previous message content. This will give Nostr clients a simple way to double check that they have the messages in the correct order before they attempt to process them. Unfortunatley, this doesn’t do a good job accounting for messages that are missing. My guess is that this isn’t going to be a major issue, but I won’t have a clear idea until there is a working Nostr relay based demo.
The next steps in my code for OpenMLS is to refactor the ciphersuites trait to make it easier to use custom ciphersuites. My initial PR hardcoded our secp256k1 based suite into the library but the clearly better solution is to refactor a few things to make sure that there isn’t any hardcoding in the main OpenMLS library, the ciphersuite, or the credentials (which hold your identity information and make prekey bundles possible). The library’s maintainers are open to this, so I’ve started on that this week.
Request for feedback
I’d love to hear from devs on one point. The OpenMLS library currently makes it very easy to serialize messages (both group control messages and actual messages between users). These messages have a lot of data in them about the current structure of the ratchet tree and whatever message or control event they’re trying to communicate. My current plan is to simply NIP-44 encrypt those serialized messages into the content field of a new event kind. The messages themselves are deserialized and processed in two simple calls by the OpenMLS library so I don’t see any reason to keep destructured or deserialized data in the nostr events that are heading over the wire. This also makes it easier to keep metadata about messages hidden to observers.
Goals Recap
It’s been a few weeks since I’ve talked about why this is important so, it’s time to recap what we’re aiming for:
- Private and Confidential DMs and Group messages
- Private means that an observer cannot tell that Alice and Bob are talking to one another, or that Alice is part of a specific group. This necessarily requires protecting metadata.
- Confidential means that the contents of conversations can only be viewed by the intended recipients.
- Forward secrecy and Post-compromise security (PCS) in the case of any key material being leaked, whether that’s your main Nostr identity key (your nsec) or any of the keys used in the MLS ratchet trees.
- Forward secrecy means that encrypted content in the past remains encrypted even if key material is leaked.
- Post compromise security means that leaking key material doesn’t allow an attacker to continue to read messages indefinitely into the future.
- Scales well for large groups. MLS provides this from a computational standpoint, but we need to make sure this works in a scalable way when multiple relays are involved.
- Allows for the use of multiple device/clients in a single conversation/group. Importantly, we’re not aiming to enable a device/client to be able to reconstruct the full history of a conversation at any point.
Onward and Upward
Grind, grind, grind. Touch grass & hug family. I’m visiting family starting next week for a few weeks. I’m going to be taking some time off in there so expect a few light updates in the coming weeks.