Nostr

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"

semisol 10mo ago

“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

Reply to this note

Please Login to reply.

Discussion

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 10mo ago

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