jimbocoin on Nostr: I’m not sure. I’m going to give you a full answer at the risk of saying too much. ...

I’m not sure. I’m going to give you a full answer at the risk of saying too much.

There are two layers of authentication in the Nostr protocol stack:

- HTTP - This is where the 403 comes from.
- Nostr (specifically NIP-42) - AFTER the HTTP connection, relays often ask clients to identify themselves, which determines what events they’ll send/receive from the client.

You can think of this like a bar. There’s the outer door (HTTP/WebSocket), then there’s the bartender (Nostr/NIP-42) that checks your id and only serves you drinks if you’re old enough.

Typically, relays will be permissive at the HTTP layer (let any client “connect”) and then rely on Nostr-level authentication to determine level of service.

If you’re seeing 403 errors, that means that the relay is rejecting your connection even before getting to the Nostr authentication part. The bouncer isn’t letting you in the establishment.

Speculation:

It’s possible that the relays are rejecting regular HTTP(S) requests because they expect only full WebSocket requests. This is like a dress code. Shirt and shoes (WebSocket) required for entry.

Technically speaking, the Nostr protocol only requires WebSocket support, so a relay COULD reject non-WebSocket requests and be compliant.

It could be that your client is sending feeler requests ahead of your actual WebSocket requests. This is like sending a kid in swim trunks to check if the bar is open. He never gets past the bouncer (403 Unauthorized) even though you’re ready to party (WebSocket) and would have gotten up to the bar just fine.

So if your client is making regular, non-WebSocket HTTP requests before connecting the WebSocket, I would argue that the client is perhaps misidentifying strictly compliant relays as “down” or unavailable.