SDK '22-23 Roadmap Themes

[dfx-json]

Hello everyone. Jason from the SDK team here to give you a little update on our SDK roadmap.

You may have bore witness to this already if you attended the recent (our first public!) Global R&D, or if you came to our Developer Tooling Working Group session (ask me for the link if you don’t have it). I’m here to network with you on the themes we’re focused on and the feature highlights we’re currently considering.

Our timeline and focus areas are still malleable at this point - I would love to hear your feedback so the team can work with you all to ensure your needs are not long forgotten.

Without further ado, let’s jump in. In no particular order, the themes are:

Monitoring, Testing, and Debugging

Why does it matter?

Developers need insight into the behavior of their applications so that they can discover, triage, and resolve issues affecting their users and/or business.

What we’re doing about it

The road to debugging your canisters is long, but the need for you to troubleshoot problems is nigh. We’re looking at what we can do to give you access to your canister’s mainnet logs so that you can triage and fix issues with quicker turnarounds. Stay tuned for more on cost model and features you would come to expect with first-class logging support.

Canister Management

Why does it matter?

Views on canister health, cycles balance, and performance are key to ensuring a reliable and efficient canister ecosystem on IC.

What we’re doing about it

We’re thinking of ways we can help developers become aware of and respond to critical events that occur during the lifecycle of a canister, such as cycles balance dropping below, or storage limits exceeding a certain threshold. The best solution here may live in user-land, so that can be a wonderful opportunity for one of you to build something great!

Identity

Why does it matter?

Web3 is predicated on ownership, and developers should be able to fully leverage the capabilities offered by cryptographically secure, decentralized identity in their dapps.

What we’re doing about it

We’re planning new ways to let dfx integrate with external identity providers, like Internet Identity or Plug.

Local Environment Synchronization

Why does it matter?

Developers should be able to harness the full power of mainnet IC within their local development environment so that they can build advanced integrations with system canisters and community projects.

What we’re doing about it

What if you could have “build once, run anywhere” WASM? We’re thinking about how we can make it so the same WASM can be deployed on mainnet and in your local environment. Looking beyond, this could open the door to a DockerHub-esque project (WASM Hub?) that the community could build to distribute IC-compatible web assembly modules across the ecosystem, lowering the barrier of entry for developers looking to integrate with specific projects in their apps.

Mobile App and Oracle Support

Why does it matter?

To accelerate end-user adoption of the IC, we should have better support for mobile. To expand the possibilities available to developers, we should support more programming languages that can be used to interact with canisters on the IC.

What we’re doing about it

If you’re passionate about mobile development, we’d like to encourage you to build agents for languages like Swift or Java with bindings for iOS / Android. If there is another language you love to use but there isn’t an agent out for it yet, why not build it yourself? We have bounty programs and a terrific grant program available. Reach out to me directly to learn more about how you can step up and build an agent.

DFX Quality of Life

Why does it matter?

The dfx user experience should be extraordinary. We are committed to making dfx friendly to newcomers, yet powerful for professionals.

What we’re doing about it

We have several new initiatives in place to improve the overall dfx user experience. Things like System Wide DFX (coming soon), and the removal of the cycles wallet are examples of what we’re doing to simplify your use of the beloved Dfinity Executor. We would also like to better ascertain what we don’t know about dfx. The upcoming dfx quickstart command will ship with some new features that give you better insight into your account and canisters, and help us make dfx better for all of you.

Conclusion

So, what do you think? Share your thoughts, excitement, concerns, and feedback in the thread! Me and the team will respond as the questions come in.

You are the best developer community in the world! Looking forward to hearing your thoughts.

[coin_master]

Thanks for writing this up, I am excited to see all these cool features!
I would like to see a documentation on how to write a CDK for canisters by any language, for example Rupy or Go.

[WoW]

I wonder when would SDK could natively installed on Windows? Not very familiar with WSL 2.

[Zane]

@dfx-json

Looking beyond, this could open the door to a DockerHub-esque project (WASM Hub?) that the community could build to distribute IC-compatible web assembly modules across the ecosystem, lowering the barrier of entry for developers looking to integrate with specific projects in their apps.

I’m not sure how much this one will solve the issue, if dApps have to provide a .wasm file publicly and theoretically also seed it with data, this has 2 downsides:

• Seeding the data is more work for the devs
• The .wasm bytecode can be modified by anyone and uploaded on chain, meaning I could take someone else’s work, modify it a bit and possibly profit from it: either by running a competing service or a phishing scam.
  This caveat might disincentivate many devs not to use this feature, rightfully so cause nobody wants to have his work stolen after months of RnD and hard work, making it less effective overall.

In my opinion Dfinity should focus on an actual testnet instead so that devs can test their own dApp’s behaviour when interacting with other canisters, enable users to test new features before pushing them to live and make sure other services have time to integrate with latest changes, all of it without having to worry about cycles.
A testnet might also remove the need of a cycle faucet, which has been abused for months and now requires manual intervention by Dfinity.

Are there any reasons why Dfinity hasn’t considered this option? Most chains have a testnet, so I suppose there are good reasons to justify the hassle.

[Maxfinity]

We’ve actually got a solution to the cycles monitoring issue, write your canisters as traits as we do using our cdk framework and inherit all of this for free. GitHub - infinity-swap/canister-sdk.

infinity-swap/canister-sdk/blob/main/ic-canister/tests/canister_c/src/lib.rs

[Severin]

@WoW

I wonder when would SDK could natively installed on Windows? Not very familiar with WSL 2.

The SDK itself is no big deal . The big problem is that the replica (the thing you run on dfx start) was not built with Windows (or even just WSL2) in mind, meaning that there appear runtime errors surprisingly often, even just on WSL2.

[mikhail-turilin]

A few comments…

Seeding the data is more work for the devs

This is purely voluntary. If you don’t see value of publishing your code - you don’t have to publish.

The .wasm bytecode can be modified by anyone and uploaded on
chain, meaning I could take someone else’s work, modify it a
bit and possibly profit from it: either by running a competing
service or a phishing scam.

This is a general issue with publishing the source code. Let’s say you are running a DEX - you may increase users’ trust in the platform by publishing the source code. However, you don’t have to if you don’t think it’s useful. WASM is just a shorthand for publishing the source code.

I can’t see a solution for both:

1. Share the source code for trust and development integration
2. Avoid people misusing your source code against the license.

Do you have examples when closed source solution make sense for Web3 in general?

[Zane]

@mikhail-turilin

This is purely voluntary

Sure what I’m saying is with a testnet all it takes is a couple clicks and the canister is there for everyone to use, so it’ll soon have data in it generated bu users, if initial state has to be seeded manually that’s more work on the dev’s part.

@mikhail-turilin

Do you have examples when closed source solution make sense for Web3 in general?

Many dApps might want to open source only some parts of their dApp, e.g the ledger, I don’t think an inherent property of Web 3 services is open source, interoperability on the other hand is one of Web 3 advantages and it’s hard to have that if you can’t test integration with other dApps. Without a testnet devs have a few choices and they all are less than ideal:

• work on mainnet and spend cycles
• use public WASM (if someone provides it)
• manually mock the interface you want to integrate with (resource intensive)

All of these have obvious downsides, which are solved by a testnet with added pros on top like making staging environment (public testing) possible, for both users who can make sure the dApps doesn’t have any bugs when its launched and devs trying to test their code as much as possible.