Nostr Web Client

No one pays attention to NIP 11 documents because they rely on manual updating. Self-describing metadata is only useful if it's reliable.

Reply to this note

Please Login to reply.

Discussion

so how does any client register that a relay requires payment? by it responding with an auth challenge?

i think the spec NIP-42 spec is pretty clear about this so i don't understand why some clients show the relay is a paid relay but how do they know that?

nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr how does nostrudel determine that a relay is a paid relay???

please don't let me down by saying you hard coded it!

Probably with the nip 11 document. Coracle doesn't do much on this front, but I should. Doesn't change the fact that clients need to be able to ask forgiveness rather than permission.

i'm not gonna push this question any further, i can see what's going on here

i naively thought you people cared about this getting traction with businesses, but you clearly are happy to keep living of VC and bursary grants

We're rebuilding the internet. Don't expect all the problems to be solved today. Maybe I'll address this after I close the 100+ issues on Coracle's github, or get one or two of my 10+ PRs to the NIPs repo merged. Or if there's someone out there who cares about this problem (you for example), they can figure it out.

i'm here to build the way for people to pay for infrastructure

i was sadly mistaken that was even remotely on anyone's priority list, of course not, you are all living off grants, and that's fine as far as it goes but it's not gonna make this thing stand on its own

I look forward to your pull request

you don't jump to front end dev after 8 years building backend server stuff and low level GUI implementations

i thought it was all obvious that this protocol needed to have people paying for relays and clients but seems like nobody cares about the back end and nobody has actually thought about how this thing can fund itself

i was wrong

I literally talked about this with Cloud Fodder on TGFN a few weeks ago, so no, I don't think "nobody cares about the back end".

nip11 is what tells clients it's paid or not.. most clients i've seen parse this and display accordingly 1) that it requires payment, 2) the amount and 3) the place to go to pay (a URL)

and that will make them respond to NIP-42 auth challenge i suppose

got it

i'm in dev, giving a url and all that stuff seems very extraneous to "must auth" but i'll figure it out, will play with it tomorrow

the API is a dog's breakfast anyhow. auth to what... pay to what...

well, auth is a little different as a client doesn't even have to see the nip11 they will receive the NOTICE and either be confused and crap out, or continue with an auth flow.. the relay will act accordingly by closing their stream till they auth, or sending them results that didn't need auth to gather, depends on the situation (kind4 or stuff like that). for payments required we got nip11 and, they will receive a "false" on their attempt to publish, with reason of "gotta pay". From the relay side, it's pretty clear, with nip11 and the various responses/notices, clients can either display these results or just silently get confused. Either way, the data is available in multiple forms (nip11 and response). At least, for my relays. I do override nip11 with custom info and use custom responses from a strfry plugin to be as informative as possible to the clients.

they should just auth. easy as pie. auth. you get auth, you sign event with auth as content wrapped in auth envelope

i can't believe i am 4 months into this and nobody gets this?

you see auth, auth. end of. fucks sake it's not rocket science

That's already, what happens? Heheeee. I don't blame clients too much, the only auth implementations for strfry relays have been closed source and so it's been a long slow road for clients to care about supporting it.. but as far as I can tell, a lot of em do..

closed source

mazin can go fuck himself, i'm pissed and i want a fucking refund

Eh I mean, you were asking about monetization and closed source stuff it's been working for this. Mazin's relay is a top dog relay and getting paid, for value add, with no grants. Same for the rest that kept it closed. Can't fault em for that I think. Eventually an open version will come out or other relay software will support it.

he didn't give anything back up to this point so i'm super dirty on him

doubly so because i PAID him

i believed him and he so fucking betrayed me, he's gonna have to do more than release the source of his shit

i'm gonna actively disrecommend nostr.wine from now on until i get some evidence that he's reformed from his closed source sins

Mazin 1y ago

With a great deal of hesitation towards even entering this conversation the only thing I want to say is that one of the reasons why several clients have NIP-42 is because we (nostr.wine) paid 500k sat bounties per client (Amethyst, Damus, Snort and Iris) and raised a lot of awareness about why NIP-42 matters.

I’m not sure why you think we owe you anything besides a reliable relay.

💯 absolutely zero clients would support auth if it wasn't for Mazin pushing it forward. 🙏

they still don't, unless you put "payment-required": true in the nip-11 as well

why have "auth-required" at all people

and i was railing against the clients up until i learned that one of the mechanisms existing for it, that i have contributed to by paying and using, does not enforce exclusivity of access to privileged messages, and it's closed source

i'm still feeling kinda cold on this because it's not logical, any of it, and it took such a lot of mean words to get anyone to even think about it properly

i've found there may be a bug in my code that is stalling the socket when error conditions occur tho... it does it with duplicate and maybe it also does it by the same mechanism when auth-required comes up

Mazin 1y ago

I replied to this note instead of the other but just want to make it clear that isn’t aimed towards you!

Laeserin 1y ago

Isn't that covered in the server limitations section? Is that what you mean, that these aren't implemented?

there is no specification for what "auth-required" applies nor "payment-required"

just another of the vague stupid things in the spec so far, these are blindspots that people who are being funded by grants don't recognise as important to business use cases (infrastructure i mean)

as a consequence i am getting comfortable with the reality that most nostr devs are isolated from reality and for my current task i've already done enough work to prepare the way for a access control management system, after we are done with the basics (access control is now off the board) then we'll seek more funding to actually develop a client that has some comprehension of "auth to read" and "auth to write" and teh "payment-required" stuff really can at this point be collapsed into subscription model, that is the simplest, lowest frequency way of engaging users to pay for infrastructure

and for business uses, this can be paid for separately, but tied to the user's identity, so there will be some kind of onboarding flow for this use case

but it's not one that anyone in the nostr dev community seems to be even peripherally interested in working on, which is pathetic, and i spit on them all