Basically all paths you can connect to the relay
classic example of how retarded the NIP guardians are:
https://github.com/nostr-protocol/nips/blob/master/11.md
> When a relay receives an HTTP(s) request with an Accept header of application/nostr+json to a URI supporting WebSocket upgrades, they SHOULD return a document with the following structure.
shouldn't there be a path qualifier as well? does it mean only for the `/` path or does it blanket cover all possible paths?
i'm writing a router for nostr that also handles websocket upgrades for specific paths
but i think that it's "implied" that they mean the root, or whatever path, that you have set your relay to answer to to listen for websockets
so i think i need to switch on paths first and then protocols
but it's not clear
fortunately almost nobody except nostr.wine uses paths at all anyway (and parameters) so i can pretty much say "nostr+json" is always at "/" so if it's not "nostr+json" then it's not asking for nip-11 info
*sigh*
just saying this because the code in relayer purely switches on the Accept header key being "nostr+json" but it should be switching first on "/" and then "nostr+json"
what this nip needs in that paragraph is "for the nostr websocket path"
Discussion
with nostr websocket protocol, yes, that's the thing
but if it does an upgrade and uses nostr+json that doesn't necessarily mean the path matches a standard nostr-supporting endpoint, it could be a websocket that ONLY does subscription requests and does not have an EOSE, whis is what i have planned for the subscription part of the protocol
also i have an endpoint that specifies to not store but only relay the event as well ("/relay") regardless of the kind and a replace endpoint that acts as though it's a replaceable as well, but those are going to be on HTTP only
the total lack of use of http headers in the existing protocol is pretty sad
i'm going to use nostr+json on http with no upgrade to mean "we are using nostr nip-01 event encoding and requests are expected in the body payload as JSON format"
“fuck you, no one cares about your use case” most people apparently
do not serve NIP-11 unless it is a perfectly functional relay thank you stupid specs
yeah, it's also because nostr doesn't really have an API per se, which is retarded
if you had actual methods with parameters and response types you could simply specify what those are
the shit about geofencing should just not even be available if you aren't in that zone, for example
needing auth could then also be tied to actual api methods, which is one of the things i intend to build out in this simplified hybrid http/ws protocol as well