Nostr Web Client

I've started programming seriously only 4 months ago, so there are many things that I still don't understand. Here is one:

Why do we always use websocket to connect to relays?

If I have to post or get one single event, why not a single http?

Why do I have to use http, then upgrade to websocket, then send/receive one event and then close the connection?

#asknostr

Five 11mo ago

Ppl have used http to fetch nostr events and I think there are some who still do.

Fiatjaf doesn't like it I know and this has been heavily debated back in the nostr telegram group days.

My guess is this: most apps most will end up keeping a connection alive to fetch multiple things from a relay as user navigates the app and even post things, with relatively high frequency.

Relays want to aim for simplicity mostly so they expose websocket connections to handle the common use-cases instead of having REST too. I think the EOSE is kind of the equivalent to an http response so that you can close the connection if you don't need anything else. Most libs/sdk-s have "closeOnEOSE" option therefore.

Reply to this note

Please Login to reply.

Discussion

Pip the WoT guy 11mo ago

for most kind1 clients I see the benefit of websockets. But when a single request is needed, I think http is just simpler.

Is it true nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 that you "don't like" http? If so, what's the rationale?

Tim Bouma 11mo ago

I use both in my web client. https has a lot of overhead for each request. Perfectly fine for responding to user requests but not great for real-time event-driven behaviour. Sockets is better.

Pip the WoT guy 11mo ago

my understanding is that if the requests are less than 3, or are distributed over minutes, than http.

Else websocket.

wdyt?

Tim Bouma 11mo ago

Yep. Good old https rest api does the job for 95% of the functionality. However, when you need async event driven stuff, websockets is the way to go. For example, when I am waiting for a Lightning payment, I prefer to use a websockets to push the event through when it comes rather than poll for it. A lot less stress on the server.

fiatjaf 11mo ago

If you're going for raw performance and you don't care about backwards-compatibility or about breaking the openness and simplicity of the protocol there are ways to do things that are much better than JSON over WebSockets or HTTP.

Rand 11mo ago

gr8"ways" t y/

fiatjaf 11mo ago

HTTP has too many ways to do things.

For example, to communicate some data to the server you can use:

- subdomains

- URL paths

- URL query strings

- headers

- body (which can be encoded in multiple ways and supposedly you have to tell the server what you're using with a header)

And when you get a response you have to check these places for information

- status code

- headers

- if it's a redirect you have to make another request and repeat the process

- body (which can be encoded in multiple ways and supposedly you have to check the headers to find out, and yet it may be incorrectly encoded)

Tim Bouma 11mo ago

Websockets is way better for listening, when new events come in. Connection is already created. With https you have to do long polling which is resource-intensive.