[discuss] Add support for contribution and contributor creation

[bumi]

I got lost in the rabbit hole of writing a GitHub app. That probot setup is pretty cool.
Actually I wanted to see how the creation of a contributor could look like through an oracle... but now this now adds some features also hubot currently has.

The GH app can:

• create new contributions when a PR is merged
• create new contributor profiles

Flow:

if a PR is merged it will try to create the contribution. If any of the contributor profiles is missing it asks the user to add it.
An initial contributor can be created by providing an address in a comment.
Once all contributor profiles are available the contributions get created.

Note:

It actually supports multiple DAOs now in this one app. So it can be added to any GH org/repo. The DAO address is either configured through a environment variable (single install) or through a .github/kredits.json config file in the repository.

[raucao]

Just a general thought on this, before having looked at code: as we're in the process of moving away from Microsoft GitHub™ at some point in the not-too-distant future, I'd personally very much prefer to keep adding functionality to hubot-kredits (or extracting that to a seperate independent app), instead of creating a lot of GitHub-only functionality that will make the lock-in stronger than it has to be.

[bumi]

yeah that's for sure. I see this as one of many integrations... and this is the github-app

[raucao]

I see this as one of many integrations... and this is the github-app

Yes, so if integrations do the same things, just with slightly different hooks and target APIs, they can share a lot of code, like hubot-kredits currently. And it makes it easy to just deploy a single app and be done (incl. TLS certs, web proxy, logging, notifications, exception handling, etc.).

In fact, I was going to move the functionality of this GitHub app to hubot-kredits as well eventually, and just created the probot app due to time constraints with learning about how to register apps. But it's actually quite easy, and the relevant configs and code can now be copied over from here and potentially some probot sources.

[bumi]

actually most shared code should be in kredits-contracts. I was even thinking if/how those scripts I have in /lib should/can be moved to the wrapper.

from here not much else can be shared with other integrations as it is only GH specific code.

[raucao]

from here not much else can be shared with other integrations as it is only GH specific code.

It's not GitHub-specific at all. Every single piece of logic applies to Gitea as well, just with different JSON formats. I learned that while adding the Gitea integration in hubot-kredits. And the one feature in this repo right now, checking for labels and setting check status based on it, should also be added for Gitea, because it's equally important there. Same goes for any other source code/issue hosting like GitLab, Bitbucket, etc.

[bumi]

of course it should be implemented for as much services as possible, same goes with the other features here imo. That's out of questions. - just not in code currently, afaik.

As said the first things that I would move into kredits-contracts are some scripts that are in lib here.

• creating a contribution for a contributor object
• find or create a contributor by account details
• optionally waiting for the transactions to be mined
• initializing Kredits with a default ETH provider

then there is not much integration specific code left as far as I experienced.

But in anyway for me the most interesting discussion is, how the onboarding processes can look like.

[raucao]

But in anyway for me the most interesting discussion is, how the onboarding processes can look like.

Great, so let's focus on that, and not on where the code will be added in the end.

I think the comments of a PR are not the right place for onboarding someone for example. The PR comments should be mostly about the pull request itself, not about some optional contribution tracking system that lives elsewhere, in my opinion.

In particular, pulling out addresses from comments seems wrong to me, but also the entire concept of misusing GitHub for an extended onboarding process. You wouldn't e.g. add your Gitea or wiki account details, or other profile information, on GitHub. So there has to be some other UI anyway, which would then just make things more complicated and confusing again. (Not even speaking of lock-in and tying the onboarding to a specific platform.)

[raucao]

... I thought about this for a while, and I think we'd need some place where one can connect arbitrary OAuth providers in order to prove their identity with each of them.

But I have no idea where that place would be ideally, and what tech stack it could be using. For example, I wouldn't want to create a whole new Rails app with OmniAuth and the whole shebang. And also, it needs to support decentralized services as much as centralized ones, of course (i.e. custom Gitea/GitLab/Mastodon/etc. domains are as important as github.com). 🤔

(Also, some services don't support OAuth, like e.g. MediaWiki in our case. So for those accounts, we probably need a different solution.) Update: possible after all.

Edit: oh, and one more thing: I remember our last idea was to refactor the contracts so that one can create a contributor without an addresss. Which I think should mostly be possible already, as contributions are tied to IDs since our recent launch changes. So then we could at least theoretically always create a new contributor for unknown GitHub (or other) accounts automatically, without interaction, and then have the actual onboarding with adding address etc. be done elsewhere.

[bumi]

if anything then it must be a node app that we can use kredits-contracts.
I was also thinking if we can use keybase as source of verified profiles. do you have any thoughts on this?

[raucao]

I was also thinking if we can use keybase as source of verified profiles. do you have any thoughts on this?

Yes, certainly: It's just another centralized, VC-funded startup, that you don't want to depend on.

[raucao]

if anything then it must be a node app that we can use kredits-contracts.

Yeah, at least JavaScript, or something that can embed it. Makes sense.

[bumi]

which leads us to the big discussion: decentralization vs. usability.
maybe we then first need to define some guidelines and decide to which services we want to have integrations, how much centralized oracles are OK and what we can make the user to do.

[raucao]

I don't see any big discussion there. It's a huge difference if you pull in contribution data from other services, or if you depend on 3rd parties (or worse: a single 3rd party that is a VC-funded startup) for your own validations. I would never do the latter, and I see zero issues with the former.

[raucao]

how much centralized oracles are OK

I haven't seen a concrete proposal for using an oracle for the smart contracts by the way. Did I miss something perhaps? That topic is super interesting imo.

[bumi]

I don't see how any integration leads to a "dependency" on that service. (if we use github, data is pulled from github if we do not use github, then not - does not really affect kredits, does it?)
If we integrate a service like github we always rely on that service somehow as it is the service hosting the profile we want to reference.

re oracle:
an oracle is anything that allows to pull or push data from the outside world into the smart contract world. In that sense hubot-kredits is an oracle, isn't it?

So far there are no decentralized oracles, we can try to use services like provable - which we already tried with not much success so far and is also not yet very usable.

anyway, don't know where we get here...and it is more and more unrelated to this PR.

[raucao]

I don't see how any integration leads to a "dependency" on that service. (if we use github, data is pulled from github if we do not use github, then not - does not really affect kredits, does it?)
If we integrate a service like github we always rely on that service somehow as it is the service hosting the profile we want to reference.

The big difference is that we don't rely on GitHub as a central piece of our onboarding or other Kredits features (yet). It's just one of the various external services that we track, and not a dependency in general. We're already in the process of moving away from GitHub, and because we have our own code in hubot-kredits, whose architecture is completely GitHub-agnostic, all of the kredits setup couldn't care less where the code contributions come from. (67P/kredits-contracts#115 is another step towards making that even more irrelevant/flexible for kredits).

The beginning of this discussion was me pointing out that adding more code to the GitHub app is doing exactly that: increasing dependency/lock-in on GitHub, because it's tied directly to GitHub, and not possible to re-use for our own Gitea or other platforms. The same argument applies for introducing a new, hard dependency on Keybase, without which our onboarding process would break.

So, I would define the terms like this: if you cannot easily remove it from your setup without breaking core functionality, that's a hard dependency (e.g. Keybase). If it's possible to easily replace it with an open-source drop-in replacement, that's a soft dependency (e.g. Infura). Personally, I'd like to never introduce hard dependencies on VC-funded 3rd-party products, unless they're either FOSS and/or operating on a decentralized protocol. Main reason being that it's just not sustainable in the long term, and in the end empowers incumbent corporations to control our data and systems (when the company inevitably gets sold to one).

Another two issues with Keybase in particular, and that make it potentially worse than other possible hard dependencies, are:

1. Their success depends on network effect, so even if there were a FOSS replacement for us to host, it would be close to useless without all the existing users.
2. Our own new contributors would have to sign up with them. And if we make it optional, then at least we'd advertise how much easier it is to just do that, instead of connecting your accounts separately, which in turn increases the network effect that constitutes issue number 1.