Can you add detail to this problem statement, and show an example?
Discussion
With nip 17 it's trivially easy to spam someone's DMs, and since sender metadata is hidden, relays can't do anything about it. Clients have to download all DMs regardless of who they're from, then make decisions about whether to show them to the user. Say someone sends 1000 DMs using 1000 different one-off pubkeys. Now you have to sift through 1000 conversations to find out if any are legit. It would be good if clients could just say "found 999 conversations that are likely spam, here's the one good one".
One more case for relay level filtering. WoT would help there, no?
No, because relays don't know who sent the message
Which 'kind' are you referring to specifically - 1059? I'm interested because I'll be implementing this tomorrow and may as well look at it now.
Yeah, 1059 wraps 13, which wraps 14. This allows the only metadata visible to be the addressee. It also allows the DM to be deniable since it doesn't carry its own signature. It's annoying to implement, but @welshman/signer has one implementation, and there are others out there if you're looking for a library to use.
Thanks, but I wasn't looking for one. Knowing the created_at, a relay could batch and score based on the addressee and created_at. I'm not suggesting it but I was going to experiment with this part anyway because I saw that yesterday.
As far as clients go, you have more options after unwrapping.. one is delaying presentation until the client decided it's trustworthy enough to show or put aside. Just an idea.