Update proposal for SIP-20 to enable two-way communication between Snap and WebSockets #149

david0xd · 2024-10-01T12:42:50Z

This PR is proposal to update SIP-20 in order to support two-way communication between Snap and WebSockets.

Potentially might resolve: https://github.com/MetaMask/MetaMask-planning/issues/3665

david0xd · 2024-10-01T12:44:12Z

SIPS/sip-20.md

@@ -1,22 +1,23 @@
 ---
 sip: 20
-title: External data entry point
+title: Advanced external communication and events


Feels like the name is not reflecting what this SIP really is anymore? Looking for advice to change it if possible. Updated with one of the ideas I had.

Mrtenz · 2024-10-03T08:27:37Z

SIPS/sip-20.md

 status: Draft
 author: David Drazic (@david0xd)
 created: 2023-12-15
 ---

 ## Abstract

-This SIP proposes a new permission that enables Snaps to receive data from external sources.
+This SIP proposes a new permission that enables Snaps to receive data from external sources and send data back to them.


Not all external sources necessarily support two-way communication.

Updated as suggested.

Mrtenz · 2024-10-03T08:28:30Z

SIPS/sip-20.md

+The Snap can then do whatever it wants with the data.
+The Snap can use RPC method to send data back to the external connection (e.g. websocket connection).


Suggested change

The Snap can then do whatever it wants with the data.

The Snap can use RPC method to send data back to the external connection (e.g. websocket connection).

The Snap can then do whatever it wants with the data, and can send data back to the external source if supported (e.g., a WebSocket connection).

Mrtenz · 2024-10-03T08:29:18Z

SIPS/sip-20.md


 ## Motivation

-Snaps are currently limited in their ability to receive data from external sources; they have to rely on user actions or cron jobs to fetch data, so they can't react to events in real time. Snaps also cannot use WebSocket connections to receive data from external sources, and are limited to HTTP requests.
+Snaps are currently limited in their ability to both receive and send data from and to external sources; they have to rely on user actions or cron jobs to fetch data, so they can't react to events in real time. Snaps also cannot use WebSocket connections for bidirectional communication, and are limited to HTTP requests.


Suggested change

Snaps are currently limited in their ability to both receive and send data from and to external sources; they have to rely on user actions or cron jobs to fetch data, so they can't react to events in real time. Snaps also cannot use WebSocket connections for bidirectional communication, and are limited to HTTP requests.

Snaps are currently limited in their ability to communicate with external sources; they have to rely on user actions or cron jobs to fetch data, so they can't react to events in real time. Snaps also cannot use WebSocket connections for bidirectional communication, and are limited to HTTP requests.

Mrtenz · 2024-10-03T08:30:10Z

SIPS/sip-20.md

@@ -111,6 +112,35 @@ The caveats MUST NOT have duplicate objects with the same `url` properties.

 The `url` MUST start with `wss://` which is a protocol indicator for secure WebSocket connection.

+### RPC Methods
+
+This SIP introduces new RPC method for sending data to the external connections.


Suggested change

This SIP introduces new RPC method for sending data to the external connections.

This SIP introduces a new RPC method for sending data to the external connections (if supported).

Mrtenz · 2024-10-03T08:31:38Z

SIPS/sip-20.md

+
+Snap can use `snap_sendData` RPC method to send data specified within request params.
+The proposed RPC method `snap_sendData` SHOULD be a restricted RPC method requiring user consent before usage via the permission system. The RPC method SHOULD only be available to Snaps.
+Snap MUST specify destination which is URL identifier of an external connection (e.g. websocket). Destination MUST be exact match of some of the URLs defined in manifest's permission caveats within `endowment:external-data`.


In theory the same URL can be used twice, in which case it would be ambiguous which one to use.

Should we disallow that in our validation steps or you think we need to design it in a different way? 🤔

Mrtenz · 2024-10-03T08:32:36Z

SIPS/sip-20.md

+Snap MUST specify destination which is URL identifier of an external connection (e.g. websocket). Destination MUST be exact match of some of the URLs defined in manifest's permission caveats within `endowment:external-data`.
+
+The `snap_sendData` JSON-RPC method takes an object as parameters, which has the following properties:
+- `data` (required, `string` or `binary`): A data, which MUST NOT be empty.


Is this necessary when this is already specified by the endowment:external-data dataType?

Hmmm, probably something needs to be mentioned about it 🤔
Made some changes to simplify it. Let me know if you have better idea, I can update.

Mrtenz · 2024-10-03T08:33:13Z

SIPS/sip-20.md

+#### snap_sendData
+
+Snap can use `snap_sendData` RPC method to send data specified within request params.
+The proposed RPC method `snap_sendData` SHOULD be a restricted RPC method requiring user consent before usage via the permission system. The RPC method SHOULD only be available to Snaps.


I think we should just use endowment:external-data for this RPC method as well.

Simplified this specification for a little bit. Let me know if that works better.

Mrtenz · 2024-10-03T08:33:46Z

SIPS/sip-20.md

+}
+```
+
+The method returns a `boolean`, `true` in case of successful delivery of a message to the WebSocket, `false` if delivery was unsuccessful.


Should it throw an error instead if delivery failed?

Yea, good idea. Updated. I'm still thinking what should be the best to return on successful delivery 🤔

Mrtenz · 2024-10-03T08:36:17Z

SIPS/sip-20.md

+/**
+ * A text message sent to a WebSocket.
+ *
+ * @property type - The type of the message.
+ * @property message - The message as a string.
+ * @property destination - The destination web socket URL as a string.
+ */
+type WebSocketOutgoingTextMessage = {
+    type: 'text';
+    message: string;
+    destination: string;
+};
+
+/**
+ * A binary message sent to a WebSocket.
+ *
+ * @property type - The type of the message.
+ * @property message - The message as an ArrayBuffer.
+ * @property destination - The destination web socket URL as a string.
+ */
+type WebSocketOutgoingBinaryMessage = {
+    type: 'binary';
+    message: ArrayBuffer;
+    destination: string;
+};


This can be simplified:

type WebSocketIncomingMessage = WebSocketIncomingTextMessage | WebSocketIncomingBinaryMessage; type WebSocketOutgoingMessage = WebSocketIncomingMessage & { destination: string; };

Good point. I tried to simplify it more by making names more generic. Let me know if you think something like that would work or if you have any other ideas.

Update SIP-20

2f5d588

david0xd self-assigned this Oct 1, 2024

david0xd requested review from Montoya, ziad-saab and a team as code owners October 1, 2024 12:42

david0xd commented Oct 1, 2024

View reviewed changes

Mrtenz reviewed Oct 3, 2024

View reviewed changes

Update and refactor

4eadf99

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update proposal for SIP-20 to enable two-way communication between Snap and WebSockets #149

Update proposal for SIP-20 to enable two-way communication between Snap and WebSockets #149

david0xd commented Oct 1, 2024 •

edited

Loading

david0xd Oct 1, 2024

Mrtenz Oct 3, 2024

david0xd Dec 9, 2024

Mrtenz Oct 3, 2024

david0xd Dec 9, 2024

Mrtenz Oct 3, 2024

david0xd Dec 9, 2024

Mrtenz Oct 3, 2024

david0xd Dec 9, 2024

Mrtenz Oct 3, 2024

david0xd Dec 9, 2024

Mrtenz Oct 3, 2024

david0xd Dec 9, 2024

Mrtenz Oct 3, 2024

david0xd Dec 9, 2024

Mrtenz Oct 3, 2024

david0xd Dec 9, 2024

Mrtenz Oct 3, 2024

david0xd Dec 9, 2024

		The Snap can then do whatever it wants with the data.
		The Snap can use RPC method to send data back to the external connection (e.g. websocket connection).

	Snaps are currently limited in their ability to both receive and send data from and to external sources; they have to rely on user actions or cron jobs to fetch data, so they can't react to events in real time. Snaps also cannot use WebSocket connections for bidirectional communication, and are limited to HTTP requests.
	Snaps are currently limited in their ability to communicate with external sources; they have to rely on user actions or cron jobs to fetch data, so they can't react to events in real time. Snaps also cannot use WebSocket connections for bidirectional communication, and are limited to HTTP requests.

	This SIP introduces new RPC method for sending data to the external connections.
	This SIP introduces a new RPC method for sending data to the external connections (if supported).

Update proposal for SIP-20 to enable two-way communication between Snap and WebSockets #149

Are you sure you want to change the base?

Update proposal for SIP-20 to enable two-way communication between Snap and WebSockets #149

Conversation

david0xd commented Oct 1, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

david0xd commented Oct 1, 2024 •

edited

Loading