Some Lessons from Building a DAPP on the IC

[josephgranata]

Dear DFINITY Devs in the Forum,

As a way to thank so many of you for your advice, and positive vibes whenever we asked about our challenges building software for the IC I wanted to share with you some nuggets of wisdom from our journey developing SatoshiNotes for the IC.

Satoshi Notes is a note taking app that works similarly to Apple Notes or MS One Note, meaning it runs locally on your computer, and can store data on the IC blockchain. Their main advantage is that it will allow people to sell notes for Bitcoin or ICP, and to do it quite easily.

That paragraph summarizes the app functionality, you can see a little more here:

Satoshi Notes Software

Now here is the good part for the developers in the forum, especially those who are not experts, but want to build an app that runs using the IC. These are the challenges we found:

1.- If you win a grant with DFINITY, as we did, remember that they only pay you when you deliver each milestone. This means your team MUST HAVE other sources of income or savings to survive. You are not paid month by month, and you are not paid if you do not deliver.
2.- As everyone who has led a team knows, the project plan is always full of unknowns, so what you estimate at 6 months of work, can easily double, and the reasons will not be discovered until you hit a problem.

For us the main problems were three:

• We were not experts in the IC, and our theoretical architecture was very hard to execute. In particular we wanted to have a manager canister that spawns user canisters, and each user canister should hold HTML and related data, those are the notes to share.
• This proved very hard, and we had to abandon over a month of work in Motoko when it proved not be able to do the job. Rust seemed to be the only way, it was tough finding a competent and professional developer who would work for FUTURE money, not a payment until there is delivery.
• There is a lot of experimentation and failure as you build, you will explore an avenue only to realize it does not work, and have to start from code you did several weeks ago.

What would we do if we did it again?

First off we would concentrate in having a steady income for all the team members, so that grant money is extra, and welcome, but not needed.

Second we would learn and build exclusively using Rust. There are many weird challenges we found that could only be solved with Rust on the IC. I do like Motoko, and it is easier to use and learn, but once you hit a roadblock more often than not only Rust will save you, and by the way, it won’t be easy either, but possible.

Third, do budget a lot more time to building if you plan to use advanced features like saving data on the blockchain, showing that data via a web page, or accepting Bitcoin.

One final thing, DFINITY is patient, but your estimate will become a deadline sooner or later. Be aware of that, or you won’t make it.

DM me for any details on any of these topics.
I wish you all success in your development projects!

Joseph Hurtado
Founder Granata Consulting

[icme]

@josephgranata

• In particular we wanted to have a manager canister that spawns user canisters, and each user canister should hold HTML and related data, those are the notes to share.
• This proved very hard, and we had to abandon over a month of work in Motoko when it proved not be able to do the job.

Hmm - there are numerous examples of a parent or manager canister dynamically spinning up child canisters in Motoko.

The first example was written in 2021 Mini BigMap library

If you search this forum with the terms “Dynamically create canisters in Motoko”, this is the first result Blog post: Dynamically Create Canister Smart Contracts In Motoko

I’m curious what the implementation blockers were for doing this in Motoko, maybe adding more support for this in the developer docs would have helped?

[josephgranata]

There are no stable structures in Motoko, and there is no easy way to render assets from canisters you create from scratch on demand.

[icme]

Hey Joseph, hopefully I can help solve a few of the issues you’ve mentioned above.

@josephgranata

There are no stable structures in Motoko,

Motoko has a different approach to stable data, which is to store it using the stable keyword that automatically persists the data during canister upgrades without having to do the serialization yourself.

There are numerous stable data structures in Motoko, including just to name a few

• Hash Map & Set
• BTrees
• Vector (i.e. array/buffer)
• Linked List
• Merkle Patricia Trie

If you’re referring to using actual stable memory directly, I agree the current APIs for directly accessing and manipulating stable memory in Motoko are difficult. Luckily, the Motoko team has been working on Enhanced Orthogonal Persistence, meaning that state will persist indefinitely and across upgrades without needing to use stable memory APIs.

Enhanced Orthogonal Persistence is close to completion, and when wasm64 support is released for canisters, this means that by just using the stable keyword, Motoko developers will be able to store 400+ GB memory in the canister heap (increased performance), and stable keyword will allow for instant upgrades of 400+ GB of heap-based variables.

@josephgranata

there is no easy way to render assets from canisters you create from scratch on demand.

Are you referring to an asset canister, or NFTs?

@ferMartz built Nitro, a decentralized file store using Motoko and CanDB. CanDB dynamically spins up auto-scaling canister partitions on demand, and I believe all the assets are stored as Blob type in the data store.

Introducing Nitro : A Decentralized File Storage Solution

Hello IC Community , We are thrilled to introduce Nitro, our new decentralized file storage DApp. Nitro ensures secure, accessible, and user-controlled data management, leveraging the power of blockchain technology. Today, we are releasing the alpha version for you to try. About the Project Initially, we aimed to create an easy way to store assets on-chain (images) for our Audionaut dapp. However, during development, we realized this solution could benefit m…

I’d be interested in learning more about the different roadblocks you ran into in using Motoko. Chances are you’re definitely not the only one!

[skilesare]

@icme

Are you referring to an asset canister, or NFTs?

@ferMartz built Nitro, a decentralized file store using Motoko and CanDB. CanDB dynamically spins up auto-scaling canister partitions on demand, and I believe all the assets are stored as Blob type in the data store

@ferMartz also did a bunch of work on the origyn_nft’s file system which serves entire websites and dapps out of a motoko canister, so there should be a ton of code available. I believe we even have a branch with asset certificates v1. V2 certification is pending and hopefully will be available soon.

[ferMartz]

@josephgranata

As @icme mentioned, CanDB allows you to spin up any number of child canisters and build a database in Motoko with various data structures. You can check the documentation here.

In Nitro, I’m storing different types of files, including notes, as Blobs.

Additionally, as @skilesare noted, I worked on the Origyn NFT project, where we stored extensive metadata and an entire website within an NFT. You can view the code here.

Feel free to post any questions here or DM me if you have any further questions!

[josephgranata]

@ferMartz @skilesare @icme Hello everyone, I’ve been quite busy so I did not have time to thank you for your suggestions.

The main objective of my post was not to criticize Motoko, just to show people the challenge that developers face when building non trivial software for the Internet Computer.

For many reasons we have decided to continue using Rust, and not use Motoko. I am happy there are many good tools on the Motoko side, but we are building on Rust now and have been able to deliver every feature. To each his own, I personally do like Motoko, it reminds me of OCAML and is certainly much easier to learn than Rust.