very interesting proposal/ideas. We started doing a bit of research in that direction in the last weeks.
I like the idea of looking into the execution time as well.
I think in general the analysis of the dependencies or the execution time can help the projects to propose first potential receivers which can afterwards be modified. The project anyway needs to decide on a fraction they would like to keep by themselfes.
I think this thread is a good point to give a quick update about our work/ideas so far
Drips to any Githubs project with an Ethereum address
Currently, in Radicle Drips a
Ethereum address is required to start receiving drips.
Projects on Github would have to generate a Ethereum adddress to receive funds.
Project Ethereum address
Assuming a project has an Ethereum address, a Github project could add a Ethereum address to their
package.json or to a customized snippet in the
In the Drips App (Frontend) we could fetch the correct Ethereum address from the Github profile URL after analysing the project dependencies.
Here, we also see some open questions because a maintainer with merge permissions would essentially be enough to define the receiver address.
One of the main problems we identified so far, is how to get dripping to dependencies started.
We want to start dripping to Github users and projects before they have an Ethereum address.
This would basically allow from the beginning to drip to anyone and incentivises projects to collect their funds and start dripping to their dependencies.
Projects could make their decision on how to split their funds completely based on preference and dependencies without any impact by the fact if a project is already on Radicle Drips.
If funds are never collected after a period of time, they could be refunded, etc.
Idea: Drips based on Github SSH/GPG keys
One way to get this started could be to build on already known public SSH/GPG keys infrastructure on Github.
On Github the SSH keys are public available.
In the past projects were working similar things: airdrops to all Github users based on their SSH keys.
The idea we have in mind is to calculate an intermediated Ethereum for a Github users based on their public ssh key to start receiving funds.
This would not require any prior action by the user.
A user could later sign a message containing a Ethereum address he/she controls to receive the funds.
Later the intermediate address could be claimed by deploying a proxy contract on that specific address. After a successful on-chain signature validation, the control of the proxy contract would be given to the project Ethereum address.
Technically, this would work by using the
create2 opcode together with the Github user url as salt.
We analysed the public ssh keys from the 5000 github users with the most stars to get some first insights. 
Here the assumption was that users with a lot of stars might be more likely to receive funds and represent a good sample.
Results: SSH Keys Usage of the 5000 Github Users with the most stars
|No SSH Key
|only RSA keys (one or more)
|only ed25519 key (one or more)
|RSA and ed25519 keys
1451 users only had one RSA key defined. Which increase the likelyhood that the key is still actively used.
- SSH keys support different algorithms (rsa, ed25519, ecdsa)
- on-chain signature validation has high gas costs (only pre-compiled support like secp256k1 is cheap)
- currently most users have multiple ssh-keys
- keys might be outdated,lost or not stored secure enough
In general it seems risky to build on the ssh keys because we don’t know if keys are lost and not everyone uses them.
Currently only RSA signature verification would be cheap enough and only about 30% of the users had only one key. We are assuming here if only one ssh-key defined it increases the likelyhood that it is not lost.
Idea: Drips to Github projects without an Ethereum address
Github projects don’t have pre existing public keys. (except deployment keys, etc)
However, we could build on the similiar approach by calculating a intermediated address based on the github project url.
After a project defines an Ethereum address in their repo, we end up with an oracle problem to connect the intermedate address with the project url.
We need the off-chain information about the Ethereum adddress of projects on-chain from a source which can be trusted.
Github projects would have to be crawled on a regular interval and checked for potential defined Ethereum addresses.
A merkle tree could be build, where the leafs are a pair of the
- Ethereum address
- Github project url
The root hash would have to be updated in regular intervals with by trusted oracle provider.
The Ethereum address of a a project could later collect the funds with a merkle proof.
The complexity increase as soon as we rely on an oracle service or on any centralized authority to verify information.
Our idea is to build Radicle Drips as decentralized as possible, which makes it hard to drip to projects without an Ethereum address.
The oracle problem could also been seen more broadly as an identity verification problem.
It makes sense to build on existing infrastructur like ENS to assign an ENS name verify Github projects.
We are also looking into other existing identity solutions on Ethereum.
We are still completely in the idea, prototype phase and want to research more existing solutions.
If anyone wants to contribute you are very welcome.