Follow

You wouldn't believe how many people replied to this thread with "something something ".

No, honey. Just no. An extremely inefficient append-only database will not solve any of this.
---
The main problem with Github being bought by Microsoft isn't MS.

It's that in 2018 we still haven't learned that critical infrastructure shouldn't belong to one company ... and that we should avoid building single points of failure.
twitter.com/tante/status/10036

@tante You say the problem is centralisation and you outright dismiss a decentralised system? What should a big repository of software look like then?

@turion @tante A blockchain lets multiple parties that can not trust each other agree on a common truth (in case of currencies a sequence of transactions), if none of the parties involved has extensively more computing power then the other.
I don't see why that would be needed for source code as every git repo is a basically little Merkle tree and you can sign commits using your pgp key.
Also if you store large sets of data inside a blockchain somebody still needs to provide the storage space.

@sebastian @tante
* I can see an application for decentralised consent in code: Whenever security is relevant. We all need to agree which crypto libraries are implemented correctly.
* Proof of work is not necessary for blockchains, there are other models.
* If designed well, not everyone needs to provide all of the storage space, but it could be distributed amongst all peers. Of course, that could mean that unpopular repos are less available.

@turion @sebastian @tante
1) Is valid use case for a blockchain, but it is more about assuring properties of a piece of code rather then hosting it. The details might become tricky though.
2) I know about proof of space or proof of stake approaches used in the wild, both do not make too much sense with 1). What are you suggesting?
3) True, but there a simpler approaches to a decentralized storage solution. For example git itself can already be used in a decentralized manner.

@turion @tante
Little addon to 1) the tricky details I was talking about:
Assuming you had enough eyeballs that you can be reasonably sure code for $lib is ''secure' (for a good definition of secure)
You'd still need way to make sure that the build of $lib you are running has not been tempered with. And if you compile it yourself you'd need to be sure that the toolchain has not...
So in the you'd have to solve most of the problems in trusted computing before the blockchain becomes really useful

@turion @tante
But let's not go there. To answer your initial question about how a decentralised code hosting platform could work:
I'd imagine something like the fediverse might be good first step.
I'd suggest a gogs/gitlab like software running on multiple instances with some sort of single sign on. Each user can comment/open issues/create merge requests for any repo on any instance. Repos can only be created on the home instance. Each user can chose N repos to mirror to his home instance.

@turion @tante And N could vary according the to resources available for each instance. And if multiple user chose to mirror the same thing to the same instance it should only happen once.
And by mirroring a repo I'm thinking about more then just the code itself, so also the issues, the wiki pages and stuff like that.
Basically a federated github.

@sebastian @tante Actually all the additional data like wiki pages and issues could (should?) be part of a #git repo. Is there a git extension that does that? Can we write one easily? Because then we just need a nice web frontend that can talk to a bare git server.

@turion @sebastian @tante A friend of mine has been working on exactly that. Maybe I should ask her how it worked out.

@turion @tante Digging through old irc logs yielded stuff like: pythonhosted.org/pyditz/ and github.com/sit-fyi/sit ... both store stuff in files an aim to be VCS agnostic and use some form of flat file database. That's a bit a problem for as user might need to merge things manually in some edge cases.
github.com/neithernut/git-dit might be a nicer solution as it stores issues directly in the git object tree, which should be trivially merge able in all cases.

@sebastian @tante 1) Yes, true. 2) E.g. proof of stake (stake could be measured by code that is used by others, for example) with landmark proof of work blocks (every 1000th block or so). 3) Right, agree. I guess the more important feature about #github there really is the social component and the interface. So how we host all code elsewhere and have a decentralised social network where we present our repos and manage issues, PRs, wikis etc.?

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!