See: Server Sent Events (basic spec for streaming messages server to client) and EventStream (JS)
an example of the retardation of typical nostr clients and auth
#jumble is fine to cope with my #realy when it's set to "public readable" with "restricted-writes" (ie auth to publish)
the relay doesn't demand auth to do req, it has "restricted-writes" in the nip-11, and if you try to send "EVENT" envelope to it, it answers back with "OK",false,"auth-required" and it duly auths and then realy accepts the submission and voila
#coracle is also fine with this
#nostrudel is not
it reads ok, but it craps itself when i try to publish
cc: nostr:npub1l5sga6xg72phsz5422ykujprejwud075ggrr3z2hwyrfgr7eylqstegx9z
this is why there needs to be a fix not just for auth handling in general (they should just all use nip-98) but also there needs to be a proper delineation of API methods being called in "envelopes" because they are ambiguous as fuck, there is really three different semantics to a REQ, a filter, an event retrieval request, and a fulltext (and filter) search
none of the clients even grok the semantics of full text searches at all, but i have figured out that so long as the filter part is reasonably restrictive, ie, it has either authors, a since/until, or some tags, ideally at least two of the above, you can actually implement a "search" just by scraping through the results with a "contains" search on the content fields on each of the space separated string values, and only return the ones that have at least one word match (they could be "relevance" sorted as well so the more words the earlier they appear in the list.
with no need for a stupid fulltext index.
anyway, that's part of what i'm doing with teh simplified nostr HTTP API
i should also mention that it is actually possible to do subscriptions with plain HTTP, just, not simple, because usually servers and clients get cranky about not getting a "Content-Length" header field for the body.
Discussion
#nostronly pls
wdym
these are browser APIs
spec is very simple
disable buffering on your proxy
Content-Type: text/event-stream
each line has a prefix + data (followed by a newline), like so:
prefix: data 1
prefix2: data 2
two newlines = end of message
types:
- event: once per message, defines event type
- id: event ID to be given to consumer
- data: data for event, multiple data lines can exist (they are joined by newline)
- retry: send by itself with nothing else, number in milliseconds to try to reconnect after connection loss
also, have subscription (new events) separate from request (stored events)
what protocol is this and where is the #golang implementation?
i'm in the process of building something like this damn you
oh, reading closer, yeah, nah, your idea is more complicated, pass
it is not really complicated
this is for realy protocol btw not nostr clients
with `application/nostr+json` it requires a JSON body and POST method
what you are talking about is something separate for a different `Accept` value
i'm trying to diverge as little as possible from existing code to make adding this simple
problem is browser won't render them... maybe it would with some CSS juju?
anyway i don't want to be anchored to fucknig shithole browser bullshit
what browser, am i reading my feed as raw json with all the ugly escapes and no linebreaks?
what is a "browser api" exactly?
i don't want to mess with making shitty parameters with ?key=value&... i thought about taht, and i decided no, just simple, post json, return json, that's what `application/nostr+json` means, really, except they didn't delineate between websockets and http request/response