Given that Snap is not meant to be directly communicating with WebSocket server, it is the responsibility of our internal controllers to maintain the reliability of the connections and messaging process (e.g. ensure reliable way of message delivery to the Snap or WebSocket server).
Here are some potential concerns and requirements to be discussed before building this feature.
Potential reliability issues
Connection drops
What if WebSocket connection is broken because (server closes connection, internet connection issues, etc.)?
Interrupted message delivery to Snap (message can be lost).
Browser closed within delivery process, etc.?
Sending messages
Interrupted or unsuccessful message delivery to a WebSocket.
Message delivery requires WebSocket connection to be already open and initialized if needed. This is prerequisite for sending messages.
Connection initialization requirements
As previously mentioned in a potential use case discussed on Slack, WebSocket connection might need initialization process (e.g. sending account address to the WebSocket in order to subscribe to specific data events related to that account)
Use case study
Potential use case documentation would be very useful. This would help us to identify potential flaws, demands or obstacles that we might encounter on the way. This is something that possibly cannot be easily covered by SIP initially, but rather identified as an implementation requirement at first based on the use cases.
Given that Snap is not meant to be directly communicating with WebSocket server, it is the responsibility of our internal controllers to maintain the reliability of the connections and messaging process (e.g. ensure reliable way of message delivery to the Snap or WebSocket server).
Here are some potential concerns and requirements to be discussed before building this feature.