SNS is just one of the many topics that DFINITY works on, and only a small fraction of the resources are spent on this. I see multiple people saying that they wish DFINITY would spent less effort on the application layer and focus more on the protocol layer, so they should be happy to hear that we spend the majority of our efforts on the core protocol.
I think we can reasonably say that the core protocol has made a lot of progress and is improving rapidly. In 2022 we released all of these features in the core protocol (and I’m probably forgetting some):
Bitcoin integration & Threshold ECDSA
Canisters can have 32GiB of memory & stable structures to support that
allow for installing gzipped canisters
deterministic time slicing (allowing for longer running messages)
Further to Manu’s point, I’d really encourage people to read this post. It contains the breakdown of R&D members on different parts (core protocol, NNS/SNS etc). As you can see from that, 43% of R&D is working on core protocol and we have shipped many (complex) features this year as Manu said. So, I’m not sure this criticism was very fair.
Sadly, when our developers submit bugs and requests, they are told that the foundation is working on SNS and that other work may be set to non-urgent. It’s disappointing that SNS-1 gave us this result.
2.1. Question about Canister Output Message Queue Limits
2.1 the new async*/await* in Motoko 0.7.4 addresses one half of this (producing fewer self sends with a modest rewrite of code that uses local asynchronous functions).
For Motoko, we are actively working on fixing the other half - allowing the user to recover from queue full errors instead of trapping - but that’s turning out to be trickier than we thought and will take time.
I also know that the replica team have been considering the possibility of raising the queue limits, though this is harder since some back-pressure must be applied.
2.2 Heap out of bounds" error when upgrading canister with Motoko
It’s still not clear what is causing the error. We have a suspicion and suggested a workaround. I have also been thinking about how we could arrange to reduce memory consumption of serialized Blobs and have a solution in mind.
Ideally, we would need a smaller repro for that issue to diagnose the root cause, although I appreciate that might be hard to produce.
2.4. Bug of Trie data structure
This is fixed in Motoko 0.7.4 (Motoko base tag moc-0.7.4). Thanks for reporting and helping us track down the bug. I still think that data structure needs further improvement though.
2.9. Optimizing the motoko-base library
This is valid but we are working on improving the correctness, performance and test coverage and have already pushed tests of some old functionality and tested new improvements. Covering the entire base library will take time.
I agree that base needs more testing (especially of older libraries) and development in some areas and that this should be ideally be prioritized over any other non-critical work.
It is true that the official team has developed a lot of basic work, but the result? It has been a year and a half since its launch so far, how many ecological applications are running well or give full play to the advantages of IC?
Yes, you may say Distrikt and Entrepot. As for Distrikt, how many users would like to use it instead of web2 social products? And Entrepot, the NFT standard is terrible for every new users to onboard. Compared with the Ethereum projects, these two projects have no obvious advantages, and their user experience is not much greater than web2 products. Why do users come and play?
Recently, even many projects including hackathon award-winning projects have left IC. I believe they will not make this decision without encountering insurmountable difficulties. As Peter Drucker said, start with the end. If the result is bad, it only means that most of the work is useless or it’s not the point you guys should focus on right now.
Some important NNS upgrades such as periodic confirmation got postponed too cause the team was busy working on the SNS. Maturity modulation somehow managed to slip through tho, despite being approved at a later date and with less approvals.
That makes it look like internal pressures are more effective than community’s feedback to shift priorities around.
And one more example to illustrate: The Principal ID. Dfinity thinks that users need security and privacy protection so they design delegation identity mechanism. But what the team didn’t see is that users just want a unified address/ID across different DApps.
For now, different wallets can’t import from each other because they use different algorithm. Users will only get different wallet address in different DApps if they use Internet Identity. Are you telling users to make more transactions when they switch DApps? Users say “No, it’s inconvinient. The user experience of wallets on Ethereum are much easier. Goodbye”.
Listen and observe more on users’ demand please, rather than doing what you think it’s great.
I am trying to understand the expectation here. You don’t have to use Internet Identity at all. You can just write a frontend or browser extension that takes in a private key or seed phrase or connects to a hardware token and uses the same key for everything (i.e. same principal everywhere). Why does nobody do that? Is the expectation that the foundation writes the “Metamask for IC”? I ask because I hear in other places that the foundation should not work on things on that level. Hence the question, what is the expectation?