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

[rysiek]

Hi there,

Dnia czwartek, 19 marca 2015 07:54:22 Logan Streondj pisze:
> > 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.

But that's exactly my point. Proof-of-work in the blockchain *has to be* 
completely automatic and easily *automagically* verifiable. Also, it has to be 
achievable in a predictable amount of time (from the whole network 
perspective, not necessarily from the perspective of a particular 
peer/agent/developer).

"Accepted to the mainline" does not satisfy any of these.

> > 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.
> (...)

I think writing a blockchain- and DHT-based GitHub replacement is already a 
bunch of innovation, maybe we should not get ahead of ourselves...

> > 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.

This is not feasible to do in the blockchain itself for the reasons I outlined 
before.

Also, there is no good reason to actually do that on the blockchain -- 
upvotes, etc, can be a separate system, not tied directly to the (crucial) 
functionality of the blockchain/ledger.

The blockchain has a single crucial function: keeping the ledger of who owns 
what. This *has to* be done automagically, and should not be tied to any 
additional functionalities, as that would possibly jeopardize this crucial 
task.

> 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.

While I agree there has to be an incentive to actually do the work for the 
proof-of-work, it doesn't have to be a payout. Twister gives the user that 
"mines" another block the right to post a non-blockable message to all Twister 
users (following them or not). And (at least for now) that is enough.

> > 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.

Yep. I would just take the "payment" out of it, as it has been taken out of 
Twister too. I don't think we need that particular social dynamic in there...

> > > 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.

Compiling and verifying reproducible builds has immense value:
https://wiki.debian.org/ReproducibleBuilds
https://www.youtube.com/watch?v=5pAen7beYNc
https://www.youtube.com/watch?v=ca0DWaV9uNc

It's also crucial to the free software movement, as probably the single most 
effective measure against "trusting trust" problems:
https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf
https://www.schneier.com/blog/archives/2006/01/countering_trus.html

> Though perhaps you mean to verify that a patch works as intended,
> then I would certainly agree that is worthwhile.

Problem with this is that first the tests would have to be written, and these 
have to be written by a programmer, and again we land in something that cannot 
be (easily) automagically verified.

Unless we include a caveat of "running tests if they are written", but then 
the blockchain can be blocked by lack of tests...

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

Zmieniam klucz GPG :: http://rys.io/pl/147
GPG Key Transition :: http://rys.io/en/147

signature.asc
Description: This is a digitally signed message part.