Today, I’d like to present a new approach to developing applications on the Internet Computer.
This vision tackles key ecosystem issues and, if done right, could completely redefine Web3 and create the foundation for a new economic era. The following article contains a high level description of the vision.
I’m opening this topic to anyone interested in discussing or challenging this vision. The article assumes technical possibilities, mainly the ability to place internal actors within our canisters.
While I don’t see any fundamental obstacles that would make this vision impossible to realize, I understand that a lot work is needed to make this real, and many questions need to be answered.
It is easier (and much more efficient) to implement on IC core level, by creating “sub-sub-nets” or “tightly connected” canisters that would use regular await, but work at speed of one canister (with await* instead).
Yes, that approach is possible, provided the developer experience remains consistent with what is described in the article. However, I’m curious about how users would ‘own’ this sub-sub-net. It’s not just about facilitating easy communication between canisters; user ownership is a central aspect of this new paradigm.
After a few more conversations. I believe it doesn’t matter whether we use a single canister or multiple canisters as a group. What we need is:
All canisters must be owned by the user.
The system should provide a coherent and trusted computational environment. Inter-canister calls within this group should not require consensus or suffer from trust issues associated with calling other canisters.
From an external perspective, the group should appear as a single, unique actor that can be called and interacted with.
A cohesive building experience with what building a canister looks like today.
My original idea was to have canisters within a canister, but that’s just another way to approach it.
Inter-canister calls within this group should not require consensus
Already, several inter-canister calls in a single subnet are almost as fast as a single call. So, in a sense, inter-canister calls on a single subnet don’t require consensus.
or suffer from trust issues associated with calling other canisters.
You mean the issue with infinitely long not answering to a call that prevents a canister to be reinstalled? That should be solved on core IC level. It should not be our task to solve this.
From an external perspective, the group should appear as a single, unique actor that can be called and interacted with.
The main issue here is that as the memory grows(or rather the size of the params of the call grows) you take a bit of a hit because the memory across actors is not shared. If you want to process something of any significant size the canisters have to copy the memory to the new canister. A single actor solution would be able to just reference the existing values in memory.
For small payloads this should be negligible, but if you want to process files or something like that it may not be as fast or give you as much processing per round as you would like.
It is possible to introduce shared memory areas. Not sure if it will speed-up a lot, however, because memory copying is already fast.
It could have the interface like:
stable var sh = [];
...
shareMemoryToActor(sh, anotherActor)
(not clear, how to implement it on WASM level, however; maybe the API should be tuned to ease implementing it in WASM).
However, I feel that your focus on performance is wrong. I propose to focus first on functionality. Otherwise, it is what since Donald Knuth is called preliminary optimization.
I doubt that it’s worth to hack the core for this apparently minor performance improvement. If I were a member of DFINITY council, I would be now unsure whether to vote for or against this performance feature, because it would increased complexity of the system, for an unclear advantage of a possibly minor speedup.
Good read, I like this problem, yeah, perhaps it’s big enough we could dedicate this OIS to solve the problem of Open Internet Services.
I agree with the size of the problem and the problems shared. But I profoundly disagree with the solution. Sorry, but sharing (leaking) state on things that you assume is private / under control, is definitively not the way to go
Maybe the solution is more of a “hybrid” between the current model (of code libraries / packages and what Ethereum has).
I like Jordan’s idea of tracking packages and just be “public” about which ones you are using. Then a “service” needs to figure out how “much” a certain canister is earning (by tracing transactions) and showing it on a graph somewhere. Then we can see if “earners” are paying their “social redistribution fee or not”.
As soon as you make this visual, then you create an economy, and you will flourish the packages dev economy and the “public” services economy in consequence.
Sorry, but sharing (leaking) state on things that you assume is private / under control, is definitively not the way to go 
