Gitcoin Grants - CLR Match Round 6, and what to spend the money on

Lanski · 17 June 2020 03:54

The Gitcoin Grants CLR Matching Round 6 is here!

As you already know, for every DAI/PAN/ETH/Token you donate to a Gitcoin Grant, you signal support for a project in a way that you get to allocate part of the matching funds: basically, you vote where the funds should go with your money. You can donate as little as 1 DAI and it will be matched x10 or even x100 depending on how many people decide to support that project too!

This thread has two objectives:

1- Ask for contributions to the Gitcoin Grant!

And, if possible, donate with PAN token (which you can acquire here), so it will be double matched: by the Gitcoin Donors and also Panvala. (to understand why we will be matched by Panvala, read this thread by @alexvinyas and @jordimorris)

If you have ever used DAppNode and has provided you with utility
If you see value in DAppNode’s mission to eliminate technical barriers to digital sovereignty
If you would like to see the community grow and more packages being built

Then, please consider donating to our Gitcoin Grant. Every contribution helps!

2. Find a formula to empower this community to spend this grant on what they want to see in DAppNode

DAppNode is about you, the user, using it for what you want. And we want to spend the money from Gitcoin Grants on getting the content you want in the DAppStore.
This is why we want to spend the money from Gitcoin Grants to funding users that develop packages for DAppNode -AND MAINTAIN THEM!.
We have already funded a couple of packages, but there’s not really a good process that fully offloads work from the Team, who should be focused on the Core and on making improvements to ETH2.0 so DAppNode can become a bomb-proof self-hosted validation solution.

Here’s a possible solution:
1- We establish Usability Criteria (NO command line needed for configuration, all done through set-up wizard or in-package web-app like the ETH2.0 dashboard, for example)
2- We establish a “champion” that will be the one in charge of reviewing the package, ensuring that it works flawlessly and complies with the Usability Criteria above. This Champion gets rewarded for “project management”.
3- We (or the champion, if they have already someone in mind) determine a developer that will create the package. It will get paid for its work and for the maintenance of the package, should new versions come. If the developer wants to discontinue the updating, the “champion” could find another one that continues to maintain the package.

I can see how the champion and the developer could be the same person, and then this person finds another dev to continue the work if they can’t dedicate more time, or other combinations of roles and individuals.

This is a baseline model, but of course I’m super open to ideas for how you would manage this. The point is, I would like to “decentralize” package building and maintenance so the community can have more tools to make DAppNode into what is useful for them, and we let the team focus on the Core improvements.

1- Which packages would you like to see? Would you be a “champion” for them?
2- Do you see another model that could work better?

kem · 19 June 2020 00:15

Which packages would you like to see?

Eth2 Lighthouse client - #2 by Edu - ETH2.0 validator - DAppNode

teku client also. with reliable backup and restore for each of the eth2 clients so that validators can be easily moved prysm, lighthouse, teku, when bugs are found.

kem · 28 June 2020 08:25

there are many packages needed. is there a list of what the team is prioritising?

where is Lighthouse in the list? how about teku and Nimbus?

it would be helpful to see what the team is prioritising because funding is limited.

Lanski · 29 June 2020 06:54

Hi Kem! I think that’s precisely the point: we want to stop depending on the team to create packages - that’s why the champion / Dev scheme.

I would like to see some feedback here to see how this could become viable. Maybe via a DAO? Offchain?

In an ideal world, the projects themselves would create the package as another distribution channel for their DApp, but we’ve seen that this is not happening. At the same time, it is impossible for the team to keep up to speed with all projects and know when they push a new release, packetize it and publish the package at sufficient speed. In fact, most of the updates are pushed when some user says: “Hey, this broke, there’s a new update that might fix it”, which is far from ideal! Second best to the projects pushing their DNPs is having the champion mechanism… or I’m open to other options!