The Problem to Solve
As sigmike has pointed out, there is much room for improvement when it comes to funding opensource projects. Peertron is my solution to this problem. It provides a safe and sure way to allow patrons of opensource work to contribute to their creation, without losing control over their power of the funds.
[hr]
The Solution: Peertron
In Peertron, there are (will be) three different roles: Patrons, Beneficiaries, and Commissioners. Roles are assigned on a project-to-project basis, and are not “account types.” Patrons donate funds to a project; there can be more than one Patron per project, and any other role can also be a Patron in addition to their current roles. Commissioners are the moderations of the project funds; they create the project, monitor tickets, and issue payments. Beneficiaries are the works: programmers, designers, writers, translators, etc; that collect the money in exchange for their services.
[hr]
Funding Accounts and Control of Funds
How funding account keys work: Peertron holds one key to every funds, to make sure funds never go stale on the server, and can be sent with just the signing of another person on control of the funds to release. Useful for refunds from projects that have seen no work, or paying out on Tickets that have been closed, but a second Commissioner is no where to be found.
There are two funding accounts that be be used in a project, each employing a M-of-N address: Public, and Private. In Public accounts, the Commissioners have full control of any funds, and each get one key to the fund as needed. Patrons are trusting the Commissioners to make the right calls, and manage their money for them. In order for funds to be released from a Public accounts, a Commissioner must create an Invoice from a Ticket that has been closed. The Invoice must then be signed by 2-of-3 keys of Commissioners to be processed immediately, or can be sent after a period of time (72 hours?) using the Peertron key in addition to the Commissioner who created the Invoice (and thus already signed). In Private accounts, the Patron who created the account, as well as Peertron, hold one key for every Commissioner on the project, and Invoices must be signed by M-of-N where M is 1/3 N + 1, meaning the Patron + one Commissioner must sign off on the transaction. If the Patron is also a Commissioner, and issues the Invoice, Peertron will provide the addition key to send the payment without and additional Commissioners. If after and extend period of time (7 days?) the Patron who controls the Private account does not either veto or sign the Invoice, Peerton will provide the additional key to release the funds.
[hr]
The M-of-N Ignorance Problem
M-of-N address are not (as of right now) easy to accomplish without knowledge of the RPC daemon. To fix that, all user keys will be held on Peertron as BIP38 keys, and all signing and private key work will happen on the front end (never held or known to the Peertron server). Making signing a M-of-N transaction as easy as remembering a BIP38 passphrase.
[hr]
Transparency
Peertron will be tightly integrated with GitHub and GitLab using their respective API’s. This will allow Commissioners to create Tickets and Invoices from the Peertron site that appears on their repositories, and return their status upon completion. Meaning when a GitHub or GitLab issue create with tags that represent them as Invoices or Tickets are closed, that is immediately reflected on the Peertron site, and visa-vera. Allowing for better transparency and money tracking.
[hr]
In Closing
This doesn’t solve every problem encounter with opensource funding of projects, however, I do believe it solves a few. Are there other problems I haven’t given thought to? I’d like to know your opinion on it.