btw, i'm just gonna say it again but the slavish use of websockets in nostr protocol also introduces hellish problems for single- and few-threaded client apps like web apps, javascript is terrible at concurrency and that's partly because most websites don't use websockets, and that's why they are so bad at handling this, even with the 3 years of work of nostr client library devs on this task, it's just like trying to use a hacksaw to cut through a log, who would do that?
the inertia of continuing to use websockets and not extend to enable HTTP for clients is only going to see this get worse because i don't see the broader web dev community solving for something they don't ever use, even if it's theoretically possible to do it, the code just hasn't been nearly refined enough, and i would suggest that probably it needs native code to really do it properly
i write concurrent code all the time but i avoid it as much as possible because of how easy it is to get it wrong when a single or couple of threads works fine... and most of that concurrency is hidden within HTTP libraries in Go so you don't even see this, the go devs have ironed out most of the lumps in it, unlike javascript websocket libraries
mleku
npub1fj…mleku
2025-05-30 20:58:26
in reply to nevent1q…n7ay
Author Public Key
npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmlekuPublished at
2025-05-30 20:58:26Event JSON
{
"id": "a88536adfed119a899fc226abfe4ed6dccf86540541a9e658d94a45b6ad50047",
"pubkey": "4c800257a588a82849d049817c2bdaad984b25a45ad9f6dad66e47d3b47e3b2f",
"created_at": 1748638706,
"kind": 1,
"tags": [
[
"e",
"afdaf251a095914d0f9d4ea7cd604092421e6a7569467e8a388bc54eb5c6928a",
"nostr-idb://cache-relay",
"root"
],
[
"e",
"6726df36431c7a2fbd99a35fdec6259a509ac6ca7967fe0c5bb9263cb695afe1",
"wss://theforest.nostr1.com/",
"reply"
],
[
"p",
"fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1",
"",
"mention"
],
[
"client",
"noStrudel",
"31990:266815e0c9210dfa324c6cba3573b14bee49da4209a9456f9484e5106cd408a5:1686066542546"
]
],
"content": "btw, i'm just gonna say it again but the slavish use of websockets in nostr protocol also introduces hellish problems for single- and few-threaded client apps like web apps, javascript is terrible at concurrency and that's partly because most websites don't use websockets, and that's why they are so bad at handling this, even with the 3 years of work of nostr client library devs on this task, it's just like trying to use a hacksaw to cut through a log, who would do that?\n\nthe inertia of continuing to use websockets and not extend to enable HTTP for clients is only going to see this get worse because i don't see the broader web dev community solving for something they don't ever use, even if it's theoretically possible to do it, the code just hasn't been nearly refined enough, and i would suggest that probably it needs native code to really do it properly\n\ni write concurrent code all the time but i avoid it as much as possible because of how easy it is to get it wrong when a single or couple of threads works fine... and most of that concurrency is hidden within HTTP libraries in Go so you don't even see this, the go devs have ironed out most of the lumps in it, unlike javascript websocket libraries",
"sig": "2b8e236570307ffa0a1365b391df06c8901bd52cb3517a126066a6233eb1319ab90b4cf152ffbf71b5c8334f0445ee2a7ed25c5bc567ceaa660684cbc01636a3"
}