Nostr Web Client

And to add to this, it's not like EVERYONE has to pay either, you can easily bootstrap the relay with your follows list, and add to it from the secondary when you want to clear someone.. it's mostly for the out-of-the-blue messages, that are still nice to have, but with someone proving they care enough to make a quick lightning verification to @ you

PABLOF7z 1y ago

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.

PABLOF7z 1y ago

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

I don't want to pay in order to tag someone on a post. If such a system is deployed to the level that my client can tell me "that tag will cost you 500 sats", I'll just stop tagging people.

what if it was just a one time payment tho, just like a relay membership to your inbox for 21 sats? I'd gladly pay some sats to be able to tag you or any large account (like jack, fiatjaf, will etc) if I thought it would increase them seeing my message. It's hard to imagine I know, most of us are not that big and don't mind the free spam. But, what if they do? How many GM fiatjafs are you willing to have, when someone writes a GM fiatjaf bot and cuts it loose on you and comments on every one of your notes? Already happens in anything jack posts, I am amazed he even manages to read or respond to anything at all.

There is something I like about the idea, and something I don't like. I think it is worthy of exploration. Right now, however, we have a more pressing problem in that people pick inbox relays that charge, and I have no way through my client (or any other client) to know that I can't contact those users or that I have to sign up to a certain relay to do so. I think the expedious solution is to get people off of paid relays where inboxes are concerned, and your idea is more long term.

Cool, yeah just bringing it up because it sounded like clients were trying to implement gossip and I'm trying to understand the meanings of the 3rd field in the 10002 and why it seems so sparse compared to the various UIs. If I was implementing a client, I'd want to know ALL the current settings from the gossip UI itself, "read, write, inbox, outbox, discover" and I was thinking "paid", "auth" are worthy of having in the field somehow in addition like "inbox-paid" or "inbox-auth" (DMs) that it might be good to think about now before everyone runs off and attempts to implement gossip in their client. Thanks for listening. Carry on. 🫡

Took me a while, but I finally think I understand how relays with Access Control Lists (or paid relays) can do their thing. It's not a gossip related thing, it's simply a client thing. If clients do their normal gossip thing, when they encounter an inbox that is paid, they can simply show this information to the user. Nostrudel has a nice way of popping up this "toast" notification for everytime you publish a note, it shows the relays that succeeded and failed. So if clients just show this, they can say "hey, this note didn't make it to these inboxes because of reason: X" Retry? Visit Relay landing page?

I find myself watching the gossip logfile all the time to see this kind of thing, maybe gossip client can show this user feedback as well in the future, and then there doesn't need to be a disclaimer about using inboxes that have Access control or etc. (Or for upcoming when more relays rollout READ protection via. auth, etc.)

Well, I don't think it can be fixed on the writer-side. If I choose a bad inbox and your gossip notices it can't post there, you are not the one that can fix it, I am. I have to choose a different inbox relay. You would have to contact me and say "Hey your inbox isn't accepting my notes". Few people bother.

Somewhat disagree. Say someone chooses inboxes that require access control. This is on purpose, to fend off garbage and bots. The UI needs to notify the user attempting to send/connect to an access controlled inbox, that there are steps needed to send there.. visiting the relay landing page to see what the deal is, would be one option (the relay is paid, the relay only allows follows, the relay needs captcha, stuff like this)

Oh sure, that's fine. I thought you were talking about how people select which relay will be their inbox.

Because relay rules can be complex, and this is a growing field, I think the most a nostr client should do is

1) Indicate that the post failed,

2) Give the user a link to the relay support page, including information about the post that failed.

Then the user and the relay can "sort it out" using any complex method they want. And

3) Give the user a method to retry the post after they have sorted it out.

My point being that gossip cannot keep up with and implement in-UI schemes for relay payment, captchas, and every other fresh new idea someone comes up with.

NIP-11 doesn't have a general "support" URL, it only has a "payments_url". So maybe we should change that.

Yes, I think we are on the same page. Nip11 does have a link to policy.. perhaps this can be used. For all my relays I make sure the root domain landing page has all necessary info for users to figure it out. And I set all Nip11 fields that are available in the nip. I agree, for clients, there just needs to be ability to click a link for the handoff to 'more info'.

isn't that why you would have several options in your NIP-65 in/outbox advertisment?

also, you know, if the clients would support NIP-42 (does gossip btw?) reading from someone's outbox when one is the addressed recipient should be permissible and could only be gated as such by using NIP-42

implement NIP-42, that's to all client devs, not just you (you know i'm not using yours because i can't test with it)

NIP-42 isn't the only gate. Relays may want you to pay them some sats, or resubmit an event with a minimum PoW, or complete a CAPTCHA, or any number of other crazy anti-spam schemes that have yet to be invented.

Yes gossip does NIP-42. It is nearly essential to nostr at this point.

a better example is, say i only want people to inbox me on nostr.wine. This is already a relay many pay for, and many should pay for. They protect the DMs with nip42, and they're solid. But if i set this as my only inbox, clients will just get silently rejected.

an element of the use cases for NIP-42 nobody except me is always going on about is that it should be required to access DMs. PEROID.

you sign with an npub that isn't either the sender or receiver of the DM... straight to jail

nostr:nevent1qqsww4ytahdxx7fr4hl38py8hmhc2wx2fwcs96awehg24cnsxk9nj5gpzemhxue69uhkyetkduhxummnw3erztnrdakj7q3q0npj3gydmv40m70ehemmal6vsdyfl7tewgvz043g54p0x23y0s8qxpqqqqqqzyh7upc

If I were to add to the "what is wrong with gossip" category here, I am starting to realize that it's paid relays. This doesn't bode well for the direction I'm going with relays as I only want to support paid relays, list based acls, or obfuscated relays. IE, relays that have not been discovered by bad actors, or that have enough barrier to entry that keeping them at bay is possible by one person or small team.

All I mean here, is I think the nip-65 needs to expand to include paid-inbox and/or auth. And maybe the word paid is now frowned upon, by people who don't want to require lighting. So acl-relays? 😅 Potentially need to provide an API or way (event kind) for checking if a pubkey has access to a paid or auth relay..

rustyspark 1y ago

Isn’t this how LinkedIn works today? You get a certain number of unsolicited reach out per month. And beyond that you have to pay for a certain tier, if you want to connect with people more than one or two clicks away from you. Or perhaps if they’ve been more restriction on their account.