IC WebSocket: Roadmap

You are absolutely right. We will provide a specification for the CDK and either implement the Motoko version ourselves or find someone else who takes care of it.
Would be great to know what other people think about this. If there is a lot of interest we could take care of the Motoko implementation relatively soon.


Yes exactly, the developer will have to expose some predefined methods on their canister’s candid interface. To have an idea, have a look at the lib.rs file in the example canister on our repo. In the example, the Rust sock module is what from v1 will become the CDK.


That will work.
Can’t we just call the canister methods thru WS gateway instead of having to pass them thru these functions

The WS Gateway is calling those methods exposed by the canister as, for example, you can see from the canister_methods:ws_open function in the Gateway. The sock methods are provided by us to make developers’ life easier, so that they don’t have to write the handlers manually.

Was it clearer? Or am I missing something from your question?

1 Like

I was wondering if the WS gateway can call actor methods directly. It seems currently it is passing messages to the ws_message method. But I guess linking it to actor methods has its disadvantages if doable at all. I would probably use the WS only to send messages to clients from the canister and use HTTP to send messages to the canister.

Thank you @massimoalbarello and @ilbert for picking up the torch and this write-up.

It’s great that this is getting built in public and there’s a chance that other developers chime in helping to build libraries or CDKs in Motoko, TypeScript, Python, and C++. As well as integrations of other protocols next to WebSockets eventually.

One interesting (research) question for the roadmap is to find a model of how we could incentivize many independent gateway providers. I think there are some case studies in the greater web3 ecosystem that could be studied.


Yes, the incentive mechanism is something that we always have in the back of our minds. Will definitely get into it after V2


Very important piece of ICP puzzle. We are planning to add support for WebSockets to our IC4J Java agent ASAP. I see many interesting use cases, especially in integration with external resources, like Apache Kafka topics.


Great news. Without a doubt, this functionality will be very useful. Congratulations, very good job

1 Like

IC4J Agent can provide direct access to WS Gateway, similar to JS Agent. IC4J Candid implementation has also implicit serialization/deserialization between Candid and popular Java types (JSON Jackson/Gson, XML DOM/JAXB, JDBC, React Native).

1 Like

Would be nice to also have Candid IDL description of WebSockets interface.

1 Like

I would probably use the WS only to send messages to clients from the canister and use HTTP to send messages to the canister.

That’s also what we are thinking about: you create an instance of IcWebsocket and whenever you call ws.send we use the canister actor you passed to the constructor to call the ws_message on the canister, skipping the gateway.

However, calling directly your methods on the canister (either from the gateway or the client as we said before) instead of the predefined ones is tricky and you would need to implement the CDK handlers inside your methods, by changing the logic.

1 Like

Yes that is something we have to provide in the documentation, because developers must implement the ws_* methods on their candid interfaces.

1 Like

I think the proposal is well written, looking forward to your work here :slight_smile: I like the iterative approach and also the targeted early community involvement. Some other things that came to mind;
Who will set up, own and run the gateway hardware for the managed solution?
If I host the WS Gateway myself, what kind of hardware requirements are in place? What’s the most likely solution where to host it?
Would WS Gateways have to be approved by the NNS? Which changes related to the proposal have to be approved by the NNS?
Could the DDoS protection or part of it be provided via the current Boundary Node (if I remember correctly, there is some DDoS protection in place)?
Will the scalability of the WebSockets mostly depend on where it’s hosted or which factors influence this? Is there some inherent limitation to this caused by the Internet Computer (Boundary Nodes, canisters or network)?
Will the SDKs be separate ones or integrated into existing ones?


Initially, we will host a WS Gateway ourselves on AWS just to start getting feedback. Depending on usage and requests from the community we will start figuring out how to decentralize it.

The idea is to keep the WS Gateway as light as possible so for self-hosting the hardware required will depend on how many clients connect to your canister. We will host a high-end WS Gateway which will be shared by multiple canisters. What this will look like in practice depends on the demand that we get for it.

No, WS Gateways do not require any approval from the NNS. In the long term, the WS Gateways could be controlled by the SNS but there is a lot to do before that.

No, the WS Gateway is before the Boundary Node (from client to canister) and therefore will have to have its own DDoS protection.

The WS Gateway will have some upper bounds on the number of clients/canisters that it can be connected to but we do not know how much this is for now. However, each WS Gateway is independent of the others and so its easy to scale out.

The IC WS is a service offered independently from what Dfinity is doing and thus require different SDKs.


Thanks, that sounds good. One follow up question; will the managed WS Gateway be open for all canisters to use or will only whitelisted canisters have access to it?

It will probably be open for all canisters, but keep in mind that the canister will have to implement a specific Candid interface for the WS Gateway to be able to interact with it.

1 Like

As a workaround while the Motoko WebSocket CDK is developed, a “middleware” Rust canister could be deployed, whose only function would be to act as a relay for WebSocket messages between your Motoko canister(s) and the Gateway.

How do you see this temporary solution? I understand it becomes more expensive due to inter-canister calls…

In general, this could be the workaround for all the canisters that for some reasons (you don’t want to refactor the code, etc.) won’t use the WebSocket CDK.

Beta release is available here :slight_smile:


The stable release of IC WebSocket is ready to be used in your canisters!