[IDEA] Dependency and Execution Driven Drips

,
1

I had a conversation with @bordumb about what Radicle is trying to achieve long-term and just wanted to jot down a few takeaways from the conversation so they don’t get lost.


Note that all of these ideas are feasible and rather impractical but can be seen as “North Star” ideas that are at least 5+ years out.

1. Dependency Driven Drips (DDD)

Idea

If a project X has a dependency on project Y, and both are “registered” with Radicle, then a small portion X’s revenue is automatically delegated to Y.

Potential Implementation

Depending on the project’s language, the language-specific dependency management mechanism (mix.exs for Elixir, requirments.txt for Python, go.mod for Go, etc…) can be parsed to build a tree of dependencies.

Benefits

  1. This will make developers be more diligent with their dependency management by only adding and keeping dependencies that they rely on. This can lead to an increase in the overall health of the project.

  2. Developers of open-source packages will automatically get paid for their contributions.

2. Execution Driven Drips (EDD)

Idea

An extension of DDD is EDD. If a project X has a dependency on project Y, and both are “registered” with Radicle, then a portion X’s revenue is automatically delegated to Y proportional to the amount of time code execution spends in Y’s source code.

Potential Implementation

Project X will be periodically profiled (exact mechanism TBD) to see where most of the time of the code execution lies. A graph can be built so the proceeds from project X can be delegated to its list dependencies proportional to what the profile shows.

Benefits

  1. This will allow projects to put a dollar amount of how important a certain dependency is to their product.
  2. This can signal projects as to when it may be worth building something in-house instead of using an external dependency.
  3. This can be used to build a leaderboard of highly profitable (and potentially inefficient) projects and provide incentives for others to build alternatives. This will also incentivize open-source projects to keep their code as efficient as possible so that their users to not use or build alternatives, leading to a healthier software ecosystem.

Caveats and Dissenting Opinions

There are a lot of caveats here including:

  1. What if project X simply copies the code from project Y without having an explicit dependency?
  2. What if project Y is responsible for doing a lot of heavy compute while the core product bringing value to the user is X, which only comprises a small part of the code execution?
  3. What if X spoofs or misrepresents their project profile? How do you guarantee Proof of Profile or Proof of Execution?
3 Likes
2

Hi @Olshansky

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 README.md file.

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.

Vision

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.[1]

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[2][3].

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. [4]

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

Type Users
No SSH Key 1225
only RSA keys (one or more) 2550
only ed25519 key (one or more) 437
RSA and ed25519 keys 754
others 44

1451 users only had one RSA key defined. Which increase the likelyhood that the key is still actively used.

Problems

  • 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.

Oracle Problem
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.

ENS/Identity Problem

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.

Get involved

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.

Reference

2 Likes
3

With regards to both Dependency and Execution Driven Drips, those sound like valid heuristics that the project maintainers might use to decide how to set up the percentages of incoming revenue.

Having said that, I have to admit that, first and foremost, I am struggling to cope with the idea that maintainers will want to drip to all of the libraries they depend on, one way or another.

This has nothing to do with Dependency Driven Drips or Execution Driven Drips. It has to do with an entirely different problem: Open Source Software projects are almost in their entirety under-funded and there is simply not enough money to go around.

At the time of writing this (and I hope Radicle Drips significantly helps improve things in this area), I believe this is the main problem that Radicle Drips must focus on, above all else.

Once the money finds itself within Radicle Drips, I think we can worry less about automating the decision making around fund distribution and leave that to maintainers’ capable hands. I would assume this is a manual decision to begin with?

4

I was also intrigued, but then a couple of potential problems popped into my head this morning:

  • execution time depends on the workload type: if I run the same app A, that depends on libraries X and Y, in two production environments P1 and P2, where the app serves different workloads, with P1 favouring execution time in X and P2 favouring execution time in Y, then it is clear to see that depending on which production environment I have telemetry data from largely shapes how my app distributes funds to its dependencies. :confused:
  • it is easy to game and creates a conflict of interest: as the library maintainer, once I know that the apps that use my library send me money depending on how much time their runtime spends on my library’s lines of code, I suddenly have an incentive for their apps to spend more execution time in my library code. (perhaps this creates a little less performant libraries?)

+1 :+1:
This is also in line with the discussions I have seen over on GitHub - openfare/openfare: Micropayment funded software. chat channels. Maintainers are best informed to make the final decision.

Let’s make that a drips.yml or something, so it’s not dependent on any other pre-existing file. Not everyone has a package.json and some people prefer asciidoc over markdown, etc. etc. :slight_smile:

When I read just this line, I really don’t see the problem being the ethereum address existing or not. I see the first problem a little earlier: the funds existing in the first place. Once the sponsor exists, incentive also exists for maintainers to create the ethereum address and start receiving money: the faster they create it, the sooner they can start receiving.

I do understand that dripping to projects before they have an ethereum address sounds promising and that it further incentivises maintainers and will speed up radicle drips adoption. However, it seems to me that the very existence of an Ethereum address (in a predefined file, for radicle drips) defines a very clear “opt in” step that maintainers can take to indicate that they want that money in the first place and I am not so sure we should be trying to skip that step… :thinking:

Some cases where maintainers may not want to receive money:

  • they are already paid by some company to work on the project. A different revenue stream creates conflict of interest between the company they currently work for and the drips sponsors.
  • they are not comfortable receiving money for their work on that project, as that completely changes the dynamics: if I publish something with an open source license today, it is my gift to the world and it usually comes with no warranty. That story changes significantly if I start to receive money from the people using it and maintainers may not be comfortable with that.
  • taxation could come into play (depending on the country and the crypto-related legislation)

To sum up, it seems to me that Radicle Drips should prefer a stricter “opt-in” flow, rather than something that could also be called “opt-out”.

Going for the “strict opt-in” flow also solves all these logistics problems.

In all, as a more general comment, if I may: Even if Radicle Drips only implements “Drips to any Githubs project with an Ethereum address” (which also seems to be the simplest case to solve for) and manages to turn just that into a success (in terms of money actually making its way into the hands of maintainers), that is already a HUGE success, solving a HUGE problem in the open source community, which hasn’t been solved for many decades. Radicle Drips will have earned our eternal gratitude, for decades more to come!!

As such, I guess I’m seeing that first peak as already too high and I’m struggling to imagine on what the rest of the journey looks like beyond that… I just want to focus on that first peak right now, I guess. :slight_smile:

5

Just dropping a small details I noticed on GitHub.

It’s rather buried in their website.

It seems like a very simple approach.
They probably just do what we’re talking about above (querying your code base), then looking up which of your packages/libraries have an account you can send support/funds to.

Link: Explore GitHub Sponsors · GitHub

image
image2064×660 76 KB