This is an entirely different problem, completely independent of the outbox model.
Relays can and should do spam protection, certainly
Outbox model is about to/from which relays to read/write not what ACL each relay applies
Been thinking about inboxes for a while.. Trying to think of the perspective of a popular user who gets probably an overwhelming amount of inbox spam. So far all the gossip specs are missing something, they're missing the idea of paid relays. Paid relays, even for small amounts, think how nice this would be for popular users. Someone has to pay, to send to their inbox, send them a DM etc (even just a one time payment). This cuts malicious users/bots down at their kneecaps because it becomes possible to moderate your inbox. Without this, bots can just spin a million keys and destroy your nostr experience while laughing all the way to the bank (the bank that cost them nothing to use).
So, what I think needs to happen, is gossip spec should to expand to think more about the paid relay case, clients should make it clear to a user that the inbox for that user is paid, and help them do this, or point them at a secondary inbox (which is not checked that much because think about it, this is a common twitter problem too, big social media accounts don't even read their comments and they think this is a solution. Nostr can do better than this. Large accounts should not have to go into broadcast only mode or get constantly screwed by bots).
nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z thoughts?
This is an entirely different problem, completely independent of the outbox model.
Relays can and should do spam protection, certainly
Outbox model is about to/from which relays to read/write not what ACL each relay applies
Right, there is resistence to paid relays for some reason but I can only see it coming from the client side.. saying "relays can protect against spam" but without lightning it doesn't work. Doing it how? Paid is the only way to fend off multi-key bots.
For example, on NYE, a bot filled my entire relay, commenting to everyone Happy New Year, while the japan earthquake was in full force. Many japanese left my relay that day, and that's why I went to paid model. I was sick of these targeted attacks and lightning is the only way to prevent them. IP limits don't work, rate limiting doesn't work, spending tons of time coding detection is just an arms race and the bots always find a way to get through while regular users get penalty. The bots won't get through lightning verification though it will exhaust their funding even in small amounts.
sure, yeah, what I'm saying that's a different thing
the client can create whatever flow they want to have users pay for relays, this is unrelated to the outbox model
just brainstorming here, like say i want to set just one inbox, to a relay i trust like nostr.wine. In the gossip settings it says for "inbox" that relays shouldn't require payment. The reason for this I think is simply that it's confusing for gossip clients, they don't know your inbox is paid. Maybe gossip can have an ["r", "wss://nostr.wine", "inbox-paid"] field or something like this? What is the downside of making paid a first class citizen? Would it not be easier to do that sooner, than having clients do multiple queries fired off to nip11 endpoint or nah?
it would just require that fetching from the relay requires ONLY paid npubs to appear in it or reject
in fact, currently for the most part they simply only accept publish with subscriber npubs, because no fucking clients support NIP-42
with NIP-44 and NIP-42 working, you can also make it so you can fetch kind 4/1059/1060 only for your own npub without opening a giant hole in the payment scheme as well
you might notice how many things become easier when clients fucking sign auth challenges
I finally understand what you were meaning here and I agree. Clients just need to be better about user feedback when gossiping. Like nostrudel, how it shows the relays that accepted the note, and the ones that didn't. If it detects that all the relays failed to accept it, there can be additional prompting like, this user only has relays with access control, visit the relay landing page? Stuff like that. Thanks for helping me think about this stuff. Sometimes I am way down in the relay trenches and I have to poke my head up and figure out what's goin on in the client world to make sure I can match to it. 🤙