Diode Message Storage coming to Difinity

Developers Getting Started
1

Hey there,

this is Dominic from diode.io team. We’re starting a three month sprint here to use the internet computer for end to end encrypted chat message relaying using canister logic. The Diode App (Download Hub | Diode™) already features e2e messaging but so far has been relying on peers to be online for the messages to be delivered. Instead of adding centralized servers caching messages we have been looking at various alternatives. Finally we the ability to store large amounts of data (32gb) and bundle them with logic decentralized on the ICP convinced us that this might be the right tool for the job. We’re going to use the internet computers canisters and large available storage to hold the encrypted messages and make them thus always available even if no peer is online.

As we’re freshly getting into the ICP there are a couple of beginner questions for us to solve coming from Solidity. Any pointers would be helpful as we’re starting to develop the canister code:

  1. Is the motoko playground here the standard equivalent of remix? Is there any newer or more idiomatic version we should be using instead? Is it a good starting point at all?
  2. To ensure the canister is only used by and pays for “in-group” interactions we would like to enable a permission checking scheme on the canisters methods using secp256k1 signatures. What are the go-to packages for doing this, any libraries or even group access frameworks we should be looking at?
  3. Last but not least as we want to use the canisters for message storage and I’ve read about Motoko limitations to access stable memory here: 32 GB Canister Storage - #5 by tomijaga — Should we use Motoko at all or start immediately with rust? Is it possible to mix? Again any pointers would be helpful

We will work our way through these and more questions here this month and publish our progress as well as findings / decisions on these questions for the rest of the community.

Happy to be here
Cheers!

2 Likes
2

  1. The playground is just an online IDE for quick examples and demos on Motoko, it’s not a framework like Remix. Right now there are 3 main language options with an SDK: Motoko, Rust and Typescript (Azle).

  2. There’s no need to check any signatures to differentiate callers, instead check the principal of the caller with e.g. the caller() method. This principal is basically the id (hash) of the public key that signed the incoming message. When you look for “securing methods” in either the Rust, Mokoto or Azle examples you’ll find how this is done, it’s quite straightforward.

  3. No idea if Motoko is still more limited, all I know is that the stable storage limit nowadays is more than 32gb, north of 200gb, basically a lot.

2 Likes
3

Have you considered using TypeScript/JavaScript? My company is developing the Azle CDK: The Azle Book (Beta) - The Azle Book

It’s in beta, has great access to Stable Structures, can even do Express/Nest to act as an http server, has access to various (not all) npm packages.

3 Likes
4

Thanks for all the pointers!

  1. We started out with the simple canister log example and then switched from the included Makefile to using mops for testing and quick turn-around during development. Had to learn about mops pocket-ic integration in order to make the test cycles acceptably fast. (One call to mops test with an actor test take >20 seconds with the default dfx replica, but <5s with pocket-ic)

  2. For the secp256k1 validation, we found that this is implicitly supported and exposed in Motoko as the calling principal. We had figure out the calling and signature conventions to figure out how to sign the request messages here: The Internet Computer Interface Specification | Internet Computer – most surprising was that the sender_pubkey field reference was expecting the DER encoded version of the key.

  3. Last but not least we found that the Motoko Region API is doing what we need: Region | Internet Computer - although it comes with a surprising 8mb pre-allocation for every new Region. Which caused us to change our architecture mid-development. Also for the future there is the Enhanced orthogonal persistence | Internet Computer coming which would be exciting to use as it might make the design even easier.

Our code so far is here:

It think it could have saved us a significant amount of time if the example that we started out with canister log example would have had mops integration and pocket-ic in the mops.toml already.

We will publish more as we come along including the elixir client for the icp that we’ve been using.

Cheers!

2 Likes
5

Thanks for the feedback! We’re considering ways to update the example projects, and it’s helpful to know you’d have preferred having mops and pocket-ic integrated

3 Likes