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.
Discussion
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.