We should call this the Nostr Paradox:
I don't want my family DMs in my "work" client in the same way that I don't want my OnlyFans DMs in both. They are all DMs, but I don't want to see them in contexts I am not ready for.
Discussion
Can use a burner set of keys for the silly things
Can't you have multiple relays set up for DMs, and only use one specific one for each client ?
We can, but then your relay lists will also be on a per app basis. Setting relays would then be an activity each app must now also do.
It is great this is being discussed. Thank you for your work.
To clarify, what I meant by sub-keys was creating a derivative of the primary key, basically the sub-key acts as a two factor authentication, or authorization protocol as a method to allow access without exposing the primary key.
I wasn't necessarily implying creating multiple accounts off of one key per se, to put it in Bitcoin terms I meant more like a Xpub that can generate new addresses for you, not a Bip-39 that let's your interact with other Bip-39 coins using the same seed (NSec).
I meant more like if there's a questionable instance you want to explore but not put your main Nsec in, & talking about a way to resolve the discrepancies between Primal, Damus, and Amethyst, etc., I use one Nsec for all them but half of my notifications don't relay to other instances.
But to elaborate on the idea, a Sub-Account Key vs a Authorization Sub-Key.
I'm not saying you should, or shouldn't build it, I was simply throwing an idea out there, & I apologize if it upset you.
For example on Facebook, and X
NIP-17 "subject" tags can fix this.
It's only a paradox if you keep thinking from the Client-perspective.
From the Relay-perspective, different communities are different relays.
You can call it the "Client that ignores Relays" Paradox if you like.
But NosTR solved for this from the start.
That's not solved at all. Every key only has a few specific relay lists. There is no such thing as multiple relay lists for the same event kind.