While having an informal discussion on X/Tweeter, I learned that more experienced developers than myself think that “composability” in the Internet Computer is an issue because every call that a container does to another container needs to through a round of consensus, so chaining few update call can be very slow. As a consequence, devs tend to design dapps with a monolithic mentality and do not think them to be later composed with other dapps.
My guess is that this is common for many block chain that need to validate each transaction through some consensus algorithm among distributed peers. So I was wondering if this is really a limitation and if it is a real limitation what can be done to alleviate it. For instance, if I use intercanister query calls to reduce latency, is there a way to validate a state change in a remote canister (e.g. N hops away)? perhaps though some sort of shared state between canisters?
I’d argue that the IC has an immense potential for composability. We lack some important pieces of code infrastructure(but many are being built) but the possibility is as much there today as there was two years ago.
The biggest driver that has resulted in the lack of composability to date has been good 'ole capitalism’s reality that walled gardens are easier to fund than open public goods platforms. We should have composability standards coming out of our ears because if we did, we’d win…but instead, the economic environment has created a nest of scratching and clawing entities just trying to survive. Often that involves making the expedient choice instead of the long-range win choice.
Overcoming a two-second latency is a solved problem in software architecture. The patterns that solve it are not trivial and are rarely employed by the ‘just out of bootcamp’ coder. We need lots of those folks banging off the walls as well, but some hard-core architecture will go a long way to solving some of these problems. We’re working on it! 
Where can I learn more about these patterns to enhance composability without giving up on latency?
I like the gardening analogy, we should expand on it, phun intended.
- Gardens are often nested. Gardens within gardens. Usually blockchain->niche protocol or platform->apps or communities->users
- Gardeners benefit from sub-gardens collaborating openly and the good ones sometimes incentivize and develop tools for that.
- Gardeners don’t trust other neighboring gardeners.
- Sometimes a lot of gardeners end up growing the same crops and producing a lot more than what’s needed.
- Gardeners usually make sure they hold the exists and control cashflow, make incompatible tools, print brochures & guides on ‘how to grow crops’, but never grow crops themselves, instead grow gardens. It’s the user who is supposed to be growing the crops at the end.
- Gardeners try to sell their business to investors by providing unprovable stats and forecasting of immense gardener growth, but nobody buys that, they just end up annoying the other gardeners.
- You can hardly compose/ use the tools made for another garden, they have incompatible sockets
- Users don’t care about the gardening business, but the products they consume.
- Investors don’t care about what users consume, nor the gardeners, but how big of a land plot that’s producing valuable crops they end up owning.
We should probably fetch a pro gardener to help us with this.
Some basic and obvious building blocks could radically simplify how composable apps are built on IC. These are most likely already being worked on by someone within the ICP ecosystem?
- Users and user profiles. New identities for all IC apps is great for privacy but less great for composability. In many cases you want to bring your profile from one app to another.
- Groups. Generic way to create groups of users. Membership rules, group names etc.
- Roles and permissions. Role based access control, which user can do what in which context?
- Agreements on how to communicate. Inter canister communication exists, yes, but no standardised way of structuring requests and responses. Something like HTTP for canister messages - a simple standard all developers can get behind.
- …
If the internet computer is going to be truly an internet… computer… it needs all the layers in the computer stack. Low level services: Storage, communication protocols etc. Mid level: users and all the stuff I listed above. High level services: notifications etc.
With the building blocks in place, we need a canvas to paint on. Something like X11 or Windows but shared and multiplayer of course. Imagine a frontend platform simply called “the platform” that supports all core services needed for composability as well as an IC App Store. One login gives you access to all apps on the platform. All apps use the same core services and are interoperable. To create something like a Facebook group, just create a “Group”, invite some friends (“Users”). Give the group access to a “Comment feed”, a “Polling app” and a “Shared file space”. Boom.