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