Re: [libreplanet-discuss] Truly decentralized/federated software development platforms?

[Logan Streondj]

On Thu, Mar 19, 2015 at 11:31:42AM +0100, rysiek wrote:
> Hi there,
> 
> Dnia środa, 18 marca 2015 09:39:06 streondj@gmail.com pisze:
> > > [1] http://twister.net.co/
> > 
> > A hybrid of the two may be best.
> 
> Actually, Twister *is* a hybrid of the two:
> https://black-puppydog.withknown.com/2015/a-quick-note-on-twisters-blocks
> https://black-puppydog.github.io/twister-dht.html

that's good to hear :-).

> > Proof-of-work traditionally does difficult computation that is easy to
> > test.  Here instead of doing something frivilous like finding a
> > particular hash, the work can be making a contribution to the
> > project which can be tested.
> 
> I don't think this is viable. "Contribution" is hard to define well enough, 
to quantify it, we can say a contribution is a patch that is accepted
to the mainline. 

> and "test" thoroughly enough. In the end it would always have to be people 
> that assess this. And the power of Bitcoin/blockchain is how automatic it is.
> *However*, we should definitely continue to try finding a better work for the 
> proof-of-work scheme.

the line between what people and computers can do, is regularly
blurred. If for instance feature-requests are written in SPEL or
another language both computers and humans can have fluency in,
then it would quite possible to automatically generate the required
tests, and once the tests are made, then it's a combination of brute
force and heuristic AI's to find code that passes the in-outs and
performance metrics.

autonomous agents might even be able to file bug reports and feature
requests, to help with whatever it is they are using or planning to
use the libreware for. For instance in the stock-market most
day-traders are actually autonomous agent AI's. 

> So, these "librecoins" you're talking about, and the blockchain, are two 
> different beasts, used for two different purposes. Mixing them, I feel, might 
> not help at all.
> 
> 
> The former one, the "librecoin"/"upvote" scheme, is a *social* process in 
> which users tell developers which features/bugs are most important.
> 
> 
> The latter, the blockchain, is a "mechanical", technological solution to the 
> problem of lack of a trusted third party verifying who owns what.
> 

right, but developers want to get paid, and they could get paid on the
blockchain, by the DAC, who bases payment based on upvotes and
donations to issues.

currently payment is based on proof of work for computing blocks,
which "generates" coins, i.e. the bitcoin DAC gives coins for blocks.
in proof-of-stake the DAC gives transaction-fee derived coins based 
on current holdings.

so here the difference is that the DAC can give new coins for solving
issues rather than blocks, though can also do proof-of-stake mining
to keep the blockchain alive, or even simply give raw transaction fees
out to chain miners.  

one little addition I wanted to make is a hoarding-tax, so that if an
account doesn't have enough activity it's money is slowly drained into
the pool, probably to chain miners and the DAC's account. This helps 
against both stale-issues, and lost/unused wallets.

> I think Twister does it right. Blockchain is used for "who owns which 
> account", and DHT is used for Twists, etc. A decentralized issue tracking 
> system could build upon that.

yep, so it would be similar, accounts and payment transactions would
be kept on the blockchain, wheras the content of issues, code, and
related media would be on the DHT.

> > For complicated issues, may need to break up solution into parts,
> > for instance a test-maker can come along to figure out what the
> > input/output is going to look like, and on acceptance get some of
> > the coin. Then someone/thing would write the code, pass the tests,
> > and  get the rest of the coin. This would open the door for automatic
> > code-generators, which could harness the FPGA's, GPU's, and other
> > hardware hardcore bitcoiners like to use.
> 
> I think that's too far out for now. But having a proof-of-work in the form of 
> compiling and *verifying* a verifiable build -- that would sound like a 
> *great* idea!

if it adds value, okay, for instance porting to a new platform.
but otherwise I don't think of compiling for the sake of doing
"something" as a worthwhile endeavour. 

Though perhaps you mean to verify that a patch works as intended,
then I would certainly agree that is worthwhile.  For instance if
there is a patch for ARM7, then a few ARM7's could compile the new
patch in a sandbox and run the required tests to verify the patch
performs as intended, in return for some fractional return from the
issue pot.

> -- 
> Pozdrawiam,
> Michał "rysiek" Woźniak

from Logan Streondj ya