Nostr Web Client

not happy this friday, i'm over this bullshit

QW 11mo ago

Speaking freely is the way. Thanks for the vent.

verbiricha 11mo ago

bro u need to touch grass

It's a problem, for our project, if our devs are not taken seriously and have their technical issues addressed because it prevents our implementations.

There is a reason he is so frustrated.

verbiricha 11mo ago

I'm sure there's a reason, nostr the protocol and the software we are building is a work in progress and it's normal to run into issues, corner cases and incompatible implementations. Civilized discussion, patching the bugs and improving the relevant specs we can move things forward. Sperging out and insulting people and their work ain't gonna solve anything.

No, and we're eager to solve it constructively, but it doesn't solve the problem to dismiss a complaint because of tone or because the person voicing it isn't viewed as being "important" or "popular".

A problem either exists, or it doesn't, and this one exists.

there is no pagination

we could at least have a query that returns event IDs as an array. minimum

I also want this. It's incredibly inefficient to always get the full json dumped out for a big REQ and then have to parse the events out to build an array.

Do you know, nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn?

Please tell me what nostr-tools is doing that doesn't work with your relay.

hzrd149 11mo ago

I'm not sure exactly, but I think it has to do with how the AUTH message is understood in different clients and relays.

It looks like wss://mleku.realy.lol responds with an AUTH message when the socket opens and then doesn't send anything until the client responds with an AUTH

This probably doesn't work well with clients or libraries that are built expecting a NOTICE "auth-required: " message as a signal to authenticate

This seems to be an issue on both sides though, because I've started using rx-nostr and its implemented the same way. it considers AUTH messages to be a signal that the relay is asking for auth without waiting for a NOTICE "auth-required: "

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.

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?

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:".

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

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

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)

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.

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

MichaelJ 11mo ago

Wine might be handling auth differently than others, then.

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.

Nothing has changed, this is the correct way.

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)

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.

cloud fodder 11mo ago

nowhere in nip42 does it mention responding with a NOTICE.. i dont do this but i was thinking about it in addition to normal auth. is that what y'all expect now?

cloud fodder 11mo ago

if i understand mleku's he sends the auth in addition to a notice. cause he says clients are more likely to stop spamming that way.

hodlbod 11mo ago

I think there's room for both, clients can respond or not depending on how aggressively they wan to auth. If there are implicit access controls going on, the relay may choose to respond with some subset of data without notifying the user. Or it may notify so the user knows to authenticate because they're missing out.

hzrd149 11mo ago

This is the way I've implemented it in noStrudel. There's an option to enable signing auth as soon as it's received. But generally it waits till it sees a auth-required response

hzrd149 11mo ago

Your right. I made a mistake, it's not NOTICE, I meant OK and CLOSE

Nice and Kind Vic 11mo ago

wtf? if this is expected behavior can we get it documented as such? devs are out here trying to reverse engineer the protocol becauase of incessent cowboy coding practices and shoddy nip docs. thanks for your insight on possible solutions

Robertrobert 11mo ago

Shots fired!

shinohai 11mo ago

neperj ♣️ 11mo ago

your relay also doesn't work on nak

BITKARROT 11mo ago

can you please rename yourself to 'Grumpy Cat'?

I much enjoyed it.

Rand 11mo ago

772f9545... 11mo ago

Because I have followed you for some time now and had a few interactions, I know that your message here is sincere in the moment and that you are probably going to be calmer in some time, and that nostr will be better off for both.

we are building a new nostr, with blackjack and hookers

whit 11mo ago

Thanks for proving why people are ….

not sure if you mean i am a cunt or if what i discuss is proof of this fact

but it's a thing... and there is lots of subtleties around this all that require discussion and examination... the history of nostr as i have witnessed is full of several examples of how cunty some kinds of people are and how they manage to get credibility despite being cunts. my life's mission is to rug them

whit 11mo ago

I think everyone is everything all at once. Humans always human. We all have good and bad within us. Most people just want to be seen and accepted for who they are. Some want to be left alone.

We can choose to respect 🫡 & have reverence for others even if we don’t agree with them. Wild world we live in.