Update on the IC Roadmap: July 2022 Summary

[samuelburri]

Following our June update on the IC roadmap, here comes the July edition. As announced during the first public global R&D session, we are changing our roadmapping approach. Starting in 2019, paving the way to Genesis in 2020 and beyond, we defined milestones named after metals that bundled sets of features. For example, the Titanium milestone included features A, B, C, Chromium included D, E, etc. Going forward, we will drop the concept of milestones and instead maintain stack-ranked lists of features associated with domains. For example, in the “Core protocol” domain, the focus will be on A, then E, F and H. We will release these features as they reach the necessary maturity, some as early preview versions which we will subsequently improve based on community feedback.

Background

Why the change and what learnings are incorporated into the new approach?

Shortcomings of the Metal Milestone Approach

• Sticking to long-term aggressive timelines proved to be impossible. We underestimated efforts, and the scope of features often increased as new aspects came up that we hadn’t anticipated. Additionally, changing priorities contributed to more timeline changes.

• Bundling features in milestones leads to unnecessary dependencies. Should we declare a milestone done even though one feature is not complete?

• We started publishing early developer previews, e.g. of the Bitcoin integration. This was well-received by the community and we were able to collect valuable feedback. Such incremental rollouts are at odds with the “big bang nature” of milestones.

• Due to constant scope and timeline changes, the milestone approach often led to confusion among community members.

Learnings and What to Keep

• Public roadmap: Having a public roadmap is a great means to engage with the community. The foundation is devoted to making its work transparent.

• Transparency about resource allocation: Recently, members of the community questioned whether the foundation focuses on the right things. For example, do we spend enough time on core protocol improvements? By showing how we allocate our resources, we would like to be more transparent to address such concerns.

• Highlight community requests: Another source of concern in the community is whether we give community requests enough priority. To address that we will highlight features that have been initiated through community requests.

• ETAs: We understand that the community wants to know in advance when a new feature becomes available. However, if we publish estimated times of arrival (ETAs) too early, we will have to constantly change them. In the future, we want to be more conservative and only publish ETAs as we get closer to releasing (1 to 2 months before the release).

• Early access and continuous improvements: we will release more early and partial solutions in order to collect community feedback.

• Regular communication of roadmap changes: we will continue with monthly updates on the roadmap. Mainly here in the forum.

• Release events: instead of organizing events around milestones, we plan on organizing events around major feature releases.

New Approach

We will maintain a table as shown above.

• Why different columns? Columns denote different domains, mapping roughly to engineering teams. The percentages describe the fraction of R&D team members working in this domain. For example, 43% of the R&D team works on the core protocol. A few more details about the domains:

  • Core protocol: All things replica, including the system, the networking layer, consensus, the execution environment, crypto libraries, etc.
  • Boundary: Boundary nodes and service worker.
  • System utils/dapps: Includes the NNS front-end dapp, Internet Identity, and exchange integrations.
  • Governance/NNS: subsumes the NNS and related services such as the SNS.
  • Developer Experience (DX): SDK, Motoko and the Rust CDK.
  • Infra & Ops: includes both infrastructure work for the IC, e.g. operating DFINITY-owned IC nodes, but to a large extent infrastructure for the foundation, including development environment and CI.

• What is a feature? A feature is a piece of work that delivers value to the community, the IC, or foundation-internal infrastructure to make us more effective. Features can be small but crucial pieces of work done in a week or a major undertaking such as threshold ECDSA. In general, we try to scope them such that their implementation does not take more than 3 months.

• Stack ranking: within each column we maintain a stack-ranked list of features. The upper part shows our top priorities and below we list features we may have started working on or plan to start on the near future.

• Constant updates: we acknowledge that priorities change. We will try to limit changes but it’s inevitable that the course will change.

• Community-requested features: the heart emojis show features that address community requests.

Disclaimer

The work of reorganizing our roadmap is still in progress. Therefore, the table shown above is by no means final. Features and their stack-ranking are subject to change. However, the top priority items are indeed our main focus today.

New Roadmap Webpage

Based on the approach introduced here, we are building a new roadmap section on internetcomputer.org. Our intent with the new page is to eventually also allow community members to submit features to the roadmap, i.e. it should not be exclusive to DFINITY.

Conclusion

While this update is mainly about the general overhaul of our roadmapping approach, it’s also worth mentioning that we are making good progress with our top priority roadmap items. Four concrete updates:

• Bitcoin integration: Next week, we plan to release instructions and tutorials for developers explaining how to use the Bitcoin and ECDSA APIs. This will enable developers to start building dapps integrating with the Bitcoin testnet. In a few weeks, we will then switch to Bitcoin mainnet.

• SNS: The individual teams contributing to the SNS initiative are close to wrapping up their individual workstreams and we have started integrating them by means of end-to-end demos. Recently, we determined that we should synchronize the introduction of the community fund with the release of the SNS as it provides an excellent means to invest in SNS-tokenized dapps. Stay tuned for an NNS motion proposal describing the community fund in more detail.

• ICRC-1 token standard: The token standard working group is getting closer to proposing an initial basic standard. A working group internal vote has led to another round of improvements and we should soon see an NNS proposal for the standard.

