libreplanet-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libreplanet-discuss] Truly decentralized/federated software develop


From: Logan Streondj
Subject: Re: [libreplanet-discuss] Truly decentralized/federated software development platforms?
Date: Thu, 19 Mar 2015 16:12:03 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, Mar 19, 2015 at 01:23:23PM +0100, rysiek wrote:
> 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).

why do you believe this to be the case?
proof-of-work is completely optional to the block-chain,
thus it shouldn't have any effect on the network.
for instance NXT doesn't use proof-of-work, 
since all coins were pre-mined. 

here the proof-of-work similarly to NXT is optional,
it is not necessary to process blocks like in bitcoin,
it is only necessary for getting new coins.

since it is so hard to get a coin,
they have greater value.

easy come, easy go.
hard to get, sucks to lose,
loss aversion and endowment effect kick in.

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

I like to look at the big picture, once we draw an outline,
can start with some small yet critical aspect.
like you say the blockchain/DHT github and issue tracker.

> > > 
> > > The former one, the "librecoin"/"upvote" scheme, is a *social* process in
> > > which users tell developers which features/bugs are most important.
> > 
> > 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.

haven't yet seen a valid argument against it.

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

I didn't imply they would be, simply that they would be at least one
of the basis for the DAC to add new coins to the issue's wallet.

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

right, I'm in complete agreement there.

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


well some libreware developers would like to be able to feed their
families from their development.

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

I don't know, maybe you just to libreware part time, 
but for those that do it full time, payout is necessary.
It's not freeware, it's libreware.

liberating not only the code, but also the developers.

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

source distributions are reproducible, or recompilable.

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

The blockchain and DAC are seperate. the blockchain is simply the
ledger. It's just like in a traditional corporation, 
you have the treasurer (block-chain), secretary (DHT), 
and president (what I've been calling DAC).

so I'm saying the president can decide to give new coins to an issue. 
the chain-miners would continue to work for the treasurer, 
and be paid in transaction fees.
The content would be organized by the secretary,
created by the various users.
the DHT, issue trackers, and content servers,
could also get some fractional amount 
as they are also putting effort in,
similar to maidsafe. 
though all that would be marginal small fractions of a coins worth,
enough to cover cost of electricity and server maintenance perhaps.

the issue-posters, test-makers, developers, and testers would work on
issues (initially all can be human). indeed initially the president
can also be human(s), or have human(s) to verify if a bug/feature is
"in-scope". necessarily the bulk of the money (whole coins) would be
paid for issues.

I guess the bare-bones would be a proof-of-stake or transaction-mined
block-chain, that can be easily incorporated into an issue tracker,
such as the git based one mentioned earlier in this thread TicGit-ng.
guess could use bananajour for the git hosting if the front page ever
gets fixed.

the Libreware project leaders/president would "premine" all the coin,
and put it on various issues which need to get done,
at first the value would be little more than points,
but if it becomes a big project they could become worth trading.
it would be similar to a company paying with shares/stock.

from Logan ya



reply via email to

[Prev in Thread] Current Thread [Next in Thread]