send message between jumble (beta) and coop works like a charm, all messages are encrypted by encryption key rather than user identity (NIP-4e). kudos @Cody
Login to reply
Replies (16)
Where can I read up on NIP-4e? Can you drop a link?
I just built it based on your ideas, I should be the one thanking you guys.
Does this work with nip17?
+1
I built it based on @npub180cv...h6w6 ideas 😅
It is nip-17, but it just didn't use your private key when encrypt/decrypt messages. 
GitHub
nip4e: decoupling encryption from identity by fiatjaf · Pull Request #1647 · nostr-protocol/nips
this is inspired by MLS, but much simpler, and definitely not trying to be a group communication system, but only a way for users to encrypt things...
How does it know when to use my identity key or when to use my decoupled key? Is it like if I send a message to someone who has a decoupled key then it will also use my decoupled key?
But aren't Jumble's DMs a NIP-17 version of NIP-4E? How is it compatible with Coop's DMs, which are NIP-4E?
Coop was the first client to support NIP-4e, and it lets you choose different modes when sending messages. Jumble only displays NIP-4e, so when sending a message from Coop to a Jumble user, make sure to select “encrypt by encryption key.”
You can check it by using config button here
"Auto": Coop will use decoupled key if both users are set it up, if not coop will fallback to the user key
I'm also adding a feature to check if message is encrypted by decoupled key or user key
Yes, I agree the UX need to be improve, but I think you're misunderstand some points
- Client A create a encryption key, user use it for encrypt/decrypt stuffs
- Then user use Client B, Client B see user has set up encryption key in Client A. Then Client B request to share the encryption key from Client A. Client A share it.
- Only one encryption key there, there are no multiple encryption keys
I'm assuming that at scale some fragmentation will occur due to undiscovered 10044. But technically you are correct: In a perfect network there would only ever be one encryption-only key pair. With all the issues Marmot has been having with key package discovery and reconciliation on NOSTR, I think 10044 will suffer a similar fate.
10044 event is only published to the user's relay list. but yes, it could still be missed