The current Cartesi Node has the primary goal of being the software that actual Cartesi validators will execute when validating DApps on Mainnet. This is generally at odds with the goal of helping developers quickly test their applications in a local environment.
For this reason, it could be interesting to have an alternative to the actual node, which would be tailor-made for development purposes: “Nonodo”
This would be like using Anvil or Hardhat for local development, instead of Geth. Ideally, this node would be extremely lightweight (e.g., entirely written in Typescript), making it easy for people to execute it without running Docker containers or anything. It could also be a more suitable setup for us to add development-specific features (e.g., easily save and restore node state such as the GraphQL database)
Currently, yes, but I understand in the near future we may have native distributions of Cartesi Machine binaries. Other than that, Nonodo could also support the current “host mode” way of doing things.
Given that it seems to have a consensus around that this task not being part of the reference Node and consequently not a task for the Node reference unit, maybe it should be a RFP.
I’m a bit out of my depth in this debate, but I think your description seems pretty reasonable.
For security reasons, the validator node should be as simple and auditable as possible, so mixing concerns sounds like the wrong way to go.
The tradeoff is on the comprehension aspect of it, I think. It’s one more software for people to know about and use. But maybe that can be hidden by a convenience layer, like sunodo? sunodo -dev-node (nonodo) vs sunodo -valididator-node
Other than that, I feel like improving the experience of newcomers is great. I believe that if they can start off quickly and understand the tech, they’ll be much more likely to face through the struggle of building an actual production dapp.
I think the design specifics of nonodo should be debated if this enters the technical vision plan. The line of ease of use vs unrealistic expectations vs code reusability etc.
But I find the goal of nonodo valuable and definitely think it should be a priority.
ps: @claudio.silva On the RFP angle, I currently think about this like this:
whatever doesn’t get prioritized by the vision council, but still received good feedback and is seen positively, should become an RFP. If it doesn’t get proposers, it gets rediscussed on the next vision council. But if it makes it into the technical vision, then there can be a taskforce created to focus on that, right? In a way the units become more malleable.
Not sure if this is the place to discuss this, but hit me up if you want to talk more about it and we can exchange views
We should consider implementing a non-node for a high-level framework instead of building it for the rollups HTTP API. The non-node node would call the DApp directly in the HLF API instead of setting up a server and waiting for the DApp to call it.
I think this topic touches a lot developer experience on running our protocol ill share my cents and tag payal for her awareness
1 - Developers having an easy way to test our tech and have a first engagement is paramount, specially during hackathon and first trials with the cartesi stack
2 - Nonodo should get as closer as we can get from the experience on using the cartesi. As i understand we can keep docker and get rid of voucher function would be already a very good simplification for nonodo.
My question is the devad team has any specific requirements that should be observed. @PayalPatel ?
From usability point of view, its important that Sunodo supports Nonodo and include it within the developer journey on design and launch its dApp @tuler
Great alternative to “host mode” and high priority for adoption
Nonodo is a top priority to facilitate faster onboarding and serve as a “playground” for the community. Although the specific approach would need to be discussed in more detail, overall, this tool can be extremely valuable for developers.
The main purpose is to create a simulation of the “real” environment without the need for nodes. I understand that there is a discussion regarding the involvement of Docker in this project, but regardless, the use of Docker is not novel to those who build using Cartesi. This aspect can always be further improved in the future as Nonodo (like all projects) should always evolve.
If this is considered a priority, the project must find a way to enable its implementation, whether through other units or collaborative efforts. While I fully support the RFP process, I agree with @felipeargento that this should be an alternative for low level priorities or ones that are not qualified by the council (but deemed to be positive), as we should also take into account that the turnaround time for RFPs might be longer.
One thing to consider is that Nonodo doesn’t need to start with the full features that host mode currently delivers. For one, support for proofs (to enable people to execute vouchers and validate notices) may not be that important to allow people (especially newcomers) to play around with how a Cartesi DApp works.
I like the proposals I’m seeing here. With that, we feel things are being aligned to the very same goal: to keep lowering the bar and increase the adoption for us. Independent of what the final solution for this will be, the important thing is to keep in mind that all the things we do and all our work efforts should be aligned with our macro objectives, those being aligned with our final “customers” needs.
Regarding Nonodo, starting to design the solution with the core features and then evolving it interactively seems the right approach. From personal experience, when first in contact with the tech, knowing almost nothing about blockchain, I intended to make any code I’ve done in the backend work. To send inputs to it and see the outputs being stored in the notice list. Then get these outputs to use in the front-end, knowing this would probably work when going to the production mode. I didn’t need to understand all the things underneath the rollups framework at all, I just wanted to know that my backend worked in a decentralized fashion. If Nonodo can bring this feeling to me, then it will be a great addition to replace host mode.
I think this is a good point; additional features could be added over time depending on the features that the community find most useful or are pivotal for their journey to explore. Just to get a better idea of this vs alternatives; how long would something like nonodo take on average with a first basic version?
Indeed Payal! As more community members use, more voice of customer feedback we get more insights we will have on what really matters for developers and make that reflect in our infrastructure.
Starting from the basic having that ready for developers and enhance from there is the right way of moving forward
I will write a MVP and share it with everyone in the following weeks. If you feel that it can replace the host mode in the node, we can move forward with this plan.
If Nonodo aims to serve as the testing version of Cartesi Nodes to enhance experimentation for DApp developers, it should be considered for inclusion in the technical roadmap list. Prioritizing the ease of local development testing and everything that streamlines the initial contact and user-friendliness of building with Cartesi tech is important, in my opinion.
I also feel this is a top priority to lower the barrier for onboarding on Cartesi and also to speed up development of applications.
Things like unit testing do speed up iterations on development, but they are not as fast to get started nor zero-setup as “nonodo” or the current host mode.
Also the current host mode is basically a drop in replacement of the production mode so it allows fast iterations with the rest of the application like the end or some external service using exactly the same communication format used with the real deal.
I think it is so important to keep this discussion on How do we make developer experience simple and smooth ? open. After interacting and observing first-time developers on Cartesi, I feel many of them are actually overwhelmed by the number of moving parts under the hood, especially when something goes wrong and they need to debug the error. Although the error may be related to something simple it is still hard to pinpoint what went wrong. Although Sunodo has done a tremendous job of solving the major problem of abstracting away the setup for getting started we still need tooling that allows people to test their DApp logic without having to get into the complexities of Cartesi infrastructure.
Nonodo can be a good solution for this problem and I feel will be worth the effort and provide a better ROI for the long run in terms of adoption.
