[Feature Request] A new option or function to stay offline when disconnected during specific situations

[vrtmrz]

Hello! Nice to see you all again!
And, (possibly again but) let me introduce myself. We are creating the plug-in Self-hosted LiveSync which synchronises Obsidian Vaults between several devices, using a peer-to-peer connection.
Of course, trystero is tremendously fantastic for making this possible more securely. Thank you for your great work!

However, there is a minor issue. It is trivial and does not affect the core synchronisation, which works perfectly. And I hope we can find a solution.

If we disconnect the sockets, or are disconnected from the network, reconnection is always attempted after a timeout in the current implementation. In web apps, this is desirable behaviour that makes things simple and efficient. Also, they will be disconnected upon page-reload or navigation.

On the other hand, Electron Apps, and mobile apps always maintain the connection even when it is not actively being used. This is probably the same for PWAs. In this case, especially in mobile, the device may not be able to sleep properly, or may not be able to resume after sleeping. It also consumes a small amount of extra data.

Therefore, I would like to propose an option to temporarily disable automatic reconnection.

I think it seems simplest to really pause/resume the reconnection rather than initialise and recreate the client. I have implemented it as follows, and it seems to be working as expected.

https://github.com/vrtmrz/trystero/blob/942a973f1e7eedc5b3151452b790e2196bea4fa7/src/utils.js#L76-L115
https://github.com/vrtmrz/trystero/blob/942a973f1e7eedc5b3151452b790e2196bea4fa7/src/utils.js#L123-L128

May I ask what you think? If you think this is a good idea, please consider this feature.
And, if you are happy with my implementation, I would also be glad to create a pull request.

[dmotz]

I think this makes sense, and thank you for suggesting it and writing a patch. My main suggestion is: should we make this behavior automatic rather than manual? It seems that this behavior is desirable in any case, as failed socket connection attempts aren't ever valuable. Therefore I'd propose calling pauseReconnection() and resumeReconnection() automatically via global event listeners for the 'offline' and 'online' events respectively. That way the library API doesn't expand and app authors don't have to manually set up this logic themselves. However, I could be missing a special case you have in mind, so feel free to explain why pause/resume might need to be manually called. I realize Node doesn't have this event, but it seems less relevant there and could be polyfilled.

[vrtmrz]

Sorry for being late! And, thank you for your thoughtful feedback! I think that is a brilliant suggestion.

I agree that making this behaviour automatic, based on the device state. It is also so helpful for the major cases.

I wonder, however, if there might still be a case for an optional, manual override. A user might be aware of their network's specific conditions in a way the library cannot be. Although the device is technically 'online', the user might consciously choose to prevent reconnection attempts.

Examples of such situations include when the user had switched the network to:

• on a metered connection and wishes to conserve data,
• connected to a network that is particularly slow, or
• using an unreliable network, they do not trust (Yes, mostly cases, connected WebRTC connection can be trusted, but reconnected WebSocket is not on these).

Perhaps the best approach would be a combination of our ideas? The library could handle the online/offline events automatically as you proposed, whilst also offering an explicit API for the user to manually disconnect and reconnect when they deem it necessary.

If we were to go down that route, I also agree that a more explicit API, such as disconnect() and reconnect(), might be more appropriate than my initial pauseReconnection() suggestion.

I would be very keen to hear your thoughts on this!