• Node hardware: As the current replica node hardware is increasingly out of stock, we are introducing a new replica node hardware specification. The first test machines complying with the next standard have arrived in our office and we will test them during the coming days. After that, we will release the new specification.

We hope you like our new roadmapping approach and look forward to your feedback.

[borovan]

Shortcomings of the Metal Milestone Approach

• Carbon is not a metal

[jzxchiang]

Can someone from DFINITY clarify what “Streaming sup” means under the Boundary column?

Is it related to the recent changes to the service worker to support video & audio streaming? Can someone explain what these changes actually do in concrete terms? @kpeacock @martin_DFN1

[jzxchiang]

I’m also curious about high-replication subnets. I wasn’t aware that was a community request. Are these supposed to be “fiduciary” subnets meant for running DeFi applications?

Somewhat unrelated, but will storage subnets be worked on? Many applications will soon store media like video (especially given the recent updates to the service worker to support streaming), and the current costs of $5 / GB / year, while awesome compared to other blockchains, still prove prohibitive for storing large volumes of consumer data.

[Zane]

I don’t see named callbacks mentioned anywhere on the roadmap, even though they are fundamental to token standards and better interoperability by making safe upgrades possible, does it mean the Foundation isn’t planning on working on them for the foreeseable future?

It’s a bit weird to not have them and other frequently asked features like Big Map on the roadmap, but somehow Subnet Rental, which I’ve never heard about is a top priority and marked as a community requested feature.

[martin_DFN1]

Yes, streaming support is related to the recent service worker changes. They are in production now. There is more work to do (like range requests and handling aspects of Safari streaming). So far we have implemented the streaming callback.

[diegop]

@samuelburri relevant comment on the July 2022 current roadmap above:

Questions and concerns about DFINITY Foundation working "beyond core protocol"

I know it’s not related to the SNS related questions, but one bit of feedback is the road map is missing the two proposed features which were approved 3 and 6 months ago (55651 & 38985) and that the community is currently trying to communicate is very important to them via the ongoing proposal 72189. I’m guessing they’re included in the “…” but I don’t think that gives the right message to the nns/governance community, it basically suggests those features didn’t even make the “later” list.

[jzxchiang]

I feel the same way.

[diegop]

@Zane

don’t see named callbacks mentioned anywhere on the roadmap, even though they are fundamental to token standards and better interoperability by making safe upgrades possible, does it mean the Foundation isn’t planning on working on them for the foreeseable future?

Good question. I’ll escalate internally… though I suspect the answer to your question is that it’s not at the top of the stack (right or wrong) so it does not have much active development… but i am checking.

[jzxchiang]

I’m surprised Motoko enhancements aren’t listed on this roadmap. They should fall under DX, but I don’t see any concrete items (although there is this, which is nice).

[samuelburri]

@jzxchiang

I’m also curious about high-replication subnets. I wasn’t aware that was a community request. Are these supposed to be “fiduciary” subnets meant for running DeFi applications?

In preparation of the SNS launch a high-replication subnet was created to host the SNSes. This, rightly, caused questions how other community members could get access to a similar high-replication subnet, i.e. giving all community members the same opportunities. With this feature we plan to introduce different cycles cost depending on the replication factor and a means for developer to target subnets with a higher replication factor. Later, this “subnet targeting” solution could be extended to deploy canisters to subnets matching other criteria. We have just started with the design and will share more details and ask for feedback in the near future.

@Zane

I don’t see named callbacks mentioned anywhere on the roadmap, even though they are fundamental to token standards and better interoperability by making safe upgrades possible, does it mean the Foundation isn’t planning on working on them for the foreeseable future?

We are aware that this is a feature that is requested by many community members. We don’t actively work on it yet. But as mentioned above, the list shown so far is by no means final. Thanks for pointing out that you miss ‘named callbacks’ on the list @Zane

@diegop

@samuelburri relevant comment on the July 2022 current roadmap above:

Good catch @diegop . Motivated by the motion proposal on governance priorities, we spoke a lot about those features during the past days. Yes, we have to add them to the list as well. I will take care of it.

@jzxchiang

I’m surprised Motoko enhancements aren’t listed on this roadmap. They should fall under DX, but I don’t see any concrete items (although there is this , which is nice).

@jzxchiang Motoko is not forgotten. We are actually working out a more holistic roadmap for Motoko as part of DX. But we don’t have a first version yet that is ready to be shown and therefore the DX domain misses Motoko for now. Stay tuned for more.

[diegop]

Thanks @samuelburri !

[blockpunk]

I would like to know why decentralized deployment of nodes and boundary nodes is not in the roadmap?

[samuelburri]

Hi @blockpunk . The decentralized onboarding process for replica nodes is on the roadmap as Node Provider Onboarding UI. All features needed to improve boundary node decentralization are not on there yet but we are working on defining these items. The Browser plug-in or similar, which you find in the Boundary domain, is actually one piece of the puzzle that we want want to deliver as soon as possible.

[Zane]

What is the reasoning behind prioritizing geo based deny list? I assume the feature will allow canister to deny access to specific countries, is that correct? If so why is it needed? To me it looks like something that goes against the principles of a world computer and web 3.