Agreed. Retail is buying ETF IOUs this cycle, perhaps.
And complaining will restart once fees go back up. Like clockwork.
I like to poke my finger in things. Recipe for #bagels soon.
https://video.nostr.build/d872aa93a4386199b65b641d2b7451dfab72faeaf2cf780b2b6af89c547d8463.mp4
https://video.nostr.build/a9f6b78a8dd988a8982872db5d5a095c33c974beef93328ae3f5f251d48adbff.mp4
Ok so I'm a bagel baking dumbass... this dough gets boiled prior to this stage, yes?
Ah yes, makes sense. I think a web client would be well advised to install a Lookup NPUB button that does a direct GET to a profile URL. I'd imagine 80% of the traffic are lookups from Twitter npub shares.
So what is the true requirement of a web client - to serve up the static html/css/js and the browser does the work from there? This should be a nothing-burger unless I'm missing something.
My mistake, i do see lots of websocket connections to relay nodes in my browser when using iris.to, for instance. I would presume all web clients do this or at least the better performing ones?
Snort is a web client. The convenience of running a web client means the back-end server is doing some work on your behalf, connecting and posting to relays, making certain UI behaviors more efficient, etc, as browsers cannot directly participate in the protocol.
To be honest, i need to study up a bit more on the protocol itself. Will it scale? Do relays have persistent state that needs to be queried and fetched by clients (to populate parents and their parents in a thread?).
UDP is fast and lightweight despite requiring potential retries. Might be of benefit for certain types of devices. Nostr seems pretty heavy when factoring in all the nip-5 / key lookups and such.