Are there any clients out there that have solved the NIP 17 spam problem from a UX standpoint? It would be nice to separate "requests" into requests from reputable people in your network (based on wot or pow) and requests that are unlikely to be worth your time.
Discussion
Can you add detail to this problem statement, and show an example?
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.
It would be fantastic:
- if people could specify whatever condition they want on their mailbox (including pricing, vertex-filter, ...)
- if their inbox relay would respect that and deny anything that doesn't meet the condition
- if the sender gets information up-front price f.e.) and feedback in case of non-acceptance
For the sender to get this info up front, it would probably need to be in some sort of "DM Policy" event kind that can be looked up by the sender's client from the receiver's relays.
Maybe this "DM Policy" event kind would include a tag for types of senders that are always accepted that could be set to follows only, web-of-trust, or allow all (not recommended unless you just like spam); and another tag for other optional conditions upon which a DM will be accepted from those who fall outside the filters, such as exceeding a pagerank threshold, including a certain amount of PoW, or paid postage using an eCash token from a reputable mint,
Of course, your DM inbox would then look very different, based on which clients respect your DM policy and which ones don't, but my inbox looks very different from client to client already, based on which DM NIPs they support. 😂
Maybe these policy tags could be included in the user's kind 10050, since clients SHOULD already be looking that up to determine where to send the DM anyway.
If your inbox relay(s) respect your conditions it's easy to make it look the same in your apps.
I suppose I was operating under the assumption it would work like your email inbox. You technically still receive the spam, it's just shuffled away to a corner of the UI that you don't have to look at unless you are looking for a particular email that may have been sent to your spam folder. In the same way, your inbox relays would still store DMs from potential spammers (with maybe an auto-delete after a certain amount of time?) but you just wouldn't see them in your client's UI unless you specifically went looking for them.
That said, you are right that making it a policy that the user's inbox relays enforced entirely would mean that the inbox would look much the same in all clients, NIP-04 vs NIP-17 notwithstanding. The user just wouldn't have an option to browse the potential spam received for possible legitimate communications, since the relay would presumably be rejecting those messages.
Can't really enforce it on the relay level without sharing the ability to decrypt the events, since sender metadata is obscured on nip 17.
Amethyst separates DMs into known and requests. I ink it is just based in whether you follow the other npub, but I could see it ring some WoT threshold. Seems like a common UX pattern that could be tuned to your needs.
None that I am aware of. It would definitely be handy to have requests split between those I probably want to see and those that are likely spam, and I think Vertex's pagerank would be a good basis for it.
With NIP17 there is no way to defend at least against an attack where the sender generates a lot of msgs and you have to decrypt(unwrap) each before you can decide what to do with it.
Relays can't do anything about this either, as mentioned before. No one knows who you are - i.e. WoT is useless here, if we look merely on event info.
The method of relay AUTH and then DM, although interesting, falls short too:
1. **Most ppl won't have a 10050**
2. Hard to standardize. Okay, we could try to craft another spec for this too. But still there is point 1.
The solution, again, is not overengineering a DOA solution.
Just use communities.
If you share at least one community, it's gonna be allowed by default.
Communities CAN and WILL run relays, for DMs as well. They care about their members getting their mail, and to effectively filter spam as well. Yes, we can do more complex stuff later when we need.
This kind of stuff is NOT solved by clients, NOR by relays. It's solved by people with the right incentives.