It's very clear to me that people do not want device keys. They want to reply in all chat-supporting clients.
Simplest version is with key aliases below, but managing keys them across multiple apps/devices is quite complicated. Lots of race conditions.
Key rotation is solved though. You can just reencrypt all wraps you received by yourself, without participation of each peer, which you cannot do with nip04 and other encryptipn mechanisms.
This is a lot different than what i was thinking of, i wasn’t trying to solve the metadata leak
Agree. The PR as proposed is just for metadata (I was trying to keep it simple) but we could change it to do the encryption as well, solving both issues at the same time.
This is cool in the sense you can have a mode where you have to establish a link before you can start communicating, this is something nostr:npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj tried to do awhile back but this appears to achieve the same thing? Just send a giftwrap of key aliases to the user to let them know how to contact you. Neat.
It's a DM-specific solution to what nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hszxmhwden5te0wfjkccte9emk2um5v4exucn5vvhxxmmd9uq3xamnwvaz7tmhda6zuat50phjummwv5hsx7c9z9 was trying to do with decoupling encryption and identity: https://github.com/nostr-protocol/nips/pull/1647
Maybe there is a broader way to do all nostr encryptions via aliases, but I don't see it yet (a use-case-agnostic scheme gets too complicated too quickly)
One thing at a time i guess, i can at least wrap my head around and design around the more focused usecase of alias keys in nip17
We should definitely be moving toward device keys across the board
Also resending this alias list would be the similar thing on signal: “user changed their safety number”
If your root npub leaked and the attacker tried changing the keys, you would see this.
