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: rysiek
Subject: Re: [libreplanet-discuss] Truly decentralized/federated software development platforms?
Date: Thu, 19 Mar 2015 11:31:42 +0100
User-agent: KMail/4.13.3 (Linux/3.13.0-46-generic; KDE/4.13.3; x86_64; ; )

Hi there,

Dnia środa, 18 marca 2015 09:39:06 streondj@gmail.com pisze:
> > [1] http://twister.net.co/
> 
> Interesting you should mention it, yesternight I was thinking about
> the very same thing, about how to best implement a DAC for Open Source
> Projects, and more in general for the internet as a whole. I'll try to
> make this brief.
> 
> BlockChains like in Bitcoin/Twister are distributed databases, since
> everyone has to keep a copy of all transactions, it's not really
> scalable for large projects which have forums/mailing-lists,
> issue-trackers, code, and possibly video tutorials hosted within.
> 
> For large things bittorrent is a great way to go. Magnet links are a
> portable solution for static websites, and with a proper DHT may be
> able to have Freenet like capabilities.
> 
> 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


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


> Thus a user can open an issue, each users' upvote could make the DAC
> put another librecoin onto it, or users could donate librecoin to the
> issue for a quick boost.  Solutions could be posted, and the one
> selected by the majority of voting users would get the librecoin.
> The solution developer could then donate librecoin to other issues, or
> they could sell it at market to users who wish to put it on issues.

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.

For instance on GitHub, *GitHub* is the "trusted third party" that verifies 
that I indeed "own" the account "rysiekpl" there, and my contributions to a 
few projects.

In a federated (a'la StatusNet/GNU Social/Diaspora/Friendica/etc) world, these 
"trusted third parties" are server/pod admins (verifying that indeed I "own" 
the "rysiek" account at "joindiaspora.com" server), in cooperation with DNS 
system admins (verifying that server admins "own" their respective DNS names 
and servers, etc).

In a truly decentralized system there is still a need for *somebody* to verify 
that A "owns" B, but there is nobody that should have the power related to 
that. So, blockchain and proof-of-work have been invented as a solution, so 
that *all participating parties* actually together verify that.


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.


> Depending on DAC scope, issues can range from just for that project,
> or for anything goes craigslist style.
> I guess it would be like a Roman forum, or a bazaar.
> 
> 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!

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

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

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


reply via email to

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