I guess some will not implement because waiting for the nostr:npub1zuuajd7u3sx8xu92yav9jwxpr839cs0kc3q6t56vd5u9q033xmhsk6c2uc proposal to happen
Discussion
This is a trade-off: implementing Double Ratchet on Nostr will be very challenging. While NIP17 doesn't offer the same level of forward secrecy as Double Ratchet, it allows DMs to be recovered on other devices and Nostr clients, which is essential for Nostr users.
Oh, I didn’t know that double ratchet lives only on one device. Yeah if the history isn’t transferable then people will be pissed off loosing their DMs
It’s per device/client pair. In other words if I have damus and primal on my phone each counts as a separate participant in the chat.
This is why group support in the protocol really matters. Smart clients will be make sure that you show up as a single participant in the conversation and there are ways to back fill chat history but there are some tradeoffs inherent.
Group support based on the same implementation? Or somehow paired with NIP17 ?
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.
Somehow signal managed to kill the metadata leaks using MLS what the concern over here ?
Metadata does leak to the signal server. They just claim they don't track it. Which is why I don't like these types of solutions with central servers.
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).
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
Can you explain that a bit more? I think we can easily obfuscate metadata via gift wraps.
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
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.
Aka no forward secrecy. Or post compromise secrecy.
They’re two different things to me. Clients shouldn’t wait to implement NiP-17 imo.