Decentralize Tip4Commit

[arsenische]

We thought about Tip4Commit as about non-commercial community-driven project.

But we hold a domain name, a bitcoin wallet, a database with information about money and users. That's a great responsibility we don't really want to deal with.

We have set the minimum tip amount to 50 000 satoshi to prevent money from being stored forever.

Since our initial idea about enabling everybody to donate to any opensource project was not well received by some of the project maintainers, we made tip4commit opt-in for them.

And now maybe it is time to make the next logical step: to decentralize tip4commit by enabling project maintainers to deploy their own instance of it.

Here is how it could work:

1. Project maintainer clicks "Deploy to Heroku" button and specifies some basic parameters
2. Donated funds go directly to project maintainer's bitcoin address
3. Project maintainer's cron job distributes tips among contributors
4. Bitcoin addresses of contributors should be fetched from Gravatar

Thus project maintainer would have the full power over the tip distribution algorithm and the donated funds. We won't be touching the money and won't hold any critical piece of information.

Tip4commit could just contain a list of projects that have its badge in README and perhaps automatically check via blockchain whether they really distribute tips according to their policies. That should attract new developers to funded projects.

This is just a general idea, many details need to be thought over, would be thankful for your comments.

[bill-auger]

broadly speaking this is o/c feasible but as proposed it seems quite a step backward regarding features and would require more routine attention of the project maintainers - as i understand the original intention of the app was to require very little to nothing of the project maintainers - then it would seem this initial proposal is in conflict with that ideal and may be unacceptable to some current users

unless each project maintainer is to run a full tip4commit clone for their repos then any features that are disabled or removed from the main site would need to re-implemented in the new maintainer client with a significant amount of work to be done on both ends - or else the maintainers would be left with no support for the routine tasks such as accepting donations, collecting and storing bitcoin addresses, deciding individual tip amounts, etc - these would need to be done manually

the Principal of Occam's Razor would suggest removing from the main app only those bits that are concerned with the transfer of coins and write a very small new maintainer client that does only those things - all of the existing GUI features could be left in tact as well the existing worker loop with only minor deletions - the existing worker loop could carry on fetching commits and the front-end registering users as is done now - then the client cron task could simply poll for updates of pending tips, bitcoin addresses, etc - projects could be registered automatically upon the main app receiving any such poll request and as long as it can locate a tip4commit badge on the corresponding repo README.md

this would allow project maintainers to direct new contributors to the main tip4commit site to register their bitcoin address and also to use the existing GUI features such as "decide tips" if they wish - in this way the project maintainers would need only to install the cron task and the javascript badge once and then could continue on as if nothing had changed - also visitors could still donate to projects on the tip4commit site if the project bitcoin addresses were still posted there and the coingiving site would probably not notice any change either

it would seem to me that none of the above requires any private or critical information to be stored - everything in the main site database would be publicly available elsewhere - even the bitcoin addresses and tip amounts will eventually show up on the blockchain

on the other end of the complexity spectrum would be to reduce the main website to a list only and re-implement the existing features in the client app - perhaps even a desktop GUI app that would not require a 3rd-party server - but o/c the time difference until completion would be large and this could not assist the project maintainers in collecting donations and contributor's bitcoin addresses without an additional client website

[arsenische]

The problem is that not only bitcoin private keys can be used to steal money, but information about deposits, commits, tips and users' bitcoin addresses too.

We are not security experts and can't hire ones for this non-commercial project. It is quite likely that in the long term at some point tip4commit will be hacked.

So far we didn't cause any serious damage to anybody but still received a lot of hate and fraud accusations. Just imagine what happens if someone alters our database and causes donated money to be sent to attackers.

We can't afford to be a single point of failure, this needs to be solved somehow.

Community said that project maintainers should be the part of the system. We made this project opt-in for project maintainers, this is a step backward... So be it, let project maintainers hold all the responsibility, they are used to this role.

Deployment on Heroku is trivial. Just press the button and fill a form, that's it. Any project maintainer is capable of doing it.

I think the current code base could be adapted to be deployed by project maintainers, all the features would be there except the following simplifications:

• there would be no user balances because we don't want to accumulate tips on project maintainers' instances, tips will be sent out in sendmany transactions, minimum tip amount could be customizable, 0.0001 btc by default.
• there would be no information about developers, their bitcoin addresses would be fetched from gravatar (that is probably more secure).
• perhaps there would be just 1 project or a list of projects that belong to the project maintainer.

It is not clear yet how to list the projects on our site and generate embeddable tip4commit badge if we do it, perhaps different solutions are possible, it needs to be discussed/thought over, maybe this is not required at all.

[bill-auger]

ok i think what you are suggesting then is essentially that the existing site be split into two sites - with the project, user, and coin management controls being hosted by the project maintainers along with the tip script - and the main site retaining the aggregate data pages like the Projects and Tips #index and #show pages

the one thing that is clear from the perspective of a contributor to this project is that whatever is decided will be a significant change and for the time being this leaves contributors with not much to do because until this issue is decided it is not clear which of the existing portions of the codebase will still be relevant in the next form - i have for example expanded the test suites and there are still some gaps but i should probably stop writing any more tests because it is not clear which features will continue to exist - also i have begun integrating support for bitbucket in the main app by distinguishing projects and user identities per host but it could be now that only the tip script would be concerned with the host distinction

my original reply to this thread was to layout the minimal approach - anything beyond that is likely to affect every class in the app in some way (and all of the tests) which puts the project essentially on hold until some plan is decided as there is not much point in writing another line of code for the main app until then - id be happy to attend a real-time scrum if that may help to move things along

regarding the badge in the repo README this would not need any javascript - all it needs to do is to request the badge .svg image from the main site (as it does now) - the only change is that the main site needs to have the url of the project tipper app so it can request the current 'next tip' amount for creating the .svg image - the url could be entered into a form on the main site manually when the project is registered then the existing badge would need no modification - to get a bit fancier as i mentioned before projects could be registered automatically by the tipper script if it authenticates itself as a collaborator but manual registration is reasonable and could be implemented quite easily

[arsenische]

Well, if we do the very minimum, the whole site could be moved to maintainer's side.

Tip4commit.com could just contain a static content with the "Deploy on Heroku" button and also serve a static tip4commit badge for all projects that already have it embedded. We could help project maintainers to migrate existing projects and transfer funds to them. That would be iteration 1, the most important one.

Perhaps in iteration 1 we could also get rid of user balances and fetch contributors' bitcoin addresses from Gravatar. That would make everyone's life easier since users won't be required to sign in to every project they contribute to. Even contributors who don't know about tip4commit would receive tips if they set up a public bitcoin address in Gravatar (I hope they wouldn't complain about "bitcoin spam" and it doesn't contradict any TOS, not sure about it).

In the following iterations we could implement a list of projects at Tip4Commit.com (similar to Project#index) with links to project maintainers' sites. Projects could be added manually or automatically. Perhaps we could collect some information from matinatiners' sites and blockchain to show financial data, and we could implement dynamically generated badges on our side (or maybe they should they be generated on the maintainers' side?). Not sure about the details yet.

You are right, would be nice to discuss it in real time, I've added you to my skype contacts.