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
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. 🤙