Provision of core functions without so many APIs

[Ly0n]

After feedback from various members of the GNU Project here are some points that should help to make LibreSelery work in a decentralized way in a limited function. Using a platform such as GitHub or Libraries.io should be optional to enable additional functionality but should not be forced by the tool. I have now added the following goal to our Contribution Guide in consultation with the team:

The core function should be as platform-independent and decentralized as possible.

Let's take this issue to talk about this topic and how we can approach it. Here are several points we came up within the discussion with @jemarch.

We can read the email addresses of users from the git history. If someone uses their email address in a public repository, it's like making it public.

The dependency declaration should be provided by the project itself. This can be done through a file in the project, such as the tooling yml file we already have. This allows us to scan the software dependency tree directly through the classic git API used by most platforms. The creation of this list can be supported by an automatic dependency scanner, which is attached by a plugin. The user should also be able to decide what to declare as a dependency when using automatic dependency scanning.

The payment method can be made available in a decentralised way by integrating GNU Taler. However, we would have to provide the e-mail infrastructure ourselves at this point.

Please give you feedback on this topic. Where do you see problems, possibilities or other technical solutions?
@fdietze @cornerman @tjarkdoering @krux02 @EdwardBetts @ZeipsCode @kikass13

[jemarch]

I just wanted to add something else that we discussed last week, and
that I think is very important for the feasibility of the whole thing:
the support of "passive participants".

The idea is to distinguish between active and passive participation:

• Active participants get some money (from donations) then distribute
  it. They need to install the libre salery software, integration with
  taler, opencoin or whatever, and what not.

• Passive participants declare in a file in the source tree:

  • What their "dependencies" are.
  • How to distribute the money among the project's people:
    • Use a fixed list of contributors, equal parts, or
    • Use the git repository in this or that way.

  All passive participans should do to be in the "net" of lbre selery is
  as easy as adding a certain file to their source trees. This way, if
  you happen to be in the subtree of at least one active participant,
  then you and your dependencies will start getting donations! It makes
  no difference whether your source tree is in a github repo, or a
  release tarball, or an ftp.

Example: let's assume the GNU project constitutes itself as an active
contributor in order to cover all the GNU packages. The tree (more a
graph, because there may be cycles) could look like:

(* means active contributor, . means passive contributor)

* gnu.org
  . GNU coreutils
  . GNU poke
    . libtextstyle
  . GNU recutils
  * guix
  * GNUnet
      . GNU recutils
      * libfoo
        . gnu.org

The idea is that when the active participant gnu.org receives some
donation (using whatever system supported by the libre salery project)
it traverses its dependencies file recursively, and:

• If an active participant is found, send this active participant the
  money using opencoin or taler or whatever. Since it is an active
  participant, it will have the needed infrastructure for that. This
  active participant will then handle its own sub-graph.

• If a passive participant is found, read its LIBRESALERY file that
  specifies its dependencies, and also how to distribute the money among
  the participant's contributors. Prepare transactions (and send
  emails) for the participant's contributors, and then process the
  dependencies.

Note that there may be cycles: in the example above, a donation to
gnu.org may trigger a donation chain: gnu.org -> GNUnet -> libfoo ->
gnu.org. It occurs to me that the best way to handle the cycles is to
use a coinage form that allows to recognize particular coins. Then it
is possible for active participants to reject coins that have been
distributed by the participant itself in, say, the last month or so.

My 2 cents :)

[Ly0n]

All passive participants should do to be in the "net" of LibreSelery is
as easy as adding a certain file to their source trees. This way, if
you happen to be in the subtree of at least one active participant,
then you and your dependencies will start getting donations! It makes
no difference whether your source tree is in a github repo, or a
release tarball, or an ftp.

This would be desirable and should in my view also be technically possible.

The idea is that when the active participant gnu.org receives some
donation (using whatever system supported by the libre salery project)
it traverses its dependencies file recursively, [...]

In this way one could also promote the distribution of LibreSelery itself. For me there is still the question what to do if the project itself has selery.yml file. In this case you could simply distribute the funding randomly, as we are doing at the moment.

How to distribute the money among the project's people:
Use a fixed list of contributors, equal parts, or
Use the git repository in this or that way.
A fixed list could be the better option but also have problems. One of the main problems the Debian project had with the current implementation was the "opt-out". This would be solved via the list. See: #185

How to distribute the money among the project's people:
Use the git repository in this or that way.

At the moment I don't know how to clone only the commit messages and email addresses of a repo without the whole repo coming along. Therefore it could be very time consuming and resource hungry with many and large dependencies.

Note that there may be cycles: in the example above, a donation to
gnu.org may trigger a donation chain: gnu.org -> GNUnet -> libfoo ->
gnu.org. It occurs to me that the best way to handle the cycles is to
use a coinage form that allows to recognize particular coins. Then it
is possible for active participants to reject coins that have been
distributed by the participant itself in, say, the last month or so.

Finding cycles could also be possible the forwarding the original "Transaction Message"
At the moment we add the git user name to the "Transaction Message" like " @kikass13 Thank your for contributing to LibreSelery" but we could also create the message "from: gnu.org @kikass13 Thank you for contributing to libfoo". In this way you know the origin of the funding and avoid sending it back.

[kikass13]

I read the hole thing twice and Im still struggling with some apecifics of the provided solutions. BUT IN GENERAL,it looks fine.
We have to get our architecture stuff and internal gathering / payout methods generic and configurable at first, then we can think about your suggestions and implement them accordingly.

My goal is to enable automatic (platform dependent) and manual (more or less independent) dependencies (your whitelist suggestion) as well as easy interchange, implementation and configuration of all these use cases ... what works for GNU is a possible end scenario (config) for GNU, but right now, we'll try to figure out the basics and check on youruse case as soon as we are ready to test something like this :)

[tjarkdoering]

There is not much that I can contribute to this discussion from a technical perspective.

The core function should be as platform-independent and decentralized as possible.

However, I support this addition wholeheartedly. I know lots people who are not using GitHub but consider the tool interesting. And spreading the idea and lowering the hurdle of applying it to a project would be easier if it is as independent as possible.