If compute costs are to be increased (as suggested by this new motion proposal, whoever raised it) I would like this to be done intelligently rather than a blanket increase across the board (if feasible).
Specific apps that are spamming the network with lots and lots of little messages - architectures that do this unnecessarily without a second thought should be disincentivised.
Ideally, dapps that have been sensibly implemented should not take too much of a hit (at least in relative terms).
I support looking into raising compute costs. So I’ll probably vote yes on the motion, by I’m interested to see some more community discussion first.
Agree, there has been much discussion on the improvements that can be done to fix the issue. That said, the solutions won’t come soon and we need a temporary break / fix. I would prefer to remove all of Yral’s canisters. It’s obvious the subnets can’t handle the amount of canisters they deployed and so IMO it would seem fairer to me that all the other projects can perform optimally whilst we lose 1 project ( Yral ).
Sacrificing the individual for the greater good of the group is an excellent communist ideal, but might not be applicable to this situation. ICP was supposedly built to enable apps like Yral (remember Cancan?). If it can’t handle them, the best way forward is trying to fix the network rather than kicking out Yral.
Theres no need to turn this into a political debate. Yral would eventually be allowed to come back once DFINITY has fixed the issue. I agree Yral should be allowed but right now everyone is suffering. Ask yourself what is better:
Option 1)
yral is removed for a month until DFINITY fixes the issue
In the meantime everyone gets their apps working as normal
Yral suffers but they have the option of deploying to their own subnet to make it congested all by themselves
Option 2)
Everyone suffers until DFINITY fixes the issue ( TBA)
Irionically it’s more capitalistic to cut off the damaging / less performing members in option 1. A communistic group would let everyone suffer until there are no resources ( compute or scheduling time ) left
What makes you think Dfinity will fix the issue in one month? They have not fixed it over three years after genesis and eight years after initiating the project. At least right now there is urgent pressure to fix it because of the clogged network. Option 2 is therefore much better. Option 1 creates a terrible precedent with no guarantee of a quick solution.
I dont know if it will be one month. It could be longer and if that’s the case then option 1 actually grows in it’s appeal because we’d all be suffering longer. I do however agree with your point that the recent issue has shown a strong light on this issue. If you were DFINITY and you saw all the projects turning into the equivalent of digital bricks, would you prioritise it now or wait 3 months? New projects and developers will increasingly find that to even test on the main ic network will cost them more and more as things stand so it will choke off adoption if they don’t prioritise it.
Why do you think option 1 isn’t a guaranteed fix, it was never intended to be a long term fix. It only allows temporary relief while DFINITY fix the issue. It does rest on DFINITY prioritising this and I have seen in a different topic that this is their priority now.
Although I agree with the overall direction of targeted cost increases, it’s unfortunate this was proposed without proper deliberation of the issue on the forums first, and without a clear, data driven understanding of how these increases would affect different applications For example, there’s an inaccuracy mentioned in the proposal around pricing using the $5 per year figure which has always referred to storage pricing, not compute.
I had been talking to different members of the community over the past two weeks about cost increases to gauge sentiment/support, but raising costs are a sensitive issue - many projects research and plan around compute & hosting costs. I believe there’s a good argument to be made for increasing specific compute costs, but I was hoping to receive feedback first to see if this idea is even popular/feasible for developer teams before getting feedback on more specific cycles cost table increases from the broader community.
ICP main mission is to provide CryptoCloud services - feature that is seriously degraded for over a week (so far without proper fix and RCA - done or at least announced, my 2 cents).
Q: What is the reason for not publishing status of this critical functionality on https://status.internetcomputer.org/ (while even wiki, forum, … - not related to Internet Computer basic purpose - are there)
Regarding subnet migration, I have a question to @Manu.
Currently our canister derive keys for users to do e.g. threshold signature. I guess migrating to another subnet will change the key derivation path for all existing users (and thus their wallet address)? This sounds like it will cause a permanent asset lose for all our users if we really do the migration. It is kinda scary to even think about it.
My question: how much assurance we will have to operate in one subnet without suffering from migrating or splitting (which will change the subnet ID)? If we don’t have 100% assurance, we will need to seriously consider if we can keep building our product anymore.
E.g. consider what happens if the canister hosting the oisy wallet or II is forced to move to another subnet?
So there is one successful app on ICP - Yral - and the next step is to remove it, so that the not-successful ones (not important ones…) can run fine? What if some other is also successful and generates traffic - let’s remove it as well? This is ridiculous suggestion - from business and logic point of view it’s better to remove everything else but Yral
Also note, if a production app is removed from cloud, I’ll expect a lawsuit and immediate migration to other provider
ICP is not some school lab experiment any more, it’s a production service provider - and must behave like that if others should take it seriously.
That’s absurd. You think a successful client would come back after doing that? It’s like kicking them out and then begging them to come back. Completely irrational. In serious organizations you do everything you can to make sure your best customers stay your customers.
Yes, your canister id matters for the key derivation, so simply reinstalling your canister on a different subnet while using threshold signatures is not going to work. Subnet splitting makes sure all canister ids are kept, so that this is not a problem. The protocol does not offer an easy way to transfer your canister without changing id yet, so this is a downside you have to consider if you manually move your canister. I hope we can address this limitation with future improvements.
Rather bold of you to assume Yral is the most successful app on IC I assume you’re from Yral since you disregard all other projects as being “not important”. The key point you’re missing is that you can still deploy to a different subnet by purchasing your own subnet. I think having temporary controls on how many extra canisters can be installed onto a subnet would be easy to implement so that the currrent subnets wont get congested again. Remember, this is all a temporary solution, it isn’t suggested to be forever.
I’m not from Yral team but I’m member of the Yral SNS DAO. What you are suggesting is simply ridiculous, like if ICP was just a kids playground - if that’s true, don’t expect anyone to really use it - effectively turning ICP into another meme.
for everyone else with a project on ICP it’s already turning into a meme with the current scaling issue. If it doesn’t get fixed soon, you get the same result ( a meme chain that promises “infinite scalability” but can’t actually deliver it ). There are of course reasonable limits to “infinite” in the real world. I understand it would be a pain for Yral to move to their own subnet but now the entire eco system is having to spend a lot of time dealing with the mess, wouldn’t it be easy for just one project to migrate to a different subnet? I did propose that a community fund be setup and matched by DFINITY to move Yral to their own subnet, this is in a way compensation for being moved. If Yral were moved then we get a temporary fix. Yral would then be free to congest their own subnet whilst all the other “non important projects” can get their applications running well again.
I feel that you don’t get how serious problem this is, lets try other way.
Github is broken for over a week… Netflix is broken for over a week… Fortnite is broken for over a week… whatever successful is broken for over a week…
And Github, Netflix, Fortnite, … load is causing troubles also to other (much smaller - not successful - not important) apps.
For example, there’s an inaccuracy mentioned in the proposal around pricing using the $5 per year figure which has always referred to storage pricing, not compute.
I assume you’re from Yral since you disregard all other projects as being “not important”. The key point you’re missing is that you can still deploy to a different subnet by purchasing your own subnet. I think having temporary controls on how many extra canisters can be installed onto a subnet would be easy to implement so that the currrent subnets wont get congested again. Remember, this is all a temporary solution, it isn’t suggested to be forever.