lol, the websockets are overkill for 90% of nostr queries, really
and it confuses programmers who don't realise they are causing the relays to spawn dozens of threads every time a client connects, that don't shut down unless the client is closed
Discussion
What’s the better option.
use http unless you need server initiated messaging. very simple.
I switched to websockets in my implementation because https long polling was too cumbersome and lots of overhead. Plus, I got real-time duplex for free.
polling is a substitute for server initiated messaging, so that's when you use sockets
it's a shitty substitute also, because it's heavy traffic for usually nothing, and it kills realtime interactive parts of teh protocol
but really, on a twitter clone style UI, when do you even need this realtime stuff? one socket that is running a subscription would sort it out, everything else is driven by clicks
I open a socket, listen for a message, once receive, send and ack, and close. Works pretty well.
liek i said... server (remote) initiated... connection started by local, message sent by remote... this is a subscription
there would be no need for the confusing EOSE if you just cut the protocol in two and socket for subscription, starting now (after eose) and query, for up to now
queries use a different algorithm, they ask the database, where subscriptions are when the server receives messages and they are to be propagated to subscribers
this is one of the dumbest things about the nostr protocol, using sockets to do queries and then assuming that the client wants to subscribe when usually they don't, and often aren't even listening for them, but they hold the socket open anyway
I just implemented what I needed for Step 1a and 4a in the interaction diagram. The rest is good ole https gets and posts.
https://github.com/trbouma/safebox/blob/nauth-refactor/docs/NAUTH-PROTOCOL.md
Interesting. I caught up on this thread because I was the person who pointed Tim towards Websockets / SSE for his ongoing projects. I also believe in only using the most basic tool for the job, but do you think that it's less complex for clients to make one query, wait until it's resolved and then make another?
I think that EOSE is a fairly useful tool to combine those two requests into one, and any half-decent implementation can send a CLOSE after that point if they aren't interested in subscribing.
Yes, I am very grateful for the tip, and it has paid back in dividends. I use it only very sparingly.