Proposal to allow an OpenChat principal to create canisters on subnet 2fq7c

Hey!

I am one of the OpenChat devs.

OpenChat currently runs on a single subnet (eq6en), this subnet now has 75,000 canisters which is causing it to slow down significantly.

Dfinity is working on supporting many more canisters per subnet but that won’t be completed for a few months, so as it stands, OpenChat must spread onto a 2nd subnet in order to keep growing its user numbers.

From our side, we have almost finished the code changes required to allow us to run OpenChat across multiple subnets. We have been speaking to Dfinity during this process and they have now submitted a proposal which will allow us to create canisters on a currently empty subnet (2fq7c).

We believe that in the future OpenChat will have millions of users and will occupy many subnets, with each subnet running hundreds of thousands or maybe even millions of canisters.

So please vote to adopt proposal 97291 so that we can continue on our path to millions of users!

Thanks!

Vote on OpenChat - OpenChat: Decentralized chat on the Internet Computer
Vote on the NNS Dapp - Internet Computer Content Validation Bootstrap

21 Likes

Done!

3 Likes

we can’t ignore the fairness of the blockchain, I voted no

1 Like

Sorry, I vote no, because you can use CMC to create random subnet canisters, in favor of Load Balance.
Not like this

2 Likes

How does scaling 1 app across multiple subnets work?

1 Like

This is completely fair criticism since it can be seen as treating OpenChat as a special case.

But I would argue that OpenChat is currently a special case.

The IC has 220k canisters in total of which 75k are from OpenChat, which means OpenChat makes up more than one third of all canisters running on the IC.

By giving OpenChat its own subnet, OpenChat is able to fill that subnet right up to its capacity and can then stop creating canisters and move onto another subnet. OpenChat is paying for this resource usage just the same as any other service would. So by using a subnet to its full capacity, that subnet is burning a huge amount of cycles and no other services are negatively affected.

If OpenChat were to run on a shared subnet, there are 2 options, either OpenChat fills the subnet to its capacity, which means the subnet is burning lots of cycles, but also means all other services on the subnet can’t grow without impacting the performance of the subnet, or alternatively, OpenChat doesn’t fill the subnet, leaving room for the other services to expand, but then the subnet isn’t consuming as many cycles as it could.

So it is better for the IC as a whole if OpenChat runs on separate subnets which it fills to their capacity, burning the maximum amount of cycles while having no effect on other services.

Also, Dfinity have 2 features planned which will remove the need for this manual intervention.

  1. Subnet rental - Anyone will be able to rent an entire subnet at a fixed cost. OpenChat will switch to this model once it is ready.

  2. Canister groups - When creating canisters you can label them as being part of the same ‘canister group’, then when a subnet reaches its capacity, that subnet will be split, and the canisters will be split in such a way that canisters in the same group will remain co-located after the split. This would allow OpenChat to start growing on any subnet, and when the subnet reaches capacity the OpenChat canisters would all be moved to a different subnet.

In the future, by making use of these features above, services with a huge amount of canisters will be able to grow without any concern for where their canisters first get allocated, but right now the IC is still in its infancy and so the best course of action for both OpenChat and the IC community as a whole is for OpenChat to manually be put onto its own subnets.

11 Likes

Thanks for the more thorough explanations :pray:
I was having concerns in the beginning but now I can see that it makes sense.

Cheers !

2 Likes

We currently have a single user_index canister, a single group_index canister and a single notifications canister.

But now we need to have a ‘local_user_index’, a ‘local_group_index’ and a ‘local_notifications’ canister on each subnet. This minimises our calls between subnets which makes everything quicker and cheaper.

Say we wanted to upgrade 70k canisters on a subnet, if those upgrades were done across subnets the upgrade would take days and be extremely expensive because every call would have to go through consensus between the subnets, whereas if those calls are handled on a single subnet, then no network requests are made and nothing needs to go through consensus.

So in order to become multi subnet we have simply had to add another layer into our canister hierarchy.

Rather than going user canister → user index, it now goes user canister → local user index → user index.

There were quite a few other changes involved but that was the main bulk of the work.

4 Likes

So a few clarifying questions:

Is any part of OpenChat currently running on a system subnet or internal test subnet?

In the past, DFINITY has paid for OpenChat development (team salaries + app costs). Is this still happening?

Why does each user need their own canister, especially since the majority of OC users don’t pay to reserve a canister? Why not only give a user a canister if they pay for it?

1 Like

Is any part of OpenChat currently running on a system subnet or internal test subnet?

No, all of OpenChat’s canisters run on the eq6en subnet.

In the past, DFINITY has paid for OpenChat development (team salaries + app costs). Is this still happening?

Yes, OpenChat is funded by Dfinity. In return for this funding, Dfinity will receive a small portion of the CHAT tokens when the decentralisation sale completes. These tokens will be locked in neurons with a vesting period of 1 year which must pass before they can start dissolving.

Why does each user need their own canister, especially since the majority of OC users don’t pay to reserve a canister? Why not only give a user a canister if they pay for it?

Having 2 models, 1 for premium users and 1 for free users, would add additional complexity so we opted to simply give every user their own canister. The cost to create each canister is small and it is likely to come down over in the future as the IC becomes more efficient and is able to handle more canisters per subnet.

3 Likes