The DAppNodeDAO manifesto

The DAppNodeDAO manifesto

As important as the technical build, there is the cultural build.

We have created the DAppNodeDAO with two (2) main objectives:

  1. Work towards a future where decentralized hardware infrastructure is more prevalent, easier to access and simple to run. It does so partly but not limited to the DAppNode software, partnerships with relevant actors, offering better tools, resources and community. I.e.: the ValidatorDAO. project

  2. Act as the channeling agent for the voice of small Node Runners. The DAO of the Indy validators, with a say on the evolution of protocols as a representative of all small Node Runners. It is an entity sitting at the table of the Infrastructure Providers representing those who run their nodes independently. I.e.: efforts to standardize an API to be able to run a standard UI with all validator clients.

But… what are the values of the people behind the DAO?

Can we crouwdsource some bullet points of what the DAO cares about?

I’ll start:

  • Create tools for anyone to be able to participate directly in decentralized networks without 3rd parties, eliminating technical barriers and educating potential Node Runners.
  • Strengthen the resilience of decentralized networks by providing an easy way to deploy nodes in diverse settings outside of the cloud, where they can be targeted and forced to shut down.
  • Coordinate Node Runners to present a united voice as the important Infrastructure Provider segment they represent.

Drop your bullet points here!

5 Likes
  • Provide a robust, stable platform that makes node setup and operation easy for everyone with basic technical skills.
  • Identify and fix common problems that users have, especially if they are using the standard DAppNode hardware and software.
  • Identify core platform DApps, and provide strong support for those, while providing a base for other DApps to be installed and operated

I cite these because I see a few recurring examples of user problems (like WiFi failing) and I think we ought to be able to resolve these for everyone, rather than making each user troubleshoot for themselves.

Prysm and Geth are clearly the most important DApps right now, so we ought to spend 80% of our time supporting and improving those, and 20% of our time on other DApps. We could also say that other Eth2 clients should be part of the 80%, and work to get those onboarded.

1 Like

I think hardware decentralization is realy important.

For the short term, I agree with ETHstaker’s vision for clients diversity. It is important that as many clients as possible are easily accessible so that more early validators can use dappnode hardware.

For the long term it will be more and more expensive to have the 32eth necessary to have a validator. This is why the integration of solution such as rocketpool or SSV will be useful.

1 Like

I think there should be something about creating an environment that makes it easy for developers to drop their projects into the DAppNode environment with minimal changes.

I’m reflecting on the fact that each new version of Prysm requires someone to customize it and configure it to work in the DAppNode environment.

If DAppNode becomes very popular, then developers will want to make there applications available on it.

To facilitate that, we should make it as simple and standardized as possible, so they can build their applications with that interface and/or API in mind. When they are ready to add their apps to DAppNode, it should require them to make as few modifications as possible.

Perhaps it could be summarized as:

Create a clear and well documented set of standards that supports best practices in application containers, to enable developers to easily port their apps to DAppNode with few to no changes required.

Fully agree about the need to have the documentation here be finished and well written like the parts that have already been completed, theres just many major sections still totally empty.

But you’re not quite correct about this part:

I’m reflecting on the fact that each new version of Prysm requires someone to customize it and configure it to work in the DAppNode environment.

This only is needed when there are major changes, the way Prysm and many other major packages are normally updated is actually automatically with a Github Bot that bumps the version to the latest upstream, pretty much in real-time, but to a new testing branch, and creates a pull request to merge the new upstream version into the master repo. The reason these aren’t merged and released just as fast is because just like any software and need to be tested by testers in a closed environment before just throwing something created by a bot at all the users. There could be some big new feature or other larger change that makes the bot created version not work, this is why there’re people in the middle to download and these test pre-releases for everybody finding any errors on their own in a safe environment that doesn’t risk any user funds.

It is pretty easy for people to create their own DApps already, the SDK has been available for years and the public DApp Explorer lists 126 packages at the time of this post. Yes a large majority of them there are heavily outdated and do not work anymore due to deprecation, project failure, programmer abandonment, or complete lack of public interest in it. But this will change. As the documentation for how to use the SDK continues to be written and filled, it. will become easier for people to develop on DAppNode, right now it only takes decent knowledge of docker, how the basic architecture of DAppNode is structured, and most of all the ability to build whatever you wanted to.

There is only minimal documentation currently for developing on DAppNode right now and thats an issue, but it’s in the works of being written, and furthermore there are plenty of human resources to be found on Discord specifically in the #developing-on-dappnode channel. Right now honestly, packaging up most applications/programs that are open source and host their own docker images already is a very simple and quick process to wrap that image in a DNP using the SDK and then publish it to IPFS and publish it all with the SDK. To be more honest I don’t have the skillset to do this yet, but I’ve been messing around with it for the last few weeks and am actually finally getting the hang of some of it, and I am not a programmer or coder by trade or education, aside from entry level classes.

1 Like