Nostr Web Client

Makes sense now why nostr:npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmleku has been saying all this time that clients do not implement AUTH properly. I think it's a big misunderstanding. His issues would all be solved if only he answered to all queries with the "auth-required" thing.

Silberengel 11mo ago

Perhaps this all needs to be clarified in the NIP. I also have had trouble implementing AUTH. It still doesn't work consistently, with some relays or clients I use, even though nostr:nprofile1qqsqvcu68pkfcyq5y9mz9n9u7sys33835rpnuglc6mtg7j4lv40c7ugpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3vamnwvaz7tmjv4kxz7fwdehhxarj9e3xzmnyqyg8wumn8ghj7mn0wd68ytnhd9hx2erc6wa has been legit on top of things and trying to help me.

I'm not necessarily convinced that we need an extra notice. And it's been frustrating to see how slowly a relatively simple, important NIP has been propagated, and that might be due to a lack of clarity and completeness.

nostr:nprofile1qqs8qy3p9qnnhhq847d7wujl5hztcr7pg6rxhmpc63pkphztcmxp3wgpz9mhxue69uhkummnw3ezuamfdejj7qgmwaehxw309a6xsetxdaex2um59ehx7um5wgcjucm0d5hsz9nhwden5te0dehhxarjv4kxjar9wvhx7un89uqaujaz how is your AUTH implementation going?

Reply to this note

Please Login to reply.

Discussion

fiatjaf 11mo ago

We don't need a NOTICE, what NIP-42 says is that the relay must answer with a CLOSED or an OK with messages prefixed by "auth-required:".

Silberengel 11mo ago

Okay, we'll do an in-project review of the NIP, with our relay and client devs, and maybe test it with some Gherkin. We needed to do that for Aedile, anyway.

We'll see if we can get the interop smooth, with the current state of the NIP, and submit PRs to the various client/relay repos and/or NIP repo, if we find inconsistencies.

This should be a solvable problem.

MichaelJ 11mo ago

As we shift towards SDK development in Aedile, these standards are going to become way more important. I think we should host Gherkin write-ups of the NIP specs on Alexandria's relays as we determine the implementation details for our SDK.

With expected behavior precisely defined in Gherkin, we can go back-and-forth with the other devs to figure out if the Gherkin scenarios actually match the implementation and usage "in the wild," and work on updates or clarifications to the NIPs from there.

I've already written up some Gherkin for NIP-46. I think NIP-42 will need the same treatment.

elsat 11mo ago

https://github.com/nostrability/nostrability/issues/163

elsat 11mo ago

nostr:npub10000000thpep7auj058803nqtymqlf3rw87lzhe6mkfeywnpxg5sjw7nql any ideas of expected nip-42 behavior for apps, relays that we can specify?

semisol 11mo ago

Client SHOULD authenticate with NIP-42 when they receive an AUTH as that indicates that there may be additional features available post-AUTH.

Such as prioritized responses, access to certain content (no, refusing an entire request with auth-required does not work, and neither does trying to figure out what requests want what with heuristics)

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 11mo ago

i know, that's why my relay doesn't work with the shit that NDK uses

MichaelJ 11mo ago

In Aedile? Haven't started yet, focusing on Alexandria.

For Alexandria, I'm currently just using NDK's default AUTH policy, and it seems to work well enough. I think nostr.wine handles it a little differently, so sometimes it bounces REQs even after the client has AUTHed.

Silberengel 11mo ago

Yeah, 🍷 is the one I can't get to work.

MichaelJ 11mo ago

Wine might be handling auth differently than others, then.

Silberengel 11mo ago

They were one of the first implementations, so they were winging it.

Mazin 11mo ago

Any idea what the issue is? We updated it when they added CLOSED.

When a REQ is sent that requires AUTH and the connection isn’t authenticated, we send an AUTH challenge and a CLOSED with "auth-required: this relay only serves private notes to authenticated users"

I believe that is the expectation in NIP-42 - unless it changed again.

fiatjaf 11mo ago

Nothing has changed, this is the correct way.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 11mo ago

i think the problem has to do with a misunderstanding of client devs about how sockets work

the socket is a modal interface. it has a state, ready, and there are requests and responses... the way the nip-01 is written this categorization is not clear, so i can understand how this problem arose

it is very clear when you read the code that nostr:nprofile1qyd8wumn8ghj7mr0vd4kymmc9enxjct5dfskvtnrdakj7qg6waehxw309ac8junpd45kgtnxd9shg6npvchxxmmd9uq3kamnwvaz7tmjv4kxz7fwwajhxar9wfhxyarr9e3k7mf0qyfhwumn8ghj7am0wsh82arcduhx7mn99uqzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vac7xr2j wrote for auth - a SOCKET is authed, not a REQUEST

if the client wants to make a request, and for example, the relay says it's "write-restricted" as in nip-11 (i need to add this to realy because i think this is relevant, write-restricted should also be part of the complex of elements in AUTH because what that means is "auth-required" to WRITE.

so i might go further to suggest that in the nip-42 text it should also mention that "restricted-writes" or whatever it is called, indicates that the sockets are modal upon AUTH, as in, when a socket demands AUTH it is because the request is "auth-required" which can be both read (req/count) and write (event)

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 11mo ago

I think this needs to also touch nip-11 and the "restricted_writes" field

auth required is ambiguous because it can mean both read and write

restricted_writes can be used instead of auth_required to signify that a socket doesn't need to auth to do read (req/count) but requires it for event

- auth_required should be specified to indicate for REQ/COUNT

- restricted_writes should be specified to indicate for EVENT

i am making an update to realy to match this clarification, and i hope there will be a revision to nip-42 to clarify the link to nip-11's limits fields and eliminating any confusion about whether NOTICE should be interpreted by clients

NOTICE is text to show in a relay log for clients. PERIOD.

i have realy send these notices because it is implied that if AUTH has been sent by the relay then AUTH must be sent by client or the socket is ded

Sebastix 11mo ago

Still not working?

My test (in PHP) works.. (I've a subscription as well). Please do additional info in the Github issue.