snaps
snaps copied to clipboard
Update SIP-20 for Accounts requirements
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.)?
- Potentially build connection revive mechanisms (reconnect).
- What if WebSocket connection is broken because (server closes connection, internet connection issues, etc.)?
- Message delivery
- Receiving messages
- Interrupted message delivery to Snap (message can be lost).
- Browser closed within delivery process, etc.?
- Interrupted message delivery to Snap (message can be lost).
- 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.
- Receiving 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)
- Connection drops
- 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.
Closing this in favor of https://github.com/MetaMask/MetaMask-planning/issues/3665