IC WebSocket: Stable Release

I’ve answered in the thread that you started: Problem in Websocket set up - #3 by ilbert

Let us know if you encounter any other issues!

1 Like

FYI, we plan to release updates for CDKs and SDKs to update their dependencies by the end of June.

Is there someone who needs the release sooner?

2 Likes

New release!

Today we’re releasing new IC WebSocket versions that affect all the SDKs.

New versions

SDKs:

What’s changed

SDKs

We suggest you to update all your SDKs to the latest version.

  • we’ve removed the deprecated ws_send method from both the Rust and Motoko CDKs. The method was already deprecated in v0.3.2 and now has been removed completely. Use send instead.

Motoko

  • Due to the newly introduced Motoko v0.11.0 safety feature, calls to sensitive functions now require the system pseudo-type. For this reason, now it’s required to initialize the IC WebSocket library using the newly introduced init function:
    let ws = IcWebSocketCdk.IcWebSocket(ws_state, params, handlers);
    + ws.init<system>(); // <- add this
    

    Please refer to the Motoko v0.11.0 migration guide to understand when you can call functions that use the system pseudo-type.

JS

  • we’ve updated the @dfinity/... dependencies to the new v2.0.0 release. Make sure you upgrade them in your dependencies too.
  • we’ve additionally fixed an issue that was causing the IC WebSocket JS client to fail to verify the incoming messages certificates.

You can also follow the updated tutorial for reference.

5 Likes

The Motoko examples for the for ic-websocket implementation have been updated as well to the latest ws SDKs and @dfinity/... packages and a few other frontend updates.

Chat App, Pingpong

2 Likes

Hi. New here. This can be used to listen de ckBtc ledger and ckBtc minter canisters to know when a deposit come in and notify my users?

1 Like

Hi @franqqe!
Unfortunately, you can’t use the current IC WebSocket implementation to subscribe to any canister.

The target canister must implement the IC WebSocket protocol by using one of the available CDKs (Rust or Motoko), in order for a client to be able to communicate with it via WebSocket.

A non-optimal workaround would be to create a “middleware” canister that polls both the ckBTC ledger and minter and sends the new events via WebSocket.
However, if you want a (near) real-time ckBTC “notification” system, you would need to poll the ckBTC canisters frequently from the middleware canister, and that can become pretty expensive in terms of cycles.

Does it make sense to you?

Yes, this is exactly what I was looking to know, thanks. I think my best option to a notification system for this “public” canisters is use de ckBtc archive and his method get_transactions maybe in a cronjob, this way I can notify my users when a mint deposit or a transfer is sent to their addresses.

It depends on the real-time rate you need. I think the archive canister receives the latest transactions only a few times per day or so

oh that’s bad. I have no more options for this :confused:

1 Like

You can still achieve the same objective by querying the get_blocks method of the ledger canister from the middleware canister, using a periodic timer.
Depending on the timer frequency, the cost can be significant.

I’m trying to notify people when their wallets receive some deposit. It doesn’t take too much. Maybe a few minutes but no more than that. I’m using de public canisters, not deployed ones, it cost cycles to me?

It’s going to cost you cycles because you need to create that “middleware” canister that polls the ckBTC Ledger canister and sends the (WebSocket) notifications to the users

but if I dont use this middleware, and in my code I run a cronjob that get every 10 minutes the method get_blocks, but without middleware. It won’t cost me, right?

If I understood correctly, in this case you will implement an off-chain server that polls the ckBTC canister using a cronjob and, yes, it won’t cost you any cycles. But you won’t make use of the IC WebSocket protocol.

1 Like

I tried with the NNS Ledger canister, but I didn’t know that this canister is in ICP token. Can I use it with another token? Or is there another NNS canister with ckBtc token? I realized this when I connect all in my code and didn’t see my transfers in the query blocks

The discussion is going a little bit out of topic now.

Would you mind opening a new topic describing what you want to achieve with the problems you’re facing and post the link here?
So that other people from the community will also be able to help.

Thanks

1 Like

New release!

Today we’re releasing new IC WebSocket versions that affect both the SDKs and the gateway.

New versions

SDKs:

Gateway:

What’s changed

SDKs

Dependencies have been updated.

For the Rust CDK, we’ve bumped the ic-cdk dependency to v0.16.

For the JS SDK, we’ve bumped the @dfinity/... dependencies to v2.1.3.

Gateway

Dependencies have been updated.
Please expect another gateway patch release soon, that will switch the ic-agent back to using the old /api/v2/... IC API again. We don’t need the update calls from the gateway to the IC to be synchronous, since we already have a way to detect if messages are effectively received by the canister.

3 Likes

New release!

Today, we’re releasing a new IC WebSocket version that affects the gateway.

New versions

Gateway:

What’s changed

Gateway

  • fixed the issue of client connecting and sending multiple messages without following the IC WS Protocol. We have relaxed the checks in the client session handler of the gateway and now we just ignore duplicate messages instead of closing the connection
  • messages relayed to the IC from the clients are now relayed to the IC in a dedicated Tokio task, so that the client session loop is not blocked

Thanks to @lorenzoronzani for the help!

4 Likes

No, the NNS Ledger canister only works with ICP. There’s no equivalent NNS canister for ckBTC.