Subnostr

I very much agree with both of these posts, thanks for summarizing the concerns accurately

The only other thing I would mention is that switching over to nip44 or nip44 + giftwraps now is an unnecessary hardfork of DMs and is only going to cause people to leave the protocol.

This desire to hardfork core communication functionality all the time is concerning. I already saw a thread of people getting frustrated that people aren’t getting DMs from amethyst users.

You could argue noone should use nip04 dms anyways because of metadata leakage, but replacing it nip44 doesn’t even fix that. giftwraps are complex and are not obviously the solution either.

My preferred route would have been keep nip04 for as long as possible until we have a really secure protocol extension that solves private communications in a robust way. A solution that is so obviously better and simple to implement that everyone would switch to it. Not sure if thats possible, but I would have at least liked to see ratcheting (OMEMO ?) in the v2 DM spec.

Reply to this note

Please Login to reply.

Discussion

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

oh yeah, ratcheting... so, as i see it, the problem is that for the most part, #nostr is a stateless protocol

all techniques of forward privacy require a state, this is easy in an interactive protocol because it is ephemeral but async state has to be stored somewhere to be available in future and on different devices independently

you need to create a secure method of securing state, and simply, application specific data can always be encrypted in each case to a different counter-key that is thrown away afterwards anyway, and in that state can be stored information about things like next-keys to use in a ratcheting protocol, even a multi user ratchet protocol like MLS the state has to be stored somewhere

jb55 1y ago

I think on-device keys is fine and inevitable. Even on signal switching to new devices will lose your comms history. Nostr wouldn’t have any issues with this.