The client is my own (alphaama) and it doesnt use ndk. The relay worker is not dying, only some relays disconnecting which triggers reconnection. Im not ruling out my own code fault but it works fine ...
i think "most relays" are the rust relay these days. strfry is lagging.
if you are building clients then i'd recommend that you examine the state of the service workers that are being used. race conditions are a plague in javascript/typescript code and are extremely hard to find even in simpler languages like golang, in javascript with all that async promise stuff, it's even worse. it's a bad execution model - event driven is far simpler to reason about. you simply don't have the option to do that with vanilla web app programming languages, without creating a lot of extra code to handle that properly.
this is why i made moxie and it has the moxiejs runtime code shims that construct a simple event driven dispatch loop model. https://git.smesh.lol/moxie the other thing is Manifest Version 3 runtimes are aggressive at terminating the service worker so if your relay access in the client is being done that way (pretty much has to be) then that's why i'd also suggest you go look at whether you can force it to use MV2. MV2 doesn't permit the browser to arbitrarily halt or terminate your service workers. that's why https://smesh.lol uses it, which is also built in moxie and though i know it's still buggy, you will notice if you use it (only works on firefox based browsers) that it is very fast at grabbing events and accessing cached events.
it's a very hot subject for me at the moment, i'm working intensively on it because i got sick to death of both service workers dropping out and dropping relay connections and subscriptions, and slow and unreliable access to storage.
the trajectory of web browser runtimes is on a downward track as far as i can see, and that doesn't include the also downward path htat the ever increasing complexity and neverending stream of ever more complex NPM packages are adding on top of the broken foundation - more broken now than it ever was before.
if you are building clients then i'd recommend that you examine the state of the service workers that are being used. race conditions are a plague in javascript/typescript code and are extremely hard to find even in simpler languages like golang, in javascript with all that async promise stuff, it's even worse. it's a bad execution model - event driven is far simpler to reason about. you simply don't have the option to do that with vanilla web app programming languages, without creating a lot of extra code to handle that properly.
this is why i made moxie and it has the moxiejs runtime code shims that construct a simple event driven dispatch loop model. https://git.smesh.lol/moxie the other thing is Manifest Version 3 runtimes are aggressive at terminating the service worker so if your relay access in the client is being done that way (pretty much has to be) then that's why i'd also suggest you go look at whether you can force it to use MV2. MV2 doesn't permit the browser to arbitrarily halt or terminate your service workers. that's why https://smesh.lol uses it, which is also built in moxie and though i know it's still buggy, you will notice if you use it (only works on firefox based browsers) that it is very fast at grabbing events and accessing cached events.
it's a very hot subject for me at the moment, i'm working intensively on it because i got sick to death of both service workers dropping out and dropping relay connections and subscriptions, and slow and unreliable access to storage.
the trajectory of web browser runtimes is on a downward track as far as i can see, and that doesn't include the also downward path htat the ever increasing complexity and neverending stream of ever more complex NPM packages are adding on top of the broken foundation - more broken now than it ever was before.