Keychat uses a seed phrase instead of an nsec. Later, users only need to save one seed phrase to have multiple IDs. At the same time, this seed phrase also serves as the user's cashu wallet seed phrase.

Can the chosen relay link IP-emphemeral identities and start putting a sequence of messages together? Can't they just see when the group id has changed and link the two? I am not doubting MLS, but I have seen too many people claim privacy until I run their server and start logging down everything every connection does to locate, track and identify each participant. If the relay can do it. They can either sell that info for profit OR be required by court order to track and identify users. If they can do it, they will do it. That's why I am using Tor when connecting to DM relays. Every app session is a new Tor exit node. Relays can't know where each message is coming from. It's the only way I found to keep things private.

To be fair, it's not unreasonable to have this primal desire for subkeys and key rotation. The problem is that: 1) it's not possible to do without centralization (or a blockchain) -- Bluesky tried, and the best solution they came up with was a big server that hosts a history of keys for everybody and can censor anyone; 2) doing it by means of Nostr events that declare subkeys or delegation or whatnot, creates insurmountable complexity that turns Nostr into an unusable pile of bloatware and away its most basic feature: the chance of working; 3) it's not the only way to protect your key from rogue computers and apps -- NIP-46 and other methods exist and are much nicer to use, with still many unexplored possibilities; 4) it's not clear that more than 16 people in the entire world want this at all -- when was the last time a normal person thought about rotating their PGP keys?

What about the UX for managing all these keys? Every time you try a new app you must create a new key using your master key, so where does that master key live? In an offline hardware device?, then it will be incredibly hard and only 5 people in the world will do it, everybody else will just paste nsecs and the protocol will be bloated for no reason. Or in an online device or server that keeps running 24/7 and answering requests for creating new keys somehow? Now we have just recreated NIP-46 but 100 times worse.

Alice and Bob use the Signal protocol to derive a key chain, sequentially using keys to encrypt/decrypt messages, and delete each key after use. Alice Bob k1 k1 k2 k2 k3 k3 k4 k4 k5 k5 k6 k6 k7 k7 k8 k8 k9 k9 k10 k10 k11 k11 ……. …… View quoted note →

Did you know that NIP-17 was designed to keep metadata private even if devs make mistakes in their apps? Designing a DM protocol where you control the server and app on a single codebase is very different than designing something anyone can code flawlessly from scratch.