
Git is already federated and decentralized - fagnerbrack
https://drewdevault.com/2018/07/23/Git-is-already-distributed.html
======
cjbprime
Hi! I'm one of the "replacing GitHub with something decentralized!" people
(via GitTorrent). And one of your Patreon backers! Thanks!

Please don't hand-wave away the UX challenges of getting to a GitHub
replacement. We need a way that someone can access and leave comments on a
project that's better than "well, first I would have joined the project
mailing list months earlier". We need to not depend on people running their
own 24/7 server infrastructure. We need to not require command-line
proficiency. We need to understand that infrastructure has inertia, and
mindshare can be everything.

For example! Gmail rejects outgoing email from most home ISPs, and mangles
patches in ways that cause vger.kernel.org to just reject email from Gmail, as
I understand it. Is that really our example of an accessible federation?

Are we actually trying to compete, or just trying to build ourselves tiny
gardens where we can say to ourselves that we're doing things the right way,
even though no-one else is?

~~~
blablabla123
> Gmail rejects outgoing email from most home ISPs

The configuration must go with the flow, for example it's recommended to at
least configure SPF or DKIM. For each E-Mail a score will be calculated and
both make it better, there's also DMARC for further improvement. In fact not
only Gmail does this, most non-trivial mail setups do inbound filtering.

