I GET THE SAME IMPRESSION.

I suppose it has something to do with wanting to avoid centralization around REST HTTP servers, but I don't quite see how WebSocket is fundamentally any better. 

 Seems like it’s way rougher on both the server and the client too, having to persist all those connections. I guess it does have the benefit on a few queries of not having to AUTH for each one, but how many operations truly need AUTH? Reads are open usually. 

Would also possibly uncomplicate some privacy things, like making it easier to do tor and i2p wouldn’t it? 

 Auth isn't that resource-intensive if you use a JWT or similar.  No HTTP server is asking for a complete OAuth flow on every request.

I don't know enough about Tor and I2P to know whether HTTP servers would make that easier.

I do know HTTP is a heck of a lot easier on client developers.  I am planning to support HTTP servers for some Nostr functionality in the future.  Maybe we can make a dev kit bundle that makes it easy for relay operators to add an HTTP surface to their relays, so it can stay decentralized. 

 but how do you get live subscriptions then? 

 How live matters? There are a ton of social apps that use REST. You can fire refreshes on a timer, and on a pull down at the top of the feed. I can’t think of a single time new notes popped in live and it ever seemed “better” to me. 

And it’s more logic for client devs to keep scrolling positions right in many cases. 

There may be use cases outside the social “twitter clone” style where it really matters, but I’m with @Michael J on this one, having both options would be really nice for clients to have the choice. 

 but more options means more work for all relays, and doing database queries every second on behalf of a client that does constant polling for new events would kill a relay, while live subscriptions are simple and easy, the client doesn't have to update the scrolling, it can cache the live updates locally then display them when the user clicks or refreshes  

 why do you say that? 

 Because we’ve built everything around websockets and a custom way of performing queries. 

 does REST have a standard way of doing queries? 

 The ONLY reason that nostr is not a REST API is because it is meant to be publish-subscribe.  You subscribe to a set of filters, and stay connected, and as matching events show up they are shuttled down that connection to your client.  With a REST API, the client would have to keep coming back, "polling" which would create periodic lookups on the relay even when nothing is happening.  Also, clients would need to make new connections to make new requests, which is a lot of overhead.  There are hacky ways to try to get REST APIs to stay connected and poll, but I'm not entirely sure they are reliable.

HTTP REST APIs are useful. @fiatjaf proposes one here https://github.com/nostr-protocol/nips/pull/1325  and there is a NIP for HTTP AUTH here https://github.com/nostr-protocol/nips/blob/master/98.md

IMHO the ideal transport would be WebTransport, but that is too new, and barring that Websockets is the next best choice.

The downside is that some people don't have as much knowledge of websocket libraries and their usage as they do of HTTP REST. But that is easily solvable.