DMs aren't used all that much right now, and maybe clients could only request all DMs within the last X amount of time by default to reduce the amount of bandwidth, only requesting older DMs if the user scrolls up and requests to "load previous" or "search for previous." That would help with the bandwidth considerations. The benefits for spam mitigation is what I am more interested in. Maybe not a terrible tradeoff. Are we basically admitting that NIP-17 DMs are the best we're going to get for the time being, and we should just make them as good as they can be. I know there have been some struggles getting MLS to play nice with Nostr, especially for group chats. I think I more or less understand how your proposal would work, as @Vitor Pamplona explained it. I assume that since you still don't see the pubkey of the sender, each side of a given conversation would have its own public conversation code?

Replies (1)

I'm still optimistic for other schemes in the long term, but nip 17 is pretty well supported and this is a very easy and relatively compatible lift. And no actually, the same key would be used to sign events no matter who sent the message (hence @Vitor Pamplona's point about attackers being able to rewrite history, which is significant). For the record, I don't exactly know where I fall yet.