I have also collected a number of technical problems that plague the developers of IC, which are not directly related to the SNS-1 decentralization sale but reflect the current dilemma of building applications on IC, and I list them below。
1. Question about Canister Output Message Queue Limits
If a user request contains a chain of multiple awaits, when the request is not processed. After other user requests come in, their await will be interspersed, so that the number of output queue will soar and then exceed the limit and finally report an error. If canister doesn’t distinguish between internal await and external await, it’s hard to handle concurrency, and it’s hard to implement DEFI projects.
3. How does the user connect to a properly working node?
When the user gets data from canister, the route is proxied by ic0.app and if the node being routed does not work properly, then the user will get the wrong data. Therefore, the user needs a list of nodes to choose from. and have ic0.app route to the node that works properly.
Nat, as a base type for Canister development, does not support rust standard serialization other than candid (such as cbor\json\bincode), need to add support to facilitate developers to implement their own serialization optimization.
Or the best serialization and deserialization solution can be given, both the size after serialization and the efficiency of serialization/deserialization should be taken into account.
Since long links cannot be established between icp boundary nodes and the browser, I have to send all requests to boundary nodes at once to ensure performance.
When I send these requests, either to fetch data or to upload data, the feedback from the boundary node becomes very unstable after a certain threshold, and many requests become difficult to guarantee QOS after a certain threshold (about 300M of data fetched in a short time).
Solution: The condition of rejecting POST requests should be changed or websocket should be added as soon as possible.
7. Adding an optional unique Principal ID for II
Internet Identity (II) is a great way to log in, but Principal inconsistencies make it difficult to interoperate identities between Dapps.
Users should be given more options. IIi should add a parameter to the login screen, or use means that would allow users to choose whether to keep a uniform Principal ID across Dapps.
8. Optimizing upload and download of large files
When a large file is uploaded and downloaded, to ensure the speed of the upload and download, I need to respectively.
When uploading, I need to slice the file into n 2M size chunks to upload.
When downloading, I can get up to 3M in size each time.
However, if a file is large and I want to get all the data, there are only two options.
Send all update requests or query requests to the edge nodes
Create a long link, and go to http_request, but http_request authentication is very troublesome
Solution:
Establish a long link to the edge node websocket (long-term recommendation)
Increase the load of single-ip post and get requests (short-term recommendation)
9. Optimizing the motoko-base library
The data structure algorithm of Motoko-base library is crude and inefficient, and the use of RBtree and Trie does not tidy up the structure when deleting data, resulting in growing space.
The unit test of Motoko-base library is not comprehensive, it is not tested extensively, boundary test, and there are many bugs.
These problems above are commonly reported by developers that DFINITY Foundation doesn’t pay enough attention to them, which seriously affects their development progress.
Just imagine that one or more of the following issues will keep causing developers’ applications (say a DEX) to fail or even lose user assets, which will result in users losing confidence in the application, the DEX project will get shut down, developers will have to leave IC, and eventually, IC will become no man’s land.
I think this problem wasn’t so serious as there was a workaround and if I understood the issue correctly then the new async* keywords solves it entirely: See the latest motoko release: Release 0.7.4 · dfinity/motoko · GitHub
See the release notes for the async* keyword.
What does “long link” mean? The automatic translation chose an uncommon word here, so I am not sure what the meaning was originally.
When you send many requests, do you keep the http connection alive (“keep-alive”) or do you use http2 multiplexing? It works well, reduces the load and reduces failure rate. That said, at some point you will hit a threshold were you will see failures. But if you cap the rate of requests below the threshold it should be fine.
I personally like that the II protects not only my privacy but also my security. That I can just carelessly try out new dapps quickly, at the press of a finger on the fingerprint sensor, without having to think if I risk funds in other apps or risk a privacy leak. That is brilliant. I am happy to have the small inconvenience if I have to copy-paste a principal from one dapp to another dapp.
I agree that there is room for improvement to make certain flows and connections between dapps more frictionless. But I am still happy that the highest privacy and highest security is the default and that lowering any of the two must be an “opt-in” feature.
We don’t need to copy everything from the Ethereum/Metamask world blindly. There are things that can be improved.
It is also worth to note that above OP saying is already solved and thus since a while now. Devs can already implement derivationOrigin (specification) or build there own authority layer at the top of II in their dapps (as I do in Papyrs) to keep a uniform Principal ID accross Dapps.
Thanks for the docs. But I still have a question about it.
Let me describe more accurate.
As far as I know, AstroX’s ME Wallet(A smart contract wallet that differs from other EOA wallets like Plug and Stoic) has implemented a function called “Global Mode”, which keeps the wallet address across different DApps consistent. But there is still a problem that the “original wallet address” and the “wallet address across DApps” are still different. Therefore, users still have to transfer the asset in the ME Wallet to the DApps’ wallets before they can use DApps. I wonder if the problem above has been sovled?
If there is something not clear to you, please try it yourself: https://astrox.me. Install the mobile wallet and then log into ICLightHouse DApp in the wallet. You’ll find a new wallet address that differs from the ME wallet.
Please try it: https://astrox.me.
Install the mobile wallet and then log into ICLightHouse DApp in the wallet. You’ll find a new wallet address that differs from the ME wallet. And that’s my point.
Currently not in my plan but if I ever got time (I’m currently working a new super side project for frontend devs on the IC that canibalize my resources outside work), will let you know.