This is most likely a cope, get gud, websockets IS http, etc. Nostr needs millisecond timestamps.

It's already added because there are mutliple clients using it. That's how I get the e-paper stuff to work. They can't deal with websockets.

Only the handshake is HTTP. They switch to WSP, after that, and are full duplex.

Nice, is there a standard?

Websockets set a false expectation that by subscribing you will keep receiving data, which fails in many situations. Now you need to use more libraries to deal with that. Everybody knows curl, nobody knows nak.

Nostr should have supported TCP sockets from the get go actually. But I prefer websockets over http.

I hand-rolled a simple API that only reads from a website, so that you can download the e-books we're printing as epubs and mobi/AZW3. Had to strip the whole site down. No Javascript, websockets, nothing. Just HTML and HTTP. There's no standard. @ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ and I have done some fiddling with Rest, for a while, is all. We are trying to get Nostr onto more different types of machines and deal with the sort of slow Internet that I regularly have to deal with, in my region. Websockets sometimes result in my seeing a blank page because they time-out over and over.

There are lots of OtherStuff use cases where speed is less important than persistence and reliability of the connection. Websockets are an artifact of starting off with Twitter clones. We've already spread out from there. Since there are Nostr clients and relays using the other protocols, they already count as part of the Nostr protocol. As per the Nostr rules.

(unix)sockets were there before http tho but I get it, some knowledge is just lost now.

I'm dumb and ignorant, give me http

http is good. (and also a socket, just with comm schema/protocol and connection closed after a response, which poses significant overhead for a new connection per request)

Http is synchronous and stateless. Nostr is asynchronous and stateful.

What does that even mean

It depends on the usecase and thats why i'm saying we should have both

indeed