I’ve brought this up multiple times on either Twitter or Telegram or elsewhere…but I’d like to check in on the status of possible WebSocket support.
Is the team working on or thinking about this use case? How would this work? Will it ever be possible for a canister to maintain WebSockets?
Would be interested to know this as well. I can’t imagine any usecases though with update calls taking in the order of seconds to complete. What did you have in mind?
Update calls taking seconds to complete doesn’t make WebSockets much less useful. Clients might want to know when data changes for a variety of reasons, regardless of whether or not it takes 2 seconds for an update to complete.
For example, just think of a simple chat app or forum. When other users submit chats or forum posts, it would be nice to update all clients through WebSockets, so that the clients do not have to refresh the page to see new updates. Stuff like that.
Or I just thought of another, consider a decentralized exchange of some sort. You could have an analytics canister that is always crunching new aggregated data about trades, volumes, etc. The frontend could have data pushed to it whenever certain changes take effect. Otherwise you’d have to always be polling, and there are downsides to polling.
We don’t even have plain HTTP yet, or a non-polling mode to get update calls, so this is certainly a bit further down the road. Not saying it’s impossible, though.
I guess, just like with the request for direct HTTP – it should be possible to prototype that in a community-driven and hosted way, by writing a WebSocket-to-IC bridge (at least for anonymous usage)! So if that’s one of your itches, don’t wait for DFINITY to scratch it, after all, it is supposed to be an open platform. If it proves suitable and uesful, it can then later still become part of the decentralized network itself.
What do you mean by this? Many of these apparently extra-protocol feature requests like HTTP and WebSockets can easily be done by hosting them on centralized infrastructure and just calling into the IC, but that defeats the major purpose of the IC.
Did you have something in mind besides that when you say community-hosted? Otherwise I think what you’re saying is, just build centralized bridges until the IC can suppor those use cases, if ever
Many of these apparently extra-protocol feature requests like HTTP and WebSockets can easily be done by hosting them on centralized infrastructure and just calling into the IC, but that defeats the major purpose of the IC.
That depends on what you consier the “major purpose”. The IC has so many amazing benefits; decentralization is just one of them. Personally, I’d consider tramperproofness a majorer purpose … and that is where HTTP and WebSocket access inherently fall short, because you can’t have both “works with existing, IC-olivious tools like off-the-shelve HTTP/Websocket clients” and “clients can do the checks necessary to verify IC-specific signatures and certificates”.
Now, I also value decentralization. But what I am saying is
It is hard to achieve secure decentralization without custom code on the client, which can, in a tamperproof way, know all the decentralized providers, switch to another one if tampering was detected etc. So I am not 100% sure what a “decentralized HTTP bridge” could mean. The best I can think of right now is a DNS-based round-robin to one of many providers of such a bridge…
Even if it is possible to run such a bridge service in a decentralized way, not much is gained in principle by bundling it with the IC itself. It could very well be an independent decentralized system that then talks the IC protocol. So “communty-hosted” could still be “decentralized” in the sense that there is isn’t a single provider you have to trust.
I think it’s totally fair to begin to prototype such a bridge as a centralized service (like my *.ic.nomeata.de) and “by the community”, i.e. without it beeing an official service initially. This allows us to experiment, learn which interfaces and approaches work best, how big the demand actually is, which features are needed etc.
If these experiments show that such functionality is better run on the same data centers as the Internet Computer proper, it can (and hopefully will) be moved there and run side-by-side with the actual IC.
The Internet Computer vision is bigger than what DFINITY can deliver on its own, and I really want to encourage the community to not just wait for us, but – where possible – build stuff around it (libraries, CDKs, services on-chain and off-chain etc.)
Thanks for these thoughts.
I’m pointing out that according to the vision sold to the community over years, the IC is supposed to be a complete replacement for the legacy IT stack, a complete alternative to AWS and centralized cloud providers, a drastic simplification to current backend infrastructure that runs in a tamper-proof and decentralization environment. If we have to set up our own infrastructure using the legacy IT stack, that piece will break out of the gaurantees of the IC. And many non-trivial yet mainstream applications need simple things like DNS integration, HTTP, WebSockets, and other protocols. There’s going to be a significant portion of normal web 2 applications that simply won’t be able to run on the IC, apparently, and IMO that defeats a good chunk of the main purpose of the IC.
I understand that there are limitations. Maybe the vision or expectations should be tempered a bit so the community knows what to actually expect.
I’m sorry if I didn’t express myself well (and, before this is also misunderstood, everything said here is my own view and opinion, and not official).
Yes, of course the application developer shouldn’t have to set up such a service, it should be part of the (wider) platform. But that doesn’t mean that DFINITY necessary needs to build it. This isn’t we vs. you; it’s all we!
I know that it doesn’t much look like this now, but the internet computer will be an open platform where not just DFINITY employees can contribute components.
Consider a canister CDK. The promise of the platform is that you get seamless interior. But that promise holds to developers who build on top of the platform. If you are building a CDK for a new language (say, go), then you are not the recipient of that promise, you are helpoito give the promise, and you will have to deal with such nasty details like the low level message passing format.
The same with “raw HTTP access” - it is a desirable feature of the platform. So I invite members of the community who want to expand the platform to build that feature, so that those who want to use the platform get all the nice things that you list get them.
So I am not backtracking on these promises of the internet computer platform - I am just expressing the hope that the internet computer platform will be built by the community, not just DFINITY, because there is soon much things to build 
Oh awesome! And I’m trying to push towards that vision too!
Am I right that these types of solutions would essentially need to be part of the ICP protocol suite to have the same gaurantees that ICP generally provides to canisters?
I don’t think we as the community have the information necessary to extend the ICP protocols ourselves, so anything we build currently would be stop-gap solutions built on cloud providers like AWS. Am I missing anything?
So for example, if I wanted to provide WebSocket support to the users of ICP generally, I would have to create the server software that handles WebSocket connections, and is the bridge to canisters. All of the WebSocket connections and state would be stored on normal centralized infrastructure, and would have the logic and capabilities to call into canisters. This could be a simple open source library that others could deploy for themselves, or I could actually spin up the infrastructure myself on something like AWS, and I would have to deal with the scaling and maintenance of that system (others could help of course, but it wouldn’t escape being a legacy system like any other).
Is that what you’re suggesting for now?
Am I right that these types of solutions would essentially need to be part of the ICP protocol suite to have the same gaurantees that ICP generally provides to canisters?
In the case of a bridge, the canisters are pretty unaffected, they just run on the Internet Computer and HTTP requests might arrive as specific anonymous queries – what guaranteeds towards canisters do you think about?
In terms of guarantees towards the users, matters are different, and I am not sure how some of the guaranteeds (e.g. certification of results) could be delivered… but if we’d knew all the answers, we probably had long built this feature 
As I tried to explain above: I don’t think a bridge feature needs to textend the core system (i.e. the stuff that runs canisters, does consensus etc). Why should it? What would that even mean?
The bridge run on the same infrastructure… but that seems a rather minor point to me at this point.
Is that what you’re suggesting for now?
Yes! The difference between what you describe (and what, incidentially, I built as a proof of concept at GitHub - nomeata/ic-http-lambda: A HTTP-to-IC bridge (proof of concept)), and this being an official feature in the Internet Computer, is merely “are we using the same infrastructure that happens to also run the core Internet Computer, or are we using a separate one”.
(others could help of course, but it wouldn’t escape being a legacy system like any other).
Yes… but the Internet Computer itself runs on “legacy systems” after all! It’s not like the Internet Computer is a magical thing that doesn’t need hardware, and networks, and firewalls, and persistence, and DOS protection. Quite contrary: It has to deal with all the things so that Canister application developers don’t have to.
Same with that bridge. If someon like you wants to help the Internet Computer to succeed, and if you think the HTTP bridge is essential, and somehow DFINITY doesn’t build it for you, then you can build and host and run and scale that so that Canister developer’s don’t have to worry. And if you want it to be more reliable and failsafe by being decentralized, well, then make it so. (Not you personally – the community.)
Or, eventually, you can make a proposal to include it in the software for the nodes that happen to run the ICP itself, and re-use the same infrastructure. This may be convenient and the right thingin the long run. But the point I am trying to make is that it is not an absolute must for this feature. (There are other features that absolutely must be part of the protocol to make sense. HTTP acces is not one of them.)
WebSocket is a full-duplex protocol, which already implies some kind of state- or context-awareness on both (on exactly two!) sides. But if you consider, that on the IC side it’s a replicated state machine, there is no 1 to 1 relationship anymore between the user and the computer, it is 1 to N instead (1 user, N replicas). So WebSocket can only be retrofit to this scenario, but not natively supported in a fully decentralized manner, simply due to the fact, that a 1 to N relationship will always have a point of “consolidation” (centralization). And where this points of consolidation lies is the interesting question.
Good point – I have been mostly addressing the issues of normal HTTP, so sorry for straying off topic. For WebSockets there are indeed quite a few fundamental technical issues to look at first…
Yes. Emulating a socket on top of request-response HTTP is nontrivial, but here is some prior art:
For a previous job, I made an implementation of this that allowed for doing graphql-ws (websocket) subscriptions over pushpin.org + websocket-over-http + aws lambda. GitHub - fanout/apollo-serverless-demo: Serverless GraphQL subscriptions
It definitely involved wading into these waters of the fundamental differences between a client-server message passing model and one that is more full-duplex/sockety, and it had to use DyanmoDB to bridge the gap. iirc because if the ‘server’ sends messages to the client outside of a request/response cycle, they have to be stored somewhere before they can be delivered to the client the next time the client is connected.
Yes, that’s exactly the “point of consolidation” I was talking about. Moving this point to IC entirely (which is the consensus) does not make sense, as the stored data would become decentralized as well and we’re back to square one, as we’d need to consolidate all the possible reads from this data again. So the consolidation makes only sense on the client side (or in general: outside of IC) and this is what makes WebSocket kind of a square peg in a round hole.
Maybe I’m missing some details of how IC works, but why can’t the boundary node maintain such a connection with user client on one end, and on the other end, keeps polling replicas?
I don’t think update call makes much sense for websocket. Query call on the other hand could benefit significantly as a means for broadcasting latest changes.
If I’m reading the implementation of icx-proxy correctly, it is already doing something like that for the streaming support in HttpResponse. IMHO, we should be able to generalize it to WebSocket.
Any update on WebSocket support?
Hi @lastmjs
We wrapped up the proof-of-concept that was presented in the Public Global R&D. We are just waiting on the last approvals for open-sourcing it. I will let you know, when it is available.
Sounds great, thanks!
@lastmjs I have finally news for you: we have just released our WebSockets proof-of-concept and explain all the details in the following thread: