Adds key aliases to NIP-17

[vitorpamplona]

trafficstars

A simple way to:

1. Remove the final metadata leak from NIP-17 (the public key of the receiver is on the gift wrap)
2. Distribute a stream of messages through multiple relays that are not publically advertised by the user.
3. Control disappearing messages from others to you (just delete/rotate the alias private key). You can already control disappearing messages from you to others by adding the expiration tag to wraps.

Questions:

• Should we add this to all Gift Wraps or just DMs?
• Should we offer more relay URL options per key or is one enough?

[wcat7]

This is awesome. I've always thought that combining nip17 with alias key could achieve an effect similar to the double-ratchet algorithm. I also have implemented a secret chat feature in 0xchat, combining nip17 with alias key exchange(NIP 101). However, I would prefer to see alias key directly integrated into nip17.

[staab]

I also have implemented a secret chat feature in 0xchat, combining nip17 with alias key exchange(NIP 101).

We should use this rather than creating something entirely new, if it's suitable.

The problem I have with adding key exchange to NIP 17 is it hard forks DMs again. Clients that don't support aliases won't receive messages. NIP 17 was "good enough" to displace nip 04, but I don't think the same is true of this NIP. I'd rather see a complete solution come together that is yet another order of magnitude better than 17.

[vitorpamplona]

The key creation requires more thinking, but for clients that don't want to support aliases, all they need to download the 10058 event and add all those keys to their GiftWrap filter, which has only the p-tag of the user right now. Then, when receiving the GiftWraps, use the private key of the p-Tag, and they will be able to see all messages from the aliases another client created.

To me is not that much different than adding a specific relay list to the DM NIP.

But I agree that full support for creating, rotating, and publishing aliases is more intricate to code.

I'd rather see a complete solution come together that is yet another order of magnitude better than 17.

The only thing that offers an order of magnitude over NIP-17 right now is MLS. And it's going to be very complicated to code that one.

[erskingardner]

MLS is coming. 😉

But you're right, it's going to take a bit longer.

Honestly, I think we should stick with simple nip-17 until MLS based messaging lands. The idea will be that in addition to the spec I'll work on library code and directly with clients to help them implement. It's not going to be super hard but it's really important to do it right so that you aren't breaking the security benefits on accident.