In the short term the WS Gateway cannot be integrated into the API Boundary Node because this decision would have to be proposed and adopted by the community, as API Boundary Nodes will soon be controlled by the NNS.
This implies that only the API Boundary Node image can run on the server which the NNS will elect as a Boundary Node.
Therefore, the only way to put the WS Gateway into a Boundary Node would be to integrate it into the API Boundary Node image but this is not something we can do right now.
However, this does NOT mean that developers must run their own WS Gateway, in the same way as they do NOT have to run their own HTTP Gateway.
Once the the API Boundary Node is integrated into the NNS, both the HTTP Gateway and the WS Gateway will be hosted on separate servers “outside” of the IC.
Dfinity will certainly host an HTTP Gateway - and hopefully also a WS Gateway - but many others will be able to do so. This way developers do NOT have to host their Gateway and do NOT have to rely on Dfinity (or on us) as the only providers of Gateways.
Designing a mechanism for rewarding the providers of WS Gateways (and maybe even HTTP Gateways) is something that we are considering and would be great to hear other people’s opinion on this.
Regarding the guarantees, as of right now, we provide a way for the client and canister to detect whether the WS Gateway acted maliciously (tampered, reordered or blocked the messages) and in the future we could integrate a way to switch from one WS Gateway to another in case malicious behaviour is detected. Also, once VetKeys are implemented the SDK and CDK, the WS Gateway will not be able to read the messages it relays and therefore developers can consider it as a fully trustless intermediary.
Let me know if there is something I missed.