Just came across this, which might be relevant to this discussion: https://github.com/jessica-taylor/hashlattice.
On Sun, Mar 22, 2015 at 10:47 AM, rysiek <[email protected]> wrote: > Dnia czwartek, 19 marca 2015 15:32:09 אנטולי קרסנר pisze: > > rysiek <[email protected]> wrote: > > > the Gitlab/Gitorius situation rekindled my interest in what I would > call > > > the "next step" in software development management -- a truly > > > decentralised/federated platform. > > > > > > First step could be to have different instances being able to "talk to > > > each other" (...) > > > Next step would be to have a truly decentralized solution, a bit like > what > > > Twister[1] does for microblogging. > > > (...) > > > > It doesn't have to be fully distributed. Actually it makes sense not to > make > > it distributed, because the last thing we want is a huge ever growing > > "blockchain". What you can safely have is redundancy: distribute copies > of > > the repo content on many servers, and allow the front server to choose > > between them, so it's harder to block/censor/DoS the system. > > Now, that's something Twister handled quite well -- the blockchain is only > used for very specific information ("who owns what"); the data itself > resides > in DHT, which scales much better. So "large blockchain problem" isn't > really > an issue. > > On the other hand, when you have "servers", you have "admins": people who > have > power over the given network. While I myself am an admin of many services, > I > can see that this is a liability: admins can be coerced, admins can be > required by law to do or refrain from doing certain things. And most > importantly, server-based infrastructure can lead to secondary > centralisation > (e-mail -> GMail et al). > > We need to put the very same full-blown peer-to-peer decentralisation that > is > (more or less) present on all the lower OSI model layers into the > application > layer. The fact we haven't yet is precisely why we have a growing walled > gardens problem. > > There are no admins on Twister or BitTorrent, hence there is no way to > "take > down content", and no easy way to centralise these solutions (and then > exert > control over users). I believe we need something exactly like that for code > and issue tracking. > > > I think having a DHT for worldwide project and user search is a good > idea, > > and use local development platform serves which can federate. For > example, > > in a team of developers works on a project, one of them can host the git > > server at home, or some other truly trusted location, and not in the > > "cloud" managed by greedy selfish corporations. > > We *really* need to move beyond the "server" narrative. As I said, > federated > servers is a stepping stone, sure, but we need to go in the direction of > full > decentralisation/peer-to-peer solutions. > > Otherwise we *will* land in the "cloud" of greedy selfish corporations yet > again, just in a bit different manner. > > It's also about how easy it is. People choose GitHub over their own repos > due > to how easy it is to use it, and then share the code, issues, pull > requests, > et al, with other GitHub users (and the assumption is: "everybody has > Faceb^WGitHub"). > > I look at Twister and I see a solution that requires no setting-up, no > configuration and no upkeep. I just fire up my Twister daemon (or, soon, > GUI > client) and I'm already on the network, being able to talk, PM, retransmit, > comment, etc., with all other Twister users. > > Imagine something like that with regard to code and issue tracking, and > you'll > start seeing what I'm getting at. > > > So global things like project and user search can use a DHT, and > operations > > across instances (forking a repo from another server, sending merge > request > > to a repo in another server, etc.) can work using a federation API, e.g. > > based on Activity Streams like Jessica Tallon's plan mentioned already in > > this thread. > > As I said, that can be the first step. But servers are a liability, and > introduce weak points. We can (and should, IMVHO) attempt to move beyond > client-server architecture. > > > There is also another, more long-term reason: peer-to-peer, fully > decentralised services are something that -- once introduced -- no closed- > source, corporate power can easily hijack. *Only* the free software (which > does not mean "free of charge", mind you!) crowd can and will be > interested in > their development. This could be the next "killer feature" of the free > software movement -- no closed/walled corporate service will be ever able > to > replicate that, as there is no closed-source business model to build on it, > plain and simple. > > On the other hand, freedom-preserving business models are actually > *easier* to > build on a peer-to-peer infrastructure, as that means all users contribute > resources (disk space, network bandwidth, etc) so that a libre business > doesn't have to pay for these. Makes it much easier to focus on providing > services (implementation, support, feature requests/bounties, etc). > > But that's a broader thing I am thinking about. > > -- > Pozdrawiam, > Michał "rysiek" Woźniak > > Zmieniam klucz GPG :: http://rys.io/pl/147 > GPG Key Transition :: http://rys.io/en/147 >
