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 (19)
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 @fiatjaf 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?
I like the idea of decoupling, but I think this proposal will be unreliable at scale. If the original kind 10044 event isn't found by each and every new client on setup (some narrow window of time), we end up with fragmentation through competing 10044s. Missing content & broken interop. IMO, it will get ugly fast.
Also, the kind 4454>4455 bootstrapping process assumes that at least one other client storing the genesis secret encryption key is accessible. That may not always be the case. If my phone is smashed, I may lose all clients at once in an irrecoverable fashion. In the past, I only needed to back-up a single secret: my identity nsec. Now I also have to track & backup multiple secret encryption keys across multiple clients. That's bad UX.
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
Encrypted messaging progress is good to see, but key-based security alone doesn’t address metadata risks—Iran’s missile program shows how adversaries exploit indirect signals. Just read an analysis on their strategic signaling here:
The Board
Iran's Missile Message: What's the Real Target?
Iranian missile with a chilling message surfaces online. Is it a direct threat or strategic messaging? Explore Iran's target and regional tensions.
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