im trying to find a spam protection model for nip-17 on relay layer and here is what we have:

1. we can't perform whitelisting on pubkey since it's a random temp key.

2. we can't p tags, since we send 2, 1059 event for each dm. each one with one different p tag. we can validate the sender event (we have a p tag and we can check it using authed pubkey) but we can't do it for receiver event. (if we just check the p tag, then anybody can put a whitelisted p tag and send dms.)

i want to know if anybody knows how we can check such thing on a whitelisted relay so only whitelsited users can send dms to each other.

> i hate nip-17. bullshit.

#dev #devstr #asknostr #nip17

Reply to this note

Please Login to reply.

Discussion

NIP-17 was specifically designed to disallow any type of interference by relays. It was one of the main purposes of the spec that relays shall not be able to know anything about those wraps.

NIP-17 as a vehicle for spam is very interesting. Any reputational metric requires to identify the sender/receiver, which is something that you don't want.

This is the ideal place for ecash I believe.

Clients should be able to file kind 1984 reports on the public wrap and you can then delete those wraps they reports.

Clients can also ask you to delete a wrap that was addressed to them on a regular kind:9 deletion request.

Hopefully over time we can build a client that simply helps users organize their inbox and delete stuff they don't need anymore.

so, based on our discussions, do you guys ok if a paid relay let any dm come to you? and you know this as a part of clients responsibility?

Yep, that's the only way at this level of privacy.

I was wondering if we could use the NIP-29 group mechanism, where only people in the group can send/receive messages.

reacting to spam is not going to work in an hostile network.

An attacker could simply spam with NIP-17, and when it starts to get rejected he simply change the public wrap.

Yep... I have been the target of multiple spam attacks involving 1000s of messages and even DoS attacks with DMs. But none of that made a dent in my DM experience on Amethyst.

All attacks can be resolved from a client. None of them will ever be fully resolved by the relay.

You can even keep a client running that simply performs any WOT assessment after decrypting the DMs. But it is the client's role.

Yes, clients do play a role against DoS attacks against users.

nostr:nprofile1qy2hwumn8ghj7erfw36x7tnsw43z7un9d3shjqg4waehxw309a4x2mrv09nxjumg9ekxzmny9uqzp022u0n8u2vkf4y5zu3xrhz989wgna4a9em5vshrvcf8zuwlhq04jt7lhu I think was more concerned about DoS attacks against a relay

my simply way ACCEPT DM from any npub once WHITELISTED by me / user

someone tell 1st time in open noste i am DMing you that's it needed

Can you explain is more clearly? Maybe with example? Also, is it for relays or clients?