Nostr Web Client

When I was reading the MLS protocol last year, I was picturing using it to rearrange destinations for the usual NIP-17 gift wraps such that Clients would use the group ratchet to find where the group is at. In that way, it would simply reuse the usual NIP 17 messaging scheme.

However, the unclear part to me is how much metadata leaks in the key exchange procedures. There will be messages going back and forth between member to rotate the group into new keys and I think that has a change of being traceable. Time correlations could allow the public to reassemble the hierarchy of keys.

It feels like MLS authors were trying to solve group chats so that they forgot about metadata tracing on all intermediate needs of the protocol.

But I also think that the metadata leak is solvable. We just need to invest the time to do it.

JeffG 1y ago

I was originally referring to the group implementation from MLS. nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z is right though, the MLS authors definitely were more concerned with efficient large groups that rotate keys correctly than they were about metadata leaks.

This makes sense when you think that they were really designing for a situation with a centralized "delivery service". They do mention that MLS is built to work in federated environments (e.g. Nostr) but call out that the transport protocol for federation would need to be figured out.

That's precisely what I'm working on now. How do you use MLS with multiple servers (relays) with no guarantees that messages arrive in order or from the right people or at all. And how do you do so without leaking metadata.

It's going to be a combo of giftwraps and a few new event kinds for the control messages that need to be sent for managing groups. (remember that a DM is just a group of 2 participants).

Reply to this note

Please Login to reply.

Discussion

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

metadata leaking can only really be eliminated by turning relays into rendezvous and making use of back channels that are not known to the rendezvous relays

the way that simplex does it would be a good reference point, i do believe that some kind of forward secrecy/ephemeral async message relaying has to be involved because of the neverending problem of lack of inbound routing for most users

JeffG 1y ago

Can you explain that a bit more? I think we can easily obfuscate metadata via gift wraps.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

gift wraps only obscure the sender from upstream, they still leak the recipient, if i understand how they work, and if the relay accepting the event is a paid member they have to use a known identity and thus effectively leak the downstream source

the hardest part of solving this problem has to do with maintaining state, and the only reasonably secure solution for that is application specific data so it transits across multiple machines with only the nsec as the linking point

the only really almost perfect solution requires the relays to only give out ASD to users specified in the pubkey field, then the relays can be moderately secure repositories of this state and for extra security, clients could use state stored on one relay but use that state on another

i am a little familiar with MLS, it requires some state to be shared between the members of a chat as well

i haven't tackled the problem because it is a pretty hard problem to solve given the stateless, relay based architecture of nostr, but i think it will be solved

i do wish that more clients would git r done and get authing working so that private personal relay caches could actually be secured without them not being reachable from the internet

JeffG 1y ago

I think you're overthinking things.

Yes, it's possible to see that a user is receiving kind: 1059 GW events but what those events are is completely hidden. As long as users that are sending the GW events to the relays are using a VPN, they're hiding their IP addresses (there are also some other ways we can improve that but let's leave it at that for now).

The state is maintained with a specific set of control messages that users in a given group send between themselves. Those will be GW'ed as well.

I imagine that in the near future there will be many many GW messages that are being sent to every user on the network, it'll be like trying to watch encrypted TLS traffic. Sure, people are using the network, but you don't know how or why.