The following is a proposal for providing WebSocket functionality to the Internet Computer. The goal is to start as a simple and standalone service - based on what has already been done by Dfinity - and further develop it based on the community’s requirements to eventually become an integral part of the IC, enabling clients to get live updates from the canisters.
The goal of the SDKs is to provide to the client and the canister the same interfaces of, respectively, the traditional WebSocket API and of a WS Server library.
The client uses the SDK to send and receive updates to the canister via a traditional WebSocket interface - wrapped into the IC WebSocket client SDK which handles the connection setup with the Gateway and the canister. The canister SDK manages the interaction with the WebSocket Gateway in order for the latter to get the messages that need to be sent to the clients. The Gateway bridges the two SDKs by connecting via a traditional WebSocket with the client SDK and polling the canister for updates. The Gateway remains hidden to the developers using the SDKs and they only have to implement the handlers for the different WebSocket events - both on the client and canister side - just like they would when using WebSocket on a Web2 infrastructure.
The client SDK provides the WS methods used to handle incoming updates from the canister and send messages to the canister. From a client using the SDK’s point of view, the client is connected via WebSocket directly to the canister.
The canister SDK provides the WS server methods which the developer has to expose via the candid interface. The Gateway calls these methods to manage a client’s connection and get messages for the clients. The SDK provides a structure where the canister can keep all the messages that have to be sent to the clients. Once the Gateway polls the canister, the new messages are sent to the Gateway, each of which is then relayed to the corresponding client.
Ideally, the WebSocket Gateway should be integrated into the boundary nodes and become part of the official IC specification as a new endpoint that clients connect to to get updates from a canister.
However, this is not on Dfinity’s short term roadmap and it is not possible for external developers to contribute to the boundary nodes. Still, the community’s interest for IC WebSocket seems to be high and therefore we should not wait for a full integration into the boundary nodes to start offering such a service to developers.
Therefore, initially, the WebSocket Gateway will be a standalone service - like the HTTP Gateway will be soon.
Our goal is to release a simple and “trusted” WS Gateway in order to get feedback from the community as soon as possible and then iterate to gradually turn it into a trustless component. Once it is mature enough, it could then be integrated first into the HTTP Gateway and then into the boundary node.
In August 2023, we will release the first version of the IC WebSocket. This will consists of both SDKs and WS Gateway. The goal of this first version is to provide the WS interfaces that clients and backend canisters can use to interact with the WS Gateway. These interfaces will hide the inner-workings of the SDKs and the WS Gateway so that these can be upgraded without requiring any changes on the client and canister side.
This version will require the WS Gateway to be fully trusted and it will not be ready for production. However, IC WebSocket V1 will already provide the full WebSocket functionality so that developers can start using it. The trust assumption can be relaxed - at least on the developer’s side - by enabling developers to host the WS Gateway for their own canister themselves. For the others, we will provide a managed solution so that developers can embed WebSocket functionality into their dApps by simply using the IC WebSocket SDKs.
Eventually, in order for the WS Gateway to be fully trustless, it needs to guarantee:
- the canister can verify that the message came from the client
- the client can verify that the message came from the IC
- the gateway cannot read the messages coming from the client
- the gateway cannot read the messages directed to the client
We consider authentication to have higher priority - as not even the IC guarantees privacy today - and therefore the second version of the WS Gateway will enable the messages to be authenticated in both directions. Detailed information on how to do this will follow but we plan to use certification to prove that messages are coming from the IC and traditional query/update calls - directly from the client - to ensure that the WS Gateway cannot impersonate clients. For this version, we will also focus on making the WS Gateway ready for production by adding SSL support and making sure that all errors are handled correctly so that the Gateway can stay up and running. At this stage, the worst thing the WS Gateway can do is to read or block the canister updates to clients - something which the boundary nodes can already do. We plan to have a production ready version of the WS gateway by October 2023.
In the third version of the IC WebSocket, we will tackle privacy and here the idea is to rely on vetKD. Given the early stage of vetKD, we cannot provide a specific milestone for this.
Later versions of the IC WebSocket will focus on providing SLAs, load balancing across multiple WS Gateways, DDoS protection.
This is just an idea of what we plan to deliver. We would like to get feedback from the community as soon as possible so that we can develop a solution tailored to the needs of the developers. You can follow our progress here.
Looking forward to hear what you think