Websockets have limitations. Most pages only need one or two connections. Pulling down data from many multiple relays via websockets is, IMO, less than ideal and requires way too much computational overhead. This needs to change as TNP (the nostr protocol) matures. We don't need websockets. We won't need dns. Nostr can and should cut out all extraneous, legacy layers for the simplest and most versatile means of notes and other stuff transmitted by relays.
Discussion
i'm working on the HTTP API right now. i've decided i'm not happy with the way that my previous implementation wasn't exactly compliant with JSON Schema so i'm adding some new codecs and annotations so the docs API renders precisely what the inputs and outputs are validated against. it's a bit of work but it will be worth it i think.
by the way, the nostr schema for filters especially is difficult to implement correctly in #golang because of its nonstandard structure. you can't simply define a standard Go struct to cover, specifically, those #a etc tags, which are omitempty and i implemented them as a simple array with the first field being the key and the rest being the other elements of the arrray.
fiatjaf used some custom JSON code generator library for go-nostr but it's retardedly inefficient and slow compared to the code i wrote for handling this stuff.
as i see it, one of the key goals that nostr has is to replace the nonuniform, bespoke real time messaging protocols used in apps like MeisterTask and Figma, that allow collaborative workspaces. for this use case, it needs to be as efficient as possible because latency matters a lot.
Can you share the link to this nip ?
they would never approve one from me, i've publicly expressed my disdain for most of the people involved in the approval process.
doesn't matter anyway, i'm using an OpenAPI library called huma that generates a full and complete specification including (currently working on this part) JSON Schema that precisely specifies the types, key names and documentation for every parameter and result that comes from it.
so once i've completed what i consider to be the base spec (it will replicate all necessary functions, only some small differences like clients only need to open one subscription channel and there will be an endpoint to close specific subscriptions) you will be able to see it all at https://realy.mleku.dev/api and you can already look at the basic stuff that's already now done, but it's a work in progress, it will be more complete soon.
it's taking me a bit longer to do because being compliant with full openapi is actually a bit more complicated, in some ways, than the websocket json api of nip-01.
once it's complete and i have it debugged, anyone who wants to could write one by taking the openapi json/yaml spec, generating all of the handlers and putting their implementation behind it.
it's better than a nip. absolutely clear and unambiguous, and machine readable.
How do you do it without web sockets?
That's a question for someone smarter than I.
But... You can't use nostr directly on lowpower SoCs or micros because of the overhead needed to run websockets. Heck, most e-paper e-readers can't handle websockets very well or at all.
So... Something else needs to replace them to lower the bar of entry to just above smoke signals.