There does not appear to be a way for people to be compensated for all of their contributions on the web (and over the network).
Objective: Develop a means for people to donate to projects and all subprojects that are dependent on them. Use a means, for this case termed 'multi-nodal distributed funding' (MNDF) to make this happen.
Requirements: This must work for projects anywhere on the web. People should also be able to keep track of their donations to these projects, and members of the projects themselves must be able to specify a suggested donation.
Terms: money can be any monetary currency or ledger representing value. For ideas see http://polyeconomy.info/systems/#shared-benefit and http://lists.w3.org/Archives/Public/public-community-io/2013Mar/0008.html.
In this MNDF scheme, funding would be distributed amongst nodes. For example, given a specified amount of money, a portion could go to project A, and a percentage could go to all of the projects that project A immediately depends on. That is, projects H, J, B, C, and E. In this case, let us call this first degree MNDF. Figure 1 below illustrates this:
Alternatively, we could also have second degree MNDF. That is, Project A would be funded, and projects H, J, B, C, and E would be funded, but projects K, I, F, D, and L which collectively depend on projects H, J, B, C, and E would also be funded. Again a specified percentage would go to each node. Figure 2 below illustrates this:
Of course we could also have third degree MNDF, or any nth degree MNDF, as illustrated in figure 3:
If money passes from node to node it goes to different servers, and thus changes ownership. These nodes must all be trusted. Additionally, money changing ownership may require a tax to be paid during each change.
Just because the nodes are linked to each other, does not mean that they trust each other. A map as given above should be preserved, but only nodes that trust each other should act as conduits for transferring value.
If taxes are paid after passing through each node, then the nth degree will be limited to some finite value. In order to ensure that all contributors are paid, taxes should be avoided for any nth degree transfer. However, they should be paid at some point. Perhaps taxes should be paid when value reaches its final destination. Further implications will need to be considered.
My present understanding suggests that:
The Ripple payment protocol allows for transferance of value through trusted nodes. This graph may be equivalent to the above graphs, or it may be different.
Payswarm allows for allows for all associated information to be stored and expressed in a fully distributed fashion using linked data. Thus the graphs above could be represented and generated through SPARQL queries. Ripple does keep a ledger of transaction, but it is possible that Payswarm and additional linked data would enhance it to allow for the model above.
Study the architecture of both Payswarm and Ripple more fully to expand on the solutions. Separate the project into a back end and a front end part. Attempt to break these parts down further. This is ambitious and could take a lot of time.
From observation, PaySwarm uses JSON-LD and Ripple uses JSON. Familiarize oneself with these.
On April 4, 2013 Manu Sporny wrote, "Use Case: Persona for Web Payments" on the Mozilla development mailing list.
In the post, he included the following requirements:
"*The customer must be able to log into each site using an in-browser identity mechanism.
*The identity mechanism must be able to provide which decentralized payment processor should be used for
payment along with other payment preference information (such as preferred currency, etc.)"
This seems useful if the objective is to "allow people to donate to projects, and all subprojects dependent on them". Different sites will be using different identity mechanisms and different sites will also have different payment prefrence information.
A few of my present skills:
The Evolving Social Web at Ohm Space (Feburary 7th, 2012)
A Distributed Economy at Ohm Space (April 3rd, 2012)
Experience / History:
-Over two years experience working on the project. Here is a description from an e-mail on February 9th, 2011.
-The project was proceeded by an earlier project mentioned at talk-polywell.org in the thread Quiz Website.
-A partial listing of discovered things may be found at http://adistributedeconomy.blogspot.com.
-A collection of slides that I prepared for private use, and occasional distribution may be found as a pdf here.
-Piles of papers on my computer and printed out.
-I worked on webpages as a hobby in high school, and was the Webmaster for the OU student chapter of AIChE in 2004 and 2005.
-Associated with members of DC405 - The Oklahoma DEFCON Group - starting in November 2011
-I was also involved in the production of three publications in Chemical Engineering. See my Linked-In profile.
This seems a bit more complicated than most of the W3C GSoC 2013 projects. At least they give some idea. I'm not a student. Difficulty: Extreme.
Yes, at least Manu Sporny posted in hacks.mozilla.org. This could a bit more manageable. At least a lot of work was done!
Web Payments with PaySwarm: Identity (part 1 of 3)
If it is not taken by a student, I'd like to start with the novice project for JSON-LD. That is, "Create a simple Web-based tool to generate valid JSON-LD for People, Places, and Events" at
W3C GSoC 2013 (http://www.w3.org/2013/03/gsoc2013).
Thank you Montana Scott Rowe for your astute observations on the limitations of distributed funding (now MNDF), and all of those on the W3C mailing lists.
This page is based on an earlier post at http://adistributedeconomy.blogspot.com/2012/03/distributed-funding.html.
Also see: https://payswarm.com/, http://json-ld.org, and https://ripple.com/.
Status: Work in Progress, April 16, 2013, v0.0, April 17, 2013, v0.01, April 19, 2013, v0.02, Revised April 22, 2013 v0.03 : Comments Welcome, brent.shambaugh at gmail dot com