Nostr Web Client

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.

Niel Liesmons 7mo ago

If your inbox relay(s) respect your conditions it's easy to make it look the same in your apps.

Reply to this note

Please Login to reply.

Discussion

Dikaios1517 7mo ago

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.

hodlbod 7mo ago

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.