I know you put a lot effort in that. And it's awesome (and send you some palindrome sats when I learned) via your crowdsource.
I think that the relays should signal this interface with denial of upgrade to websocket.
I'm no fan of SSE either. I think clients responsibility what to fetch, how and when.
subscription is an option, i specifically separated it from the filter endpoint, unlike the REQ of nostr protocol which is a filter, and then a subscription, and the dumbass client devs can't comprehend this, and it's messy
subscription is better than polling, both in latency of messaging and a solution for propagating data on demand without pushing it, people ask, and then you SSE and done
the actual SSE protocol is just a thin wrapper around what could have easily been line structured JSON, which for whatever reason also isn't widely supported, but the difference is very trivial
you know what JSONL is
just add event: eventype, newline, data: json, newline. same same
the web server just adds to the message as data comes in, it's the same as what you get from a REQ in standard nostr protocol AFTER the EOSE, or if you make a REQ that has a "since" that is very close to now.
You're probably right.
I just somehow don't like the ever opened socket(s). but hey clients can deal with that too.
or even better I'd just change that for DNS protocol 🤪
DNS is an important issue as well. Super controlled.
look, solve one problem at a time
satoshi spent a lot of energy and even basically created namecoin to try and fix this
making a simple uniform, distributable document server protocol, that's the first problem
problem with nostr as it is, it's not simple, and it uses obscure, weird shit in too many places
i'm fine with the bip340 signatures but i'm not cool with the envelopes, at all, not one bit, they are awful, and rigid and hard to extend
we already have http paths, i mean, duh. REST?
It's on my list of issues just after IANNA
but not what I meant. I think DNS protocol is awesome and efficient way to query data.