Nowadays there are even Docker containers for that. Not saying that E-Mail is
great but automation will get one really far and there doesn't seem to be a
decentralized alternative for that yet. (Obviously there are centralized
alternatives; and of course there's XMPP)

~~~
cjbprime
None of these suggestions make sense. DKIM, SPF, and Docker are all irrelevant
to whether Gmail will accept mail that is relayed to them through a broadband
IP address. (They won't.)

~~~
blablabla123
Sorry, I misread that one. I thought you meant self-hosted.

Just out of curiosity, have you tried or have heard of someone who tried? I
mean nothing stops one from pointing a Domain to a Home ISP IP address and
creating DKIM and SPF entries for that. I kind of doubt that Google can
determine with high accuracy whether an IP is from a Consumer ISP or not,
especially when it comes to small ISPs - which might be the most interesting,
when already going so far... ;-)

~~~
zAy0LfpBZLC8mAC
There are dynamic IP DNS blocklists and they are usually pretty accurate.
Also, usually, your reverse name is pretty telling with home ISPs. Sure, you
might be lucky with a small ISP, but then, with a small ISP, chances are they
wouldn't mind giving you "static" addresses anyway.

Though indeed it would be an interesting experiment how domain and IP
reputation actually interact at large email providers.

------
adtac
I'll never completely trust a software product, especially communication ones.
However, I'll blindly put all my money on protocols. A protocol is
indestructible, it's just a document. It doesn't need VC funding to keep
servers alive, it doesn't need advertisements, it doesn't need ridiculous
growth benchmarks, it doesn't need anything. The beauty of protocols is that
you're free to write your own client and server to have end-to-end control.
IRC is a perfect example. I can't count the amount of client and server
software, but they all interact with each almost perfectly.

That's why email will continue to exist forever. And that's why email is so
versatile.

~~~
hyperpallium
Efficient implementation of a protocol _can_ be patent encumbered.

While a protocol exists forever, implementations mightn't, and there are many
failed protocols. But can endure through network effects.

~~~
erikb
It is theoretically possible though, that if you find a usecase for a protocol
that happened to be not used for a hundred years, that you implement it and
then use it. Not even the document about the protocol is necessary if you
remember it well enough.

And a part of the self-responsible philosophy is also that "there is no
implementation" is not even an excuse. As long as there are free programming
languages and affordable computers (I.e. a raspberry pi) then you can very
well create your own implementation. It might take years to even start due to
the requirements to learn programming, but it's not impossible at all.

~~~
hyperpallium
I meant: a communications protocol that no one else uses is as useful as one
telephone.

~~~
erikb
More like a notebook. You could for instance use the email format to store
your diary entries, or a todo list, or an index of useful links, etc. even if
nobody else uses the standard anymore.

------
phoe-krk
Being an active Fediverse user, I've realized that what people realize is that
when they say they want to decentralize Git, they often aren't thinking about
decentralizing Git; they are thinking about decentralizing
GitHub/GitLab/Gitea/etc.. They want to decentralize the social aspect, the
issues trackers, the ability to automatically pull fresh changes from other
parts of the web via webhooks.

~~~
josteink
> when they say they want to decentralize Git, they often aren't thinking
> about decentralizing Git; they are thinking about decentralizing
> GitHub/GitLab/Gitea/etc.

Obviously, because Git was decentralized from day one.

~~~
phoe-krk
Not so obviously, as you can see here. If people keep on saying "let's
decentralize Git", they clearly can't mean what you just said.

------
akerl_
Email is basically the worst-common-denominator for communications and data
transfer. It's going to keep existing forever because it's the one thing that
basically everybody has and everything can support, but from the perspective
of security, usability, and especially structured data transfer it's terrible.

I can't think of a reason I'd want a decentralized system to use email as the
message bus. I do want the message bus to be backed by something standardized,
but there's plenty of standard ways to transmit data that aren't SMTP. If some
users want to interact with the system via email, supporting email as a
notification / response mechanism is totally viable without using that as the
backplane for the service itself.

~~~
stevenicr
I blaming tech overload at the moment, but I'm trying to remember some of the
"supporting email as a notification / response mechanism" that I have seen /
used in the past that took those emails and put them into a threaded responses
kind of graphical hierarchy.

I kind of get this with searches in thunderbird email client, but I can't
quite remember if phpbb or vbulletin does that. I am guessing slack, rocket
chat and similar have some kind of bots or bouncers kind of things that could
re-insert replies and group by threads.

Maybe it's just having a new view layer added into into some of the systems
and giving the option to get notified and reply by email, as well as other
methods that others may prefer.

I think we need to remind people posting in forums and other softwares that
others may be getting plaintext-viewable-by-the-world emails of the posts and
replies - that's a security gap I think many would not consider if they do not
use those methods, so a reminder would be good.

Of course adding an option to get pgp encypted emails only and blocking
plaintext for example might be a step up and in the better direction for
adaptability and moving towards future better.

Still can't pinpoint where I have seen similar things used in the past or what
it was called at the moment.

~~~
zAy0LfpBZLC8mAC
Erm, maybe I am misunderstanding what you are saying, but threading is a
built-in feature of the email RFCs. Mutt can do it perfectly, and has been
doing it forever. If at all, it's a feature that was lost with some "modern"
clients in the name of usability or something idiotic like that.

------
xte
Git is a dVCS so yes, it's already decentralized and in that sense GitHub is a
mere "starting place" for newcomers who want to checkout the official repo.

However many, too many, use proprietary stuff offered by GitHub on top of it's
storage, from PR to wiki etc and those are NOT decentralized and are NOT
"free" in the sense of freedom. A FOSS project that depend on GitHub for
bugreports, patches, discussions etc is voluntary trapped in a proprietary
platform.

We have mailing lists to discuss and post casual patches, Linux kernel work
that way, Python work that way, Emacs work thay way etc and all those are not
small potatoes projects. We have NO NEED of discourse, GitHub etc if we know
how to use good development and user environments, of course we can't develop
anything via mail if we are tied to a webmail or to an ancient '90-style MUA
monster, we need to know other MUA and other UI to work with (my personal
choice notmuch-emacs and EXWM, another populat choice neomutt/*pine and Vim
etc). If even FOSS developer lose this knowledge FOSS is at the end.

------
JamesLeonis
Speaking of existing technologies, Chris Ball combined the BitTorrent, DHT,
and GIT protocols into GitTorrent [1][2].

[1]: [https://blog.printf.net/articles/2015/05/29/announcing-
gitto...](https://blog.printf.net/articles/2015/05/29/announcing-gittorrent-a-
decentralized-github/)

[2]: [https://github.com/cjb/GitTorrent](https://github.com/cjb/GitTorrent)

~~~
rudiv
Serendipitously* enough, he's actually in this thread; top comment. * I don't
know if that's a word.

~~~
erikb
Next time, please mouse over the corresponding comments time stamp, next to
the authors name, and copy&paste the link into your comment. Just because it's
the top comment at the time of your writing doesn't mean it's always the top
comment, right?

I think you mean this one (yes, it's still the top comment):
[https://news.ycombinator.com/item?id=18098416](https://news.ycombinator.com/item?id=18098416)

------
nanomonkey
If anyone is interested in a truly decentralized git repo, check out git-ssb
(git on top of secure scuttlebutt protocol).

[https://git.scuttlebot.io/%25n92DiQh7ietE%2BR%2BX%2FI403LQoy...](https://git.scuttlebot.io/%25n92DiQh7ietE%2BR%2BX%2FI403LQoyf2DtR3WQfCkDKlheQU%3D.sha256)

And of course the scuttlebutt message types work on commit hashes, so leaving
comments, etc. is baked in.

------
0x8BADF00D
> The main issue with using ActivityPub for decentralized git forges boils
> down to email simply being a better choice. The advantages of email are
> numerous. It’s already standardized and has countless open source
> implementations, many in the standard libraries of almost every programming
> language. It’s decentralized and federated, and it’s already integrated with
> git. Has been since day one! I don’t think that we should replace web forges
> with our email clients, not at all. Instead, web forges should embrace email
> to communicate with each other.

This is true. But the problem they’re solving is that email as a protocol is
great, but the UX of most standard mail clients is trash. Especially for
mobile. Consuming the protocol and providing a better UX will incentivize
people to switch.

------
Pxtl
Great. Now let me edit history in a decentralized way (squashing, tweaking
messages, etc) instead of taking away all its glorious power the moment I
push.

Yes, I know that what I said doesn't make sense if you understand how the dag
works. The emergent features matter, and that feature is absent.

~~~
IshKebab
Well, nothing is doing is _changing_ how the git graph works. It's not set in
stone. I think being able to squash historical commits without changing the
has of a future commit would be a good feature.

~~~
Pxtl
I don't even need a real squash, a pseudosquash that conceals intermediate
commits in some kind of aggregate object would be good.

------
huntie
I thought the whole point of ActivityPub+Git was to replicate the social
aspects of GitHub. I think developers don't really have experience working
with email either, so they go with what they know best (web).

~~~
User23
Email is the most mature and widely used social app.

~~~
questionasked
That doesn't mean that it translates to an easy git interface.

~~~
zAy0LfpBZLC8mAC
Email isn't an interface, it's a transport mechanism. This is like saying that
you don't think http translates to an easy git interface.

------
dnautics
Are issues decentralized? I have a pair of GitHub repos, both private, one a
fork of the other, and would like to deprecate the old fork and move issues...
If there is a clean way to do this I'd love to know.

~~~
ChrisRackauckas
Git and Github are not the same. Git is decentralized, Github is centralized
hosting with extra features, including issues and PRs.

~~~
dnautics
gah, for some reason I thought the title said "github" and wondered why it
only talked about git.

------
gerdesj
_I already spoke at length about how a large minority of the git community
uses email for collaboration_

Surely that minority are working on quite a large project. Ahh:

 _Using email for git scales extremely well. The canonical project, of course,
is the Linux kernel. A change is made to the Linux kernel an average of 7
times per hour, constantly. It is maintained by dozens of veritable clans of
software engineers hacking on dozens of modules, and email allows these
changes to efficiently flow code throughout the system. Without email, Linux’s
maintenance model would be impossible. It’s worth noting that git was designed
for maintaining Linux, of course._

As it turns out, that canonical project is both quite large and invented the
bloody thing in the first place (as mentioned in the prior article).

~~~
jasonmp85
I couldn’t tell whether you intended this comment as support or to discount
Linux’s use, but as another data point, PostgreSQL uses git and email in a
similar fashion.

------
badrabbit
Someone once told me, most people mean distributed when they say
decentralized.

Git is decentralized only if commit priviledge is controlled and decided by at
minimum two users where either user cannot revoke or otherwise threaten the
other users priviledge.

------
erikb
Btw git is already running on SSB (Scuttlebut protocol):
[https://git.scuttlebot.io/%25n92DiQh7ietE%2BR%2BX%2FI403LQoy...](https://git.scuttlebot.io/%25n92DiQh7ietE%2BR%2BX%2FI403LQoyf2DtR3WQfCkDKlheQU%3D.sha256)

There it has issue tracking, Readme parsing etc. Looks pretty githubby to me.

------
jancsika
I already live by the dogma that my local machine is the lone input into
master on the remote server of my Gitlab instance. And that remote master
never inputs into my local copy of the repo.

What better UX is awaiting me and my new developers by taking an email-based
approach?

Edit: clarification

~~~
BurritoAlPastor
You have a push-only workflow, and 100% of commits are made on your local?
Frankly, I’m not sure what you’re even using Gitlab for in this setup; it
seems like you might as well just rsync your working directory to your remote
server instead, since you don’t have to approve, merge, or reconcile commits
from other sources. There’s nothing distributed about your version control
needs.

~~~
jancsika
No-- I'll fetch branches from other devs, inspect them, merge them locally,
then push to remote. But that all happens on my local machine.

I use the Gitlab UI for issues, creating merge requests and discussing them
with other devs, etc. That centralized Gitlab instance provides a lot of value
for me. If there were a method of leveraging something close to the Gitlab UX
with a decentralized or even federated design underneath, I'd use that. But
this article reads like it's saying, "Give up that value and use this less
convenient flow in order to protect against an unlikely class of attack."

------
the_clarence
If we are talking cryptocurrency level of decentralization this is false. They
work on a race to be able to sign the next message, commit the next set or
transactions, and to avoid the spam proof of work is a required element.

~~~
dllthomas
"Cryptocurrency level of decentralization" is _more_ centralized than git. It
has to be, because it's about maintaining a global ledger, whereas even within
a single project there's no need for git to sync at any given point.

Proof of work to avoid spam is orthogonal - it could be introduced without any
sort of race (there have long been such proposals around email) but putting
together a patch set that seems anything like plausible seems sufficient
"proof of work" in this context for most projects.

~~~
the_clarence
You have a weird definition of decentralization

~~~
ernesth
In git, everyone has its own repository and its own commit history that can be
totally different from each others. In cryptocurrencies, there is one
authoritative version that is distributed.

Both are distributed, but git is more decentralized as the central law needs
not be pushed to the outer citizens.

~~~
the_clarence
You are comparing apples to oranges. Git can be use alone whereas the utility
of a cryptocurrency is in the network. You don't say that a video game is
"decentralized" because you can play offline do you?

~~~
dllthomas
> You are comparing apples to oranges.

Conversational foul! It was _your comparison in the first place_. You don't
get to accuse someone else of comparing apples and oranges when they describe
where you were wrong.

> Git can be use alone whereas the utility of a cryptocurrency is in the
> network.

To the degree that's true, it's why we can't expect cryptocurrency
implementations to reach git's levels of decentralization. It doesn't somehow
make it extra decentralized.

It's not even quite true that the value is in the network - the value is in my
ability to safely transact. There have been proposals for digital currencies
that allow offline transactions while maintaining resistance to double spends.

> You don't say that a video game is "decentralized" because you can play
> offline do you?

No, but only because we don't really have reason to think about them in those
terms.

------
est
yes, git is. But issues, discussions, wikis are not.

Authentication of who can comment on issue and who can see them, the user
identity service is not decentralized.

That's the main problem with git. And that's why github exists.

I think github could try transform into a namespace and identity service.

~~~
zAy0LfpBZLC8mAC
> the user identity service is not decentralized.

Yes, it is, it's the DNS. The user identity of your git repository is your
host name, which is connected between participants via the DNS.

As for issues and wikis, well, they are not part of git, obviously, but the
same applies in principle. Also, in the case of issues and the like, if you
use mailing lists, your user identity service is decentralized by virtue of
using email addresses.

Whether those are the perfect solution may be questionable, but they most
definitely are not centralized, and might very well be the basis for improving
the usability.

> I think github could try transform into a namespace and identity service.

So they stay the monopolistic gatekeeper? What would be the point of that? If
anything, namespace and identity must not be controlled by one monopolistic
entity.

~~~
est
ok, let's try describe a simple scenario. There's a hundreds of developers in
your git, thousands watching it, now there's an security issue. You want to
include a few trusted ones to discuss a patch, how do you proceed? Especially
how do you move around the disccusion content around with your git repo?

~~~
zAy0LfpBZLC8mAC
Now, there are many ways to implement a solution for this, and I personally
would probably prefer simple patches in plain text emails, unless it's a
really complicated issue with a massive patch.

But in any case, your mistake seems to be in thinking in terms of one repo.
You don't need that. Every developer can have their own repo published
somewhere. Or even more than one. And for the probably simplest solution for
limited access, you just add http authentication in front of that repo and
then send the URI including the credentials via email.

Is that the perfect solution? Maybe not. But the point is that you don't need
a centralized gatekeeper. If you don't like email, you can build new
communication protocols that use DNS names for identity. Or you could
integrate email more with git so git automatically imports machine-readable
pull requests you receive via email. Or whatever. There are endless
possibilities that can use DNS names for federation of independently hosted
repositories and issues trackers and whatnot. And there exist many
implementations of ideas as well. You also could use OpenID for federated
authentication.

~~~
est
I think it comes down to two scopes of the .git:

1\. preserve source code change history 2\. preserve history of how the
project evolves.

Github serves the #2 well but in an centralized way. But #2 is kinda essential
these days. People need to know how the code changed but also WHY.

------
markjspivey
Git is “already federated and decentralized” (depending on emergent
semiotics), but GitHub is NOT.

~~~
markjspivey
I think the ActivityPub related work is moreso related to the GitHub
experience, and less so Git itself ... ?

------
mishurov
It's actually a nifty idea, could be implemented as something like blockchain
in terms of distribution and syncing diffs among peers.

~~~
_jal
Hey, maybe work geolocated "check-ins" into it, and a gig model where you can
pay someone to do your merges!

~~~
MrEldritch
I'm sure you can figure out some way to work deep learning into it. How are
you ever going to disrupt anything with a buzzword density below five nines?

