I think the proposal is well written, looking forward to your work here 
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.
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.