You just successfully argued against your proposed solution.
I agree that requiring payment per message would solve the spam issue, but it wouldn't necessarily solve the "different clients use different DM specs" problem. Indeed, it would just make it worse.
I argued that only payments solve the DM issue, and the reason clients are not converging on one spec in the first place is that they have little hope to get their users pay for DMs, so they try to cook up a multitude of specs to escape this reality.
Get users to pay -> ossify/converge specs = easy.
That is what I argued. Do you find something problematic with that?
NIP 4 still handles the spam angle with a possible wot filtering without payments.
This makes it usable. Usability comes first. Encryption is still hiding the content, and we can NOT do better, at the moment because _someone_ must pay for DMs to be more private, that's just the reality.
I funded a NIP17 PR to be included in NDK. It was merged, and then I realized the shortcomings so couldn't actually implement it in SatShoot, and I was not happy about that.
I agree NIP17 is the way short term, WITH payments. Perhaps MLS later, or signal protocol. But without paying users it's hopeless in my opinion so I am tackling that problem first.
Beating the drum about DMs doesn't get you anywhere, and no, it is not an easy problem.
Yup :110percent: !
I'm starting to like NIP-04 more tbh. Because it incentivises having a relay (that you can set any limit/price on, as the receiver).
I don't think having the sender metadata leaked is an issue, if the message is only sent to the recipient's DM inbox relay, and that relay supports auth to ensure only the recipient can request the message. I don't think NIP-4 uses NIP-44 for encryption, though, right? Would it be better to use that updated encryption standard, at least?
Then, yes, users could have a relay that they set a required price to post a DM to them. Users who have the know-how would be incentivized to run a relay where they get paid anytime someone wants to DM them. The rest of users would have to rely on relays that take a cut of the payment, or else deal with spam.
Same :Check:
Have no idea what encryption Nip-04 uses. I'd dare to bet it's good enough for me tho 😉
I am not aware of a "multitude of specs." I know of three.
1. NIP-04, which should only be used with auth relays, due to the metadata it leaks about both sender and receiver.
2. NIP-17, which definitely has the shortcoming of being unable to filter DMs based on who the sender is, since the metadata with sender info is hidden. More private, but yes, more susceptible to spam without some other mitigating factor.
3. NIP-EE, which uses MLS and may well be the future of DMs and group messages, but is not yet ready for prime-time.
There are a couple clients that are doing a bit of their own thing, too, like nostr:npub1h0uj825jgcr9lzxyp37ehasuenq070707pj63je07n8mkcsg3u0qnsrwx8, but that's outside of any NIPs that I am aware of.
As far as whether I find any problems with your argument, only a couple. First, you already identified why it will never happen. Users expect to be able to DM for free. Requiring payment to send a DM is a fantastic way to reduce spam, but only if users are on-board with it.
I also don't think it would result in a convergence on a particular spec. If anything, I think it would result in more fighting about it. You would have folks like us on one side, shouting about how requiring paid "postage" is the most effective way to reduce spam, especially if users themselves can set the amount of postage required to DM them, while others would be shouting about how making people pay for things is a barrier to adoption, and stubbornly keeping DMs in their clients free for everyone.
Heck, Keychat is already an example of a client that has MLS-based DMs with paid postage, yet its existence hasn't resulted in every other client converging on that spec, because most users simply don't want to pay to send a DM, even if it would mean they receive less spam.
Signal and MLS keep state (they ratchet keys every message), so they’re kinda awkward for microblog DMs. For Nostr DMs, it basically comes down to NIP-4 or NIP-17.
Since you can’t know what the other person’s client supports, a tiny DM mini-app could just send both versions—one NIP-4, one NIP-17. Their client opens whichever it understands and they reply like normal. Downside: a separate mini-app isn’t as smooth as hitting “DM” on someone’s profile.
