I remember the evisceral reaction to it when Dominic announced it. Most people thought it was another way to fleece investors. To be fair, information was hard to get back then.
1 Like
Thank you, @lei for representing the ICP community and ICP investors with such a lengthy summary. It is much appreciated.
As we all know, ICP loyal fans are all over the world, on OpenChat, on discord, on Twitter, on WeChat groups, there are ICP’s most ardent fans all over the world. Most of us are not technical developers and have very limited computer knowledge. We only have the most primitive consensus and dreams, hoping that computer technology will still maintain the values of freedom, decentralization, and anti-censorship, to maintain our freedom of speech and data privacy. That’s why we have been investing and holding ICP for a long time.
Thank you also to the Dfinity’s technical team and @dominicwilliams for their patient and meticulous replies. Although most of us still don’t understand what you are saying, it is undoubtedly a great encouragement to see the leaders of the developers appear modestly in the community center.
Guys, please give the Dfinity and developers more time and patience. Please think about where you invest and buy a stock in the world, can u see the core developers and the boss come out to answer your doubts modestly and patiently, and appease your dissatisfaction. Not at all,all right? Only the blockchain and encryption community can see this.
So I ask everyone to give the Dfinity more patience and confidence. We will definitely see the ICP roadmap. Hold!
10 Likes
The problems around composability are not limited to principals. As far as I can see it, there are 3 separate issues that prevent the composability of services on the IC.
(1) II Principals generate separate IDs for different websites (as mentioned), which means an identity is not transferrable across different websites.
(2) Inter-canister calls to third-party untrusted canisters can prevent your canister from being upgraded, without inter-canister calls to untrusted canisters there really cannot be said to be any composability.
(3) Only the first canister in a chain of inter-canister calls has knowledge of the user agent that initiated the chain of calls. In Ethereum we have the tx.sender metadata included in the tx as well as msg.sender. In the IC, we only know of the canister that made a call to another service and not the end user, which prevents many composable services from being developed.
Ideally, all 3 issues would be resolved to enable composable services on the IC.
3 Likes
Psychedelic’s attempts to get Dfinity to back away from developing crucial infrastructure at the application layer were misguided, and were in part self-interested attempts to control DeFi and token issuance on the IC. That was a threat to decentralisation, and even for a 40 person team Psychedelic were a bit over-extended.
I think having dedicated teams work on single areas of focus would result in more interesting projects on the IC, and ultimately more competition between services.
Having said that, Psychedelic was right wrt the fact Dfinity should be laser-focused on the protocol layer. The fact of the matter is that other blockchain companies out there will be razor-focused on infrastructure and developer experience. Recent trends in blockchain have even specialised blockchain development into three components: data availability, execution and consensus, which can be optimised as independent modules. With so many other well-funded teams, and many other blockchain companies focused on sometimes just one “module” in the blockchain stack, there will be a heavy price to pay for not focusing on core infrastructure and developer ease-of-use.
Having said that, to me SNS/ICRC-1 and People Parties, which intend to bring us a common token standard, a way to bootstrap projects and mitigate spam on the IC, were good things and enhanced the developer experience and were IMO good for the community.
8 Likes
Hey @dominicwilliams thank you for taking so much time today to respond to this forum topic. It is very inspiring to read your explanations and vision. It would be great to see you interact on the forum like this more in the future. I know you are very busy, but engaging in a civilized debate when concerns are expressed by important community leaders like @lei is very smart and helpful. I’ve been inspired by your responses.
I also want to voice strong support for DFINITY picking up the People Parties functionality again. This is one of the roadmap initiatives that I have always believed is critical to decentralization for the reasons you outlined. Please pursue it full speed ahead, including asking for input from the community, but not letting the community persuade you to deprioritize it again. It might even be a good opportunity to offer contract with community members and/or organizations who have the expertise to participate on the team(s) that develops the solution.
10 Likes
I think that Dfinity is trying to create an end-to-end blockchain-based cloud computing solution, so the IC is destined to be a closed-loop ecosystem like Apple. This explains why Dfinity is developing SNS, II, and the People’s Party, which seem to be applications at the application layer. Am i right?
2 Likes
One of the best discussions and debates in the forum.
From a layman point of view, maybe not a popular opinion, but I do think that it is a mistake from Dfinity when trying to promote decentralization and letting the community be involved too much in this early stage of their network development.
In high tech, sometimes doing our own way and getting things done without listening too much from outsiders’ noises and opinions is not a bad idea.
To be fair, a 51% attack is also within the rules, doesn’t make it correct to attempt.
I agree to a certain extent, and I’ve already said that a benevolent dictatorship model can be quite effective during the highly iterative start-up period. However, once the community stakes become dramatically higher, there needs to be a transition plan towards more collective prioritization. Also, even under a benevolent dictatorship model, it would be very unwise not to keep a constant finger on the pulse of the community’s collective priorities, as I’ve argued above in this post:
3 Likes
Will that still be the case when ETH introduces sharding?
Yes, I believe that will be the case…
I like that suggestion from Dom. It is a capability that will help tools like Digital Time Capsule upgrade canisters controlled by user principles.
This is a good post. Thank you for Posting. Bump.
1 Like
The first canister A can just pass along the msg.caller information along in its call to the second canister B in the chain, and so on.
Yes, here A could forge the principal that is passes along to B while in Ethereum the tx.origin seen by B cannot be forged. But even in Ethereum B has to trust A’s code because the “origin” could have called A with a different intent, e.g. the “origin” could have not wanted A to call B at all and A being malicious could have done it anyway. So I think the forgeability is not argument against simply passing the information msg.caller along.
2 Likes
That is only if you make inter-canister calls that rely on system-guaranteed responses. There is a different style of asynchronous programming based on one-way calls. That style does not have the problem you describe.
In the pub-sub example examples/motoko/pub-sub at master · dfinity/examples · GitHub a subscriber can subscribe to a publisher to receive notifications (callbacks) on events. The publisher does not have to trust the subscriber in any way even though the publisher calls the subscriber on each event. The reason is that the notification calls used are one-way calls.
You can design any asynchronous communication around one-way calls. And you should if you call untrusted canisters.
1 Like
“Yes, here A could forge the principal that is passes along to B” … you have answered why this is not possible in the IC. The canister A may lie about who the user is. If B is managing canister funds, this is not acceptable as any caller can trick canister B into updating balances of arbitrary users under this design.
Your counter-argument is also unfortunately built from the wrong assumptions: as with all smart-contract code that handles money, the assumption is that you know what the code you are calling is doing. If A calls B with a different intent that is of no material concern to B, the responsibility is on the user to not call A if A’s code is malicious.
The fact is Ethereum has canister interoperability for the reason that it knows who the user calling is in a chain of smart-contract calls, and on the IC this is not the case.
On the IC, the assumption is that the downstream canister, canister B knows the code of canister A, which is a bad assumption in a world of interoperable finance. It means there can only be communication with a known set of canisters that have been deployed prior to canister B being deployed and whose code is immutable.
5 Likes
M understanding is that one way calls are also undesirable because of network errors, which mean that they may never be delivered. And if they are never delivered, the only way to really know about this without getting into a ping-pong match of one-way calls is to have request-response inter-canister calls working as they should.
2 Likes
Ok, I see what you mean. Thanks! I agree. We badly need capabilities on the IC which would solve this problem.
7 Likes
I am not a developer but I have followed the thread. Do you think that this problem can be solved in a coherent way without seriously impairing security or network speed?
1 Like
I also feel funny about this. I know this ICPL and I don’t feel they have delivered any work that worth 1 million USD.