11 ms·

Git is already federated and decentralized

184 points by fagnerbrack 8y ago

mishurov 8y ago
It's actually a nifty idea, could be implemented as something like blockchain in terms of distribution and syncing diffs among peers.
- ISO-morphism 8y ago
  > distribution and syncing diffs among peers That's the stated purpose of git. Git syncs diffs, distributedly. The whole point of the article was that we have technology that works and is very well supported, so we should use and improve those rather than reinvent them for the sake of a new technology.
- _jal 8y ago
  Hey, maybe work geolocated "check-ins" into it, and a gig model where you can pay someone to do your merges!
  - MrEldritch 8y ago
    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?
- harlanji 8y ago
  Git and BlockChain are both based on the Merkle tree data structure. So you could pretty easily prototype a text-based diff/merge-able schema with a single file via git, and then implement the protocol as a smart contract when you figure out the semantics. Multi-file might map to a KeyValue store such as what's implemented with IBM HLF/Composer. I guess something like the protobuf schema evolution rules would be good inspiration as well.
  - erikb 8y ago
    No criticism intended but how is git based on a merkle tree? Commits reference each others hash to build a DAG, but in a merkle tree, if I understand correctly, the non-leaf nodes are actually only having the purpose of simplifying a hash check of the underlying leaf nodes, a tradeoff between processing (checking all the hashes) and storage space (storing the non-leaf nodes additionally to the actual data). Just learned about a few days ago though, might be incorrect.
- erikb 8y ago
  The funny thing is that a huge part of the world hasn't realized yet that a blockchain is in fact a p2p network with the addition of increased trust in the form of proof-of-work. If you could define work on a bug, providing a changeset, reviewing a changeset, running tests on a changeset as proof-of-work, you could actually define a development system based on a blockchain.
adtac 8y ago
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.
- perfmode 8y ago
  a protocol is merely an agreement, no?
  - Reelin 8y ago
    That's the point though. Anyone is free to implement it, anyone can interoperate with it, and anyone can publish improvements to it. Dependence on a protocol instead of a service or piece of software directly facilitates decentralization and user freedom.
- skybrian 8y ago
  I'd hardly say email works perfectly. It's very lossy due to spam prevention. Running your own email server that's trusted by others isn't easy. Whether data is encrypted or not is hit and miss. It's less terrible than some other alternatives, that's all.
  - cirgue 8y ago
    There are organizations and tools to solve those problems, and when they fail there’s always an incentive for something else to take its place while maintaining interoperability. The key point of protocols is that they richly reward diversity.
- hyperpallium 8y ago
  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.
deleted 8y ago
[deleted]
huntie 8y ago
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 8y ago
  Email is the most mature and widely used social app.
  - questionasked 8y ago
    That doesn't mean that it translates to an easy git interface.
    - zAy0LfpBZLC8mAC 8y ago
      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.
- erikb 8y ago
  > I think developers don't really have experience working with email either Honestly if you compare the two, email is much easier to grasp. So I'm not sure what the point is. If you want easier, then go with email. That said, I don't understand why a decentralized system shouldn't speak as many languages as possible. Therefore I see no harm in implementing both.
gerdesj 8y ago
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 8y ago
  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.
akerl_ 8y ago
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 8y ago
  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 8y ago
    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.
0x8BADF00D 8y ago
> 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.
jancsika 8y ago
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 8y ago
  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 8y ago
    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."
- ozim 8y ago
  UX none and for most proprietary projects central repo is what is needed. Hippie utopia where people publish or send changes by email to mailing list their code fixes for software they are using themselves, sharing all code, all free (not necessarily as free beer but free and reviewable). Software improvements where you can not accept some feature sent to mailing list only for your own pleasure or own decision, in contrast to SaaS where changes or "features" for software are pushed down your throat. World where everyone is his own software developer deciding exactly what codes of line his hardware is executing. I don't mean to be derogatory with 'hippie utopia', but that view is really attractive. Though in reality I don't have time to review and merge changes for all software I am using, I would have to have life span of 1000 years probably just to do it, so I understand that is not very practical.
dnautics 8y ago
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.
- harlanji 8y ago
  Check out git-annex for inspiration... I've used it and it works with GitHub, via an extra database of objects. I have hobbyist experience with it... and I've heard of an issue system that works similar, but have not used it so can't speak for it nor recall the name at the moment.
- ChrisRackauckas 8y ago
  Git and Github are not the same. Git is decentralized, Github is centralized hosting with extra features, including issues and PRs.
  - dnautics 8y ago
    gah, for some reason I thought the title said "github" and wondered why it only talked about git.
- chriswarbo 8y ago
  Check out distributed issue trackers like artemis (which I use), bugs-everywhere, git-dit, ditz, git-appraise or many others.
JamesLeonis 8y ago
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-gittorrent-a-decentralized-github/ https://blog.printf.net/articles/2015/05/29/announcing-gitto... [2]: https://github.com/cjb/GitTorrent https://github.com/cjb/GitTorrent
- rudiv 8y ago
  Serendipitously* enough, he's actually in this thread; top comment. * I don't know if that's a word.
  - erikb 8y ago
    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
markjspivey 8y ago
Git is “already federated and decentralized” (depending on emergent semiotics), but GitHub is NOT.
- markjspivey 8y ago
  I think the ActivityPub related work is moreso related to the GitHub experience, and less so Git itself ... ?
the_clarence 8y ago
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 8y ago
  "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 8y ago
    You have a weird definition of decentralization
    - dllthomas 8y ago
      Could you expand?
      - the_clarence 8y ago
        See my other response.
    - ernesth 8y ago
      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.
      - 8y ago
cjbprime 8y ago
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?
- johnny22 8y ago
  I'm really glad to hear you take those concerns seriously. There's nothing that sours me more on "decentralized" versions of X than that.
- blablabla123 8y ago
  > 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 8y ago
    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.)
Pxtl 8y ago
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.
- Reelin 8y ago
  I realize it doesn't entirely solve the problem, but the evolve extension for Mercurial seems to at least be a step in the right direction. https://www.mercurial-scm.org/doc/evolution/ https://www.mercurial-scm.org/doc/evolution/
- IshKebab 8y ago
  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 8y ago
    I don't even need a real squash, a pseudosquash that conceals intermediate commits in some kind of aggregate object would be good.
badrabbit 8y ago
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.
nanomonkey 8y ago
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%2FI403LQoyf2DtR3WQfCkDKlheQU%3D.sha256 https://git.scuttlebot.io/%25n92DiQh7ietE%2BR%2BX%2FI403LQoy... And of course the scuttlebutt message types work on commit hashes, so leaving comments, etc. is baked in.
phoe-krk 8y ago
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 8y ago
  > 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 8y ago
    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.
est 8y ago
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 8y ago
  > 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 8y ago
    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 8y ago
      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.
draw_down 8y ago
Git is; Github isn’t. Two different things. And god help me if anyone says Github is just a pretty web UI for git
xte 8y ago
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.
erikb 8y ago
Btw git is already running on SSB (Scuttlebut protocol): https://git.scuttlebot.io/%25n92DiQh7ietE%2BR%2BX%2FI403LQoyf2DtR3WQfCkDKlheQU%3D.sha256 https://git.scuttlebot.io/%25n92DiQh7ietE%2BR%2BX%2FI403LQoy... There it has issue tracking, Readme parsing etc. Looks pretty githubby to me.

184 points by fagnerbrack 8y ago

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

ISO-morphism 8y ago
> distribution and syncing diffs among peers That's the stated purpose of git. Git syncs diffs, distributedly. The whole point of the article was that we have technology that works and is very well supported, so we should use and improve those rather than reinvent them for the sake of a new technology.
_jal 8y ago
Hey, maybe work geolocated "check-ins" into it, and a gig model where you can pay someone to do your merges!
- MrEldritch 8y ago
  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?
harlanji 8y ago
Git and BlockChain are both based on the Merkle tree data structure. So you could pretty easily prototype a text-based diff/merge-able schema with a single file via git, and then implement the protocol as a smart contract when you figure out the semantics. Multi-file might map to a KeyValue store such as what's implemented with IBM HLF/Composer. I guess something like the protobuf schema evolution rules would be good inspiration as well.
- erikb 8y ago
  No criticism intended but how is git based on a merkle tree? Commits reference each others hash to build a DAG, but in a merkle tree, if I understand correctly, the non-leaf nodes are actually only having the purpose of simplifying a hash check of the underlying leaf nodes, a tradeoff between processing (checking all the hashes) and storage space (storing the non-leaf nodes additionally to the actual data). Just learned about a few days ago though, might be incorrect.
erikb 8y ago
The funny thing is that a huge part of the world hasn't realized yet that a blockchain is in fact a p2p network with the addition of increased trust in the form of proof-of-work. If you could define work on a bug, providing a changeset, reviewing a changeset, running tests on a changeset as proof-of-work, you could actually define a development system based on a blockchain.

adtac 8y ago

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.

perfmode 8y ago
a protocol is merely an agreement, no?
- Reelin 8y ago
  That's the point though. Anyone is free to implement it, anyone can interoperate with it, and anyone can publish improvements to it. Dependence on a protocol instead of a service or piece of software directly facilitates decentralization and user freedom.
skybrian 8y ago
I'd hardly say email works perfectly. It's very lossy due to spam prevention. Running your own email server that's trusted by others isn't easy. Whether data is encrypted or not is hit and miss. It's less terrible than some other alternatives, that's all.
- cirgue 8y ago
  There are organizations and tools to solve those problems, and when they fail there’s always an incentive for something else to take its place while maintaining interoperability. The key point of protocols is that they richly reward diversity.
hyperpallium 8y ago
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.

deleted 8y ago

[deleted]

huntie 8y ago

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 8y ago
Email is the most mature and widely used social app.
- questionasked 8y ago
  That doesn't mean that it translates to an easy git interface.
  - zAy0LfpBZLC8mAC 8y ago
    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.
erikb 8y ago
> I think developers don't really have experience working with email either Honestly if you compare the two, email is much easier to grasp. So I'm not sure what the point is. If you want easier, then go with email. That said, I don't understand why a decentralized system shouldn't speak as many languages as possible. Therefore I see no harm in implementing both.

gerdesj 8y ago

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 8y ago
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.

akerl_ 8y ago

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 8y ago
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 8y ago
  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.

0x8BADF00D 8y ago

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

jancsika 8y ago

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 8y ago
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 8y ago
  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."
ozim 8y ago
UX none and for most proprietary projects central repo is what is needed. Hippie utopia where people publish or send changes by email to mailing list their code fixes for software they are using themselves, sharing all code, all free (not necessarily as free beer but free and reviewable). Software improvements where you can not accept some feature sent to mailing list only for your own pleasure or own decision, in contrast to SaaS where changes or "features" for software are pushed down your throat. World where everyone is his own software developer deciding exactly what codes of line his hardware is executing. I don't mean to be derogatory with 'hippie utopia', but that view is really attractive. Though in reality I don't have time to review and merge changes for all software I am using, I would have to have life span of 1000 years probably just to do it, so I understand that is not very practical.

dnautics 8y ago

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.

harlanji 8y ago
Check out git-annex for inspiration... I've used it and it works with GitHub, via an extra database of objects. I have hobbyist experience with it... and I've heard of an issue system that works similar, but have not used it so can't speak for it nor recall the name at the moment.
ChrisRackauckas 8y ago
Git and Github are not the same. Git is decentralized, Github is centralized hosting with extra features, including issues and PRs.
- dnautics 8y ago
  gah, for some reason I thought the title said "github" and wondered why it only talked about git.
chriswarbo 8y ago
Check out distributed issue trackers like artemis (which I use), bugs-everywhere, git-dit, ditz, git-appraise or many others.

JamesLeonis 8y ago

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-gittorrent-a-decentralized-github/ https://blog.printf.net/articles/2015/05/29/announcing-gitto... [2]: https://github.com/cjb/GitTorrent https://github.com/cjb/GitTorrent

rudiv 8y ago
Serendipitously* enough, he's actually in this thread; top comment. * I don't know if that's a word.
- erikb 8y ago
  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

markjspivey 8y ago

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

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

the_clarence 8y ago

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 8y ago
"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 8y ago
  You have a weird definition of decentralization
  - dllthomas 8y ago
    Could you expand?
    - the_clarence 8y ago
      See my other response.
  - ernesth 8y ago
    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.
    - 8y ago

cjbprime 8y ago

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?

johnny22 8y ago
I'm really glad to hear you take those concerns seriously. There's nothing that sours me more on "decentralized" versions of X than that.
blablabla123 8y ago
> 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 8y ago
  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.)

Pxtl 8y ago

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.

Reelin 8y ago
I realize it doesn't entirely solve the problem, but the evolve extension for Mercurial seems to at least be a step in the right direction. https://www.mercurial-scm.org/doc/evolution/ https://www.mercurial-scm.org/doc/evolution/
IshKebab 8y ago
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 8y ago
  I don't even need a real squash, a pseudosquash that conceals intermediate commits in some kind of aggregate object would be good.

badrabbit 8y ago

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.

nanomonkey 8y ago

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%2FI403LQoyf2DtR3WQfCkDKlheQU%3D.sha256 https://git.scuttlebot.io/%25n92DiQh7ietE%2BR%2BX%2FI403LQoy... And of course the scuttlebutt message types work on commit hashes, so leaving comments, etc. is baked in.

phoe-krk 8y ago

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 8y ago
> 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 8y ago
  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.

est 8y ago

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 8y ago
> 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 8y ago
  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 8y ago
    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.

draw_down 8y ago

Git is; Github isn’t. Two different things. And god help me if anyone says Github is just a pretty web UI for git

xte 8y ago

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.

erikb 8y ago

Btw git is already running on SSB (Scuttlebut protocol): https://git.scuttlebot.io/%25n92DiQh7ietE%2BR%2BX%2FI403LQoyf2DtR3WQfCkDKlheQU%3D.sha256 https://git.scuttlebot.io/%25n92DiQh7ietE%2BR%2BX%2FI403LQoy... There it has issue tracking, Readme parsing etc. Looks pretty githubby to me.