Why the shade for p2p? Surely you don’t want to pipe every single communication through a ledger? As several projects have shown, the costs for doing this are prohibitive (and increasing) on this network. How do you propose solving this issue without p2p architecture?
Speaking of architecture, the ‘one user, one canister’ model feels like the wrong pattern for most cases. More broadly i think the notion of software provision is changing, and the IC will need an agentic layer that will necessarily include motoko, so those features that allow broad orchestration and self-organisation will be the most valuable.
I’m not against p2p at the right layer, but that is not the canister layer. People want to run long running process software on the IC and it doesn’t work without significant efforts(see the recent Wordpress port and what was necessary/still doesn’t work). Feel free to replace p2p with sql, llm inference, or any other potentially long running process.
Lemma: If it can over run the cycle limit, it will over run the cycle limit.
The only real way to avoid it is to write the software from the ground up to make overrunning the cycle limit impossible. This is much easier to do today than 1 year ago!
As far as one canister - one user. I’ll disagree kindly and strongly. It is the only real distinguishing-and-interesting use case the IC has(there are many other uses that are distinguishing-or-interesting but that is different). An always on wallet that is smart and can react in real time to other actors(smart or dumb) is the killer architecture of the next decade. Everyone is still getting their hands around using ONE llm to do cool things but soon you’ll wee that expand and actor based programming will find the spotlight. If we can get ahead and be ready when everyone arrives then we win if not subverted by hubris and not-built-here mentality.