Gitlab's ActivityPub architecture blueprint(docs.gitlab.com)
docs.gitlab.com
Gitlab's ActivityPub architecture blueprint
https://docs.gitlab.com/ee/architecture/blueprints/activity_pub/
106 コメント
I would love this. I created a Codeberg account to contribute to an OSS Android app I liked. Then, (thankfully, after my contribution was merged) I had a situation where I lost access to my 2fa codes. I could provide other identity verification, but where? Their official docs tell you there's a support at Codeberg email address....but that nobody looks at that inbox. They link a Discord room (kinda defeats the appeal of an EU-hosted indie forge, but okay). I went in there, and was told (eventually, when the apparently sole employee in the room) that I was out of luck. Not because they couldn't verify my identity or anything, but because support for account-related issues is something they categorically do not offer.
I'd love to regain the ability to contribute to stuff that is trapped in the Codeberg ice without having to create another account on a service with that sort of ramshackle operating approach.
I'd love to regain the ability to contribute to stuff that is trapped in the Codeberg ice without having to create another account on a service with that sort of ramshackle operating approach.
It would be awesome to see Git becoming decentralized again but what's the likelihood of GitHub implementing this?
It's approximately 0. Microsoft knew that GitHub had no moat being what it was when they acquired it.
T hat's why they've been adding CI, Pages, Codespaces, Copilot, and a bunch of other crap that only some of which people actually asked for in order to raise switching costs. That would go against everything they've been doing the last couple years.
> Microsoft knew that GitHub had no moat
GitHub had the best moat: network.
But yes, the additions have only deepened it.
GitHub had the best moat: network.
But yes, the additions have only deepened it.
Pages predates Microsoft's acquisition, and I can use Copilot on the repos I commit to any other source control system.
Everyone knows the answer to that ;)
None, that’s why github is awful
Only when there is so much critical mass behind all of it's competitors that they can't ignore it any longer. Improbably, for the time being.
I was going to say that Microsoft has no social network, so that this might open them up etc, but then again, there's LinkedIn.
I was going to say that Microsoft has no social network, so that this might open them up etc, but then again, there's LinkedIn.
Not the best way to look at it. A lot of developers today work primarily on github because it's not possible to interact/work in other projects from their siloed forges. When gitlab implements AP, things are no longer siloed and therefore there will be a percentage of (current) Github users who will free to choose their forge independently of network effects.
It's better to ask "how many projects are stuck to Github exclusively because of collaboration tools, and how many of these would be able to leave Github once more Gitlab/Gitea/Forgejo are able to interoperate? How much of its customer base can Github afford to lose before being forced to give up their monopolistic strategy?"
It's better to ask "how many projects are stuck to Github exclusively because of collaboration tools, and how many of these would be able to leave Github once more Gitlab/Gitea/Forgejo are able to interoperate? How much of its customer base can Github afford to lose before being forced to give up their monopolistic strategy?"
Is the European Union’s Digital Markets Act relevant here?
IIRC Meta now has to implement interoperability with other chat apps like Signal, I wonder if GitHub will have to do the same through AP soon
IIRC Meta now has to implement interoperability with other chat apps like Signal, I wonder if GitHub will have to do the same through AP soon
I'm pretty sure that's only if you're a gatekeeper, which are only the services big enough that my mom would notice directly if they'd go down (things used by millions of people in my country of 18 million). Whether Apple's messaging system, default enabled on every Apple phone, qualifies is currently being debated, to give a sense of what scale this requires.
The DMA/DSA laws also contain rules for smaller parties (I've been getting tons of ToS update emails mentioning the digital somethings act), but not interoperability
The DMA/DSA laws also contain rules for smaller parties (I've been getting tons of ToS update emails mentioning the digital somethings act), but not interoperability
Fwiw, GitHub has been on the news occasionally in at least the US.
- "Graph of Keybase commits pre and post Zoom acquisition" (2021) https://news.ycombinator.com/item?id=28814802 :
- "Key server (cryptographic)" https://en.wikipedia.org/wiki/Key_server_(cryptographic)
- W3C DID Decentralized Identifiers (that you can optionally locally generate like pubkey hash account identifiers)
- "Linked Data Signatures for GPG" https://gpg.jsld.org/ ; GPG in (JSON-LD) RDF
- ld-signatures is now W3C vc-data-integrity: "Verifiable Credential Data Integrity 1.0 Securing the Integrity of Verifiable Credential Data" https://www.w3.org/TR/vc-data-integrity/
- An example of GPG signatures on linked data documents: https://gpg.jsld.org/contexts/#GpgSignature2020
- vc-data-integrity specifies how to normalize the document by sorting keys ~ in the JSON before cryptographically signing the transformed, isomorphic graph
- SLSA.dev also specifies signed provenance metadata (optionally with sigstore.dev for centralized release artifact hashes), but not (yet?) with Linked Data
- Blockcerts: blockchain-certificates/cert-verifier-js , https://www.blockcerts.org/guide/ :
> Blockcerts is an open standard for building apps that issue and verify blockchain-based official records. These may include certificates for civic records, academic credentials, professional licenses, workforce development, and more.
> Blockcerts consists of open-source libraries, tools, and mobile apps enabling a decentralized, standards-based, recipient-centric ecosystem, enabling trustless verification through blockchain technologies.
> Blockcerts uses and encourages consolidation on open standards. Blockcerts is committed to self-sovereign identity of all participants, and enabling recipient control of their claims through easy-to-use tools such as the certificate wallet (mobile app). Blockcerts is also committed to availability of credentials, without single points of failure.
- [ ] SCH: link a git commit graph (with GPG signatures) with other linked data of an open source software project; for example (SLSA,) build logs and JSON-LD SBOMs.
- >> Is there an ACME-like thing to verify online identity control like Keybase still does?
- "Key server (cryptographic)" https://en.wikipedia.org/wiki/Key_server_(cryptographic)
- W3C DID Decentralized Identifiers (that you can optionally locally generate like pubkey hash account identifiers)
- "Linked Data Signatures for GPG" https://gpg.jsld.org/ ; GPG in (JSON-LD) RDF
- ld-signatures is now W3C vc-data-integrity: "Verifiable Credential Data Integrity 1.0 Securing the Integrity of Verifiable Credential Data" https://www.w3.org/TR/vc-data-integrity/
- An example of GPG signatures on linked data documents: https://gpg.jsld.org/contexts/#GpgSignature2020
- vc-data-integrity specifies how to normalize the document by sorting keys ~ in the JSON before cryptographically signing the transformed, isomorphic graph
- SLSA.dev also specifies signed provenance metadata (optionally with sigstore.dev for centralized release artifact hashes), but not (yet?) with Linked Data
- Blockcerts: blockchain-certificates/cert-verifier-js , https://www.blockcerts.org/guide/ :
> Blockcerts is an open standard for building apps that issue and verify blockchain-based official records. These may include certificates for civic records, academic credentials, professional licenses, workforce development, and more.
> Blockcerts consists of open-source libraries, tools, and mobile apps enabling a decentralized, standards-based, recipient-centric ecosystem, enabling trustless verification through blockchain technologies.
> Blockcerts uses and encourages consolidation on open standards. Blockcerts is committed to self-sovereign identity of all participants, and enabling recipient control of their claims through easy-to-use tools such as the certificate wallet (mobile app). Blockcerts is also committed to availability of credentials, without single points of failure.
- [ ] SCH: link a git commit graph (with GPG signatures) with other linked data of an open source software project; for example (SLSA,) build logs and JSON-LD SBOMs.
- >> Is there an ACME-like thing to verify online identity control like Keybase still does?
This is exciting and could be disruptive to closed software hosting platforms.
ActivityPub's open standard is an added bonus. A fediverse for code? Sing me in.
ActivityPub's open standard is an added bonus. A fediverse for code? Sing me in.
Yes, my first thought is - doesn't this allow other sites to interoperate with Gitlab without asking Gitlab? Like Gitea can implement this and now we can do PRs back and forth? That's fantastic, exactly what the internet is for and the sort of thing we need more of.
edit - learned about https://forgefed.org/ from a sibling thread, great stuff.
edit - learned about https://forgefed.org/ from a sibling thread, great stuff.
What's really strange is ForgeFed, Forgejo, Gitea, etc. have all been working on this for a while with a goal to be interoperable, and GitLab doesn't mention any of that at all. Are they planning to enter this late and build a completely incompatible solution?
Don't suppose you have links to the work they have been doing towards this?
Of course: https://forgefed.org/
:facepalm: I thought they were all names of alternative source control projects, didn't realise the first one was the name of the collaboration effort.
Thank you :-)
Thank you :-)
It sounds like they have heard of it and plan to support it once they get to that point of their implementation.
There is some discussion in there epic tracking the feature - https://gitlab.com/groups/gitlab-org/-/epics/11247
There is some discussion in there epic tracking the feature - https://gitlab.com/groups/gitlab-org/-/epics/11247
Contemplating this through the lens of simply using email and git (ala Linux) to share, review and consume patches, among other things, I can't help but conclude that ultimately this is all totally fucking ridiculous.
Sure, it's cool I can send a merge request to another server whatever, but... why are we like this
Sure, it's cool I can send a merge request to another server whatever, but... why are we like this
For me as a person who learned programming in the times of Github/lab/whatever, the idea of sending patches via email is fucking ridiculous.
The typical interface for handling merge/pull requests adds so many useful things over just sending a patch - if the project has CI I can immediately see if it even successfully builds before even going into the details of the PR.
Same for reviewing, each comment can be replied to separately or resolved, which serves as a nice TODO list for the original author.
I know there are some things people don't like (I think Linus was pretty vocal about it), but it seems to be they could be easily fixed by modifying the available open-source forges. This proposal here for example fixes the concern about centralisation, so I guess it's a good step forward.
Or maybe I'm just young and like shiny things and will eventually have a spiritual awakening and learn about the virtues of sending in patches via email.
The typical interface for handling merge/pull requests adds so many useful things over just sending a patch - if the project has CI I can immediately see if it even successfully builds before even going into the details of the PR.
Same for reviewing, each comment can be replied to separately or resolved, which serves as a nice TODO list for the original author.
I know there are some things people don't like (I think Linus was pretty vocal about it), but it seems to be they could be easily fixed by modifying the available open-source forges. This proposal here for example fixes the concern about centralisation, so I guess it's a good step forward.
Or maybe I'm just young and like shiny things and will eventually have a spiritual awakening and learn about the virtues of sending in patches via email.
> For me as a person who learned programming in the times of Github/lab/whatever, the idea of sending patches via email is fucking ridiculous.
For me as a person who learned programming before the Internet was a thing, and has worked both on projects that do patches by email and on projects that use web-based pull requests, I also prefer the web-based pull requests in every possible way. The email based workflow is baroque, painful both to send and to receive, lacking in features, and error-prone.
For me as a person who learned programming before the Internet was a thing, and has worked both on projects that do patches by email and on projects that use web-based pull requests, I also prefer the web-based pull requests in every possible way. The email based workflow is baroque, painful both to send and to receive, lacking in features, and error-prone.
I would prefer `git request-pull etc` to actually make a pull request that anyone could see inside their editor, on GitHub, in their mailbox or wherever else they want.
Hopefully federated forges will make that easier, since it'll be easy for anyone to interface with using whatever technology they prefer.
I think we can all agree that the main reason why developers require distributed source control is in order to facilitate development in a parallel way.
So, as a maintainer the purpose of such a request for collaboration (it being a PR or a patch) is to determine if: a) it does what it's expected out of it, b) it matches the conventions of the existing code.
I, personally, can make a judgement about both of things better with a patch that I apply locally than with a PR.
The main issue with PRs (in my opinion) is that they limit severely the context in which the changes are viewed. If I want to properly review a piece of code I have to check it out and follow the diff in its proper context (either while debugging) or even while just reading it.
Source forges, through the PR mechanism, encourage superficial reviews and insufficient attention being given to the merged code.
So, as a maintainer the purpose of such a request for collaboration (it being a PR or a patch) is to determine if: a) it does what it's expected out of it, b) it matches the conventions of the existing code.
I, personally, can make a judgement about both of things better with a patch that I apply locally than with a PR.
The main issue with PRs (in my opinion) is that they limit severely the context in which the changes are viewed. If I want to properly review a piece of code I have to check it out and follow the diff in its proper context (either while debugging) or even while just reading it.
Source forges, through the PR mechanism, encourage superficial reviews and insufficient attention being given to the merged code.
> I, personally, can make a judgement about both of things better with a patch that I apply locally than with a PR.
How come? How is a text .patch file easier in this regard than a UI for essentially that same .patch? Can't you check out the PR in the same way you would 'apply' a patch to review it?
For what it's worth, you can just add .patch onto the end of a github PR URL to get that.
How come? How is a text .patch file easier in this regard than a UI for essentially that same .patch? Can't you check out the PR in the same way you would 'apply' a patch to review it?
For what it's worth, you can just add .patch onto the end of a github PR URL to get that.
I don't look at the patch by itself, I hoped that was clear. I apply the patch locally, where I have the full context.
I can of course do the same with the PR, but then it loses its convenience. :)
I can of course do the same with the PR, but then it loses its convenience. :)
> I can of course do the same with the PR, but then it loses its convenience. :)
Not at all. A PR still retains all the other useful features like separate threads for comments which be individually marked as done and CI checks. And not all PRs need a local checkout for a review.
Not at all. A PR still retains all the other useful features like separate threads for comments which be individually marked as done and CI checks. And not all PRs need a local checkout for a review.
> I, personally, can make a judgement about both of things better with a patch that I apply locally than with a PR.
`gh pr checkout NNN` works very well to give a local copy for review, by pulling and checking out the PR branch. There are equivalent commands for gitlab.
Also:
> The main issue with PRs (in my opinion) is that they limit severely the context in which the changes are viewed. If I want to properly review a piece of code I have to check it out and follow the diff in its proper context (either while debugging) or even while just reading it.
Both PRs and emailed patches encourage reading and reviewing just the patch. With emailed patches, you need to prepare a local branch with the patches applied if you want to do the kind of review you describe; with a PR, you need to fetch and checkout the PR branch. I would argue that checking out the latter is substantially easier than the former, especially given the availability of command-line tools like `gh pr checkout`.
`gh pr checkout NNN` works very well to give a local copy for review, by pulling and checking out the PR branch. There are equivalent commands for gitlab.
Also:
> The main issue with PRs (in my opinion) is that they limit severely the context in which the changes are viewed. If I want to properly review a piece of code I have to check it out and follow the diff in its proper context (either while debugging) or even while just reading it.
Both PRs and emailed patches encourage reading and reviewing just the patch. With emailed patches, you need to prepare a local branch with the patches applied if you want to do the kind of review you describe; with a PR, you need to fetch and checkout the PR branch. I would argue that checking out the latter is substantially easier than the former, especially given the availability of command-line tools like `gh pr checkout`.
Others keep in mind that Josh is so experienced with the email workflow that he made a tool to manage multiple versions of a “patch series”: git-series
(git(1) doesn’t help you with maintaining patch series)
(git(1) doesn’t help you with maintaining patch series)
Thank you, you just made my day. (I feel bad about leaving that undermaintained, though.)
> I, personally, can make a judgement about both of things better with a patch that I apply locally than with a PR.
FWIW, my git is configured in such a way that pulling from github also pulls all PRs for that repo, so, in effect, all PRs are applied locally, and I can review them however I want.
I do think that email threads (when all parties are disciplined and have them properly configured) are superior to the PR+comments format for discussion, but applying patches from a mailbox has never seemed to me like a pretty and reliable way to go, so at least github helps with that.
At any rate, git sucks for reviews in general because it still lacks mercurial's "mutable-history"/evolve approach to safe and distributed history rewriting (or "diffs of diffs"), and that, to me, is saddening as one more evidence that git's monopoly is causing stagnation and unnecessary pain in this space.
FWIW, my git is configured in such a way that pulling from github also pulls all PRs for that repo, so, in effect, all PRs are applied locally, and I can review them however I want.
I do think that email threads (when all parties are disciplined and have them properly configured) are superior to the PR+comments format for discussion, but applying patches from a mailbox has never seemed to me like a pretty and reliable way to go, so at least github helps with that.
At any rate, git sucks for reviews in general because it still lacks mercurial's "mutable-history"/evolve approach to safe and distributed history rewriting (or "diffs of diffs"), and that, to me, is saddening as one more evidence that git's monopoly is causing stagnation and unnecessary pain in this space.
You can still get a “diff of diffs” with git range-diff. (If I interpret you correctly.) Like it says that in this iteration a paragraph was added to one commit, another commit was dropped, and another commit was expanded.
But you gotta do most of the work of lining up what the previous thing was yourself. (Inconvenient if you rebased and can’t seem to find the previous version.)
But you gotta do most of the work of lining up what the previous thing was yourself. (Inconvenient if you rebased and can’t seem to find the previous version.)
Mercurial's evolve is more about tracking history rewrites and their context. If I submit a series of commits, and over the review you have me amend one mid-series, then rebase few identically on top of that, then add some new changes, and split some existing ones, mercurial will still know how every single commit in the resulting series relates to things from the original PR. As such, answering questions like "show me how commit 3 was updated several times over multiple series submissions" is trivial.
As I replied to a sibling comment. I agree that I can review PRs on my local machine, which is sometimes what I do, but that means that the upside of viewing them directly on the source forge is lost, and I might as well have received a patch. :)
> is saddening as one more evidence that git's monopoly is causing stagnation and unnecessary pain in this space.
I disagree strongly with this type of sentiment. Mercurial works, mercurial source forges exist. It's entirely possible to use them for development. Complaining about git's success despite that feels a bit disingenuous.
> is saddening as one more evidence that git's monopoly is causing stagnation and unnecessary pain in this space.
I disagree strongly with this type of sentiment. Mercurial works, mercurial source forges exist. It's entirely possible to use them for development. Complaining about git's success despite that feels a bit disingenuous.
>> The main issue with PRs (in my opinion) is that they limit severely the context in which the changes are viewed. If I want to properly review a piece of code I have to check it out and follow the diff in its proper context (either while debugging) or even while just reading it.
> but that means that the upside of viewing them directly on the source forge is lost, and I might as well have received a patch. :)
I don't follow, github gives it to you both ways, so I don't see the downside here. And on top of that, you can pull comments into your IDE of choice would you need to. I hardly see the problem, I suspect it isn't technical.
> I disagree strongly with this type of sentiment. Mercurial works, mercurial source forges exist.
Your disagreement doesn't align with the reality, unfortunately. Could you name one mercurial forge? They aren't many left anymore, and you have to get out of your way to host your mercurial code somewhere. And while it's hard to name mercurial forge, it's easy to name high profile projects which reluctantly converted to git: python, mozilla, pypy. It only got worse over time, "interestingly", about as fast as git consolidated its monopoly. And that's the main flaw in your point, that success somehow is based on merit alone, with no influence of peer/social pressure/network effect.
FYI, I just submitted this post: https://news.ycombinator.com/item?id=39208464 which is pretty much what remains of hosted mercurial today.
> but that means that the upside of viewing them directly on the source forge is lost, and I might as well have received a patch. :)
I don't follow, github gives it to you both ways, so I don't see the downside here. And on top of that, you can pull comments into your IDE of choice would you need to. I hardly see the problem, I suspect it isn't technical.
> I disagree strongly with this type of sentiment. Mercurial works, mercurial source forges exist.
Your disagreement doesn't align with the reality, unfortunately. Could you name one mercurial forge? They aren't many left anymore, and you have to get out of your way to host your mercurial code somewhere. And while it's hard to name mercurial forge, it's easy to name high profile projects which reluctantly converted to git: python, mozilla, pypy. It only got worse over time, "interestingly", about as fast as git consolidated its monopoly. And that's the main flaw in your point, that success somehow is based on merit alone, with no influence of peer/social pressure/network effect.
FYI, I just submitted this post: https://news.ycombinator.com/item?id=39208464 which is pretty much what remains of hosted mercurial today.
Sourcehut can host mercurial repositories.
The only way sending patches through email would actually work is if there was some interface on top of that process that managed that. By that point, it's probably easier to just use ActivityPub/HTTP as your protocol rather than SMTP/IMAP.
I'm a little confused, there are interfaces on top of email based patch workflows? What do you mean?
Absolutely, but it's depressing that we have to build a whole new system instead of dovetailing with a system that not only works but is already universally deployed.
This is the reason why a large part of the Linux kernel is actually developed in GitHub/GitLab. Just search for `github` in the maintainers file to see who many https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
I like the user experience of forges far more than email clients.
(1) It's hard to track the development of a patch in mailing lists unless you actively follow it. Sometimes there will be a v7 patch but it gets buried in the sheer volume of other emails in the list. Sometimes discussions continue in the v6 thread while others occur in v7 so you have to track _both_ threads.
And god forbid people changing subject lines thus breaking the thread.
Meanwhile, discussions in forge workflow tend to be concentrated in the same merge request or issue.
(2) Discovering patches is also a fairly difficult thing to do in mailing lists. The forges include tools like issue trackers and in each issue there is a list of all mentioned merge requests, and the status of those MRs (whether open, closed or merged) are immediately obvious.
(3) I also like labels for similar reasons as (2) - don't get me wrong, I know email subjects often start with "some sort of tag:", but labels are sometimes used to mean "hey, this $MODULE1 code isn't directly related to $MODULE2, but might have some interactions with it so you should take a look". Cc-ing is a manual process which is annoying and like many manual processes is subject to human errors.
(4) Emails rely heavily on conventions, e.g. should people top-post or bottom-post or inline-reply? That introduces a barrier of entry.
As a sidenote, personally I hate that I occasionally have to scroll through long, long, emails that include reply chains from eons ago, but there's nothing email can really do to prevent it from happening. It's conventions all the way down.
(1) It's hard to track the development of a patch in mailing lists unless you actively follow it. Sometimes there will be a v7 patch but it gets buried in the sheer volume of other emails in the list. Sometimes discussions continue in the v6 thread while others occur in v7 so you have to track _both_ threads.
And god forbid people changing subject lines thus breaking the thread.
Meanwhile, discussions in forge workflow tend to be concentrated in the same merge request or issue.
(2) Discovering patches is also a fairly difficult thing to do in mailing lists. The forges include tools like issue trackers and in each issue there is a list of all mentioned merge requests, and the status of those MRs (whether open, closed or merged) are immediately obvious.
(3) I also like labels for similar reasons as (2) - don't get me wrong, I know email subjects often start with "some sort of tag:", but labels are sometimes used to mean "hey, this $MODULE1 code isn't directly related to $MODULE2, but might have some interactions with it so you should take a look". Cc-ing is a manual process which is annoying and like many manual processes is subject to human errors.
(4) Emails rely heavily on conventions, e.g. should people top-post or bottom-post or inline-reply? That introduces a barrier of entry.
As a sidenote, personally I hate that I occasionally have to scroll through long, long, emails that include reply chains from eons ago, but there's nothing email can really do to prevent it from happening. It's conventions all the way down.
> (1) It's hard to track the development of a patch in mailing lists unless you actively follow it.
I would add that if you automatize it somehow, then you don't "just use e-mail", but you have a different protocol for it (over email in this case).
I would add that if you automatize it somehow, then you don't "just use e-mail", but you have a different protocol for it (over email in this case).
I think the beauty of email is that it's already an open, federated standard. Is it easier to build this new activitypub layer on top of all forges, or is it easier to build a decent tool on top of email?
It would be nice if it were the latter but given the stranglehold the major email providers have over email I think it's a lost cause.
Just look at the hoops you have to go through to send a patch over gmail.
Just look at the hoops you have to go through to send a patch over gmail.
The answer to that question depends on where "the mindshare" is, and unfortunately we're living in a future where many seem to believe the former is easy and the latter impossible.
A lot of this could be solved with better tooling on your side, starting with a better mail reader. Mail readers have supported threading since before many of us were born. You don't have to follow an entire mailing list to follow a thread. I know we have to use normie mail readers for general communication but why are people so averse to using a proper mail set up when it makes sense, like for software development? We already use a ton of other tools specific to software development.
A personal todo list system that integrates with your email is also essential. I don't understand how people don't do it. It's all very well forges having status of MRs etc. but surely your job isn't only merging MRs on GitLab? So you'll have other todo lists distributed over various places like other forges, Jira type things and, of course, your email. Why not consolidate all your todos into one place? If you're interested in a patch, add it to your todo list and check the status of it periodically.
Conventions are good. It's part of being human. Learn how to use language to communicate with your fellow humans. It keeps the creative juices flowing.
A personal todo list system that integrates with your email is also essential. I don't understand how people don't do it. It's all very well forges having status of MRs etc. but surely your job isn't only merging MRs on GitLab? So you'll have other todo lists distributed over various places like other forges, Jira type things and, of course, your email. Why not consolidate all your todos into one place? If you're interested in a patch, add it to your todo list and check the status of it periodically.
Conventions are good. It's part of being human. Learn how to use language to communicate with your fellow humans. It keeps the creative juices flowing.
> a lot of this could be solved with better tooling
Yeah, better tooling like GitLab.
Yeah, better tooling like GitLab.
Better tooling in Linux kernel case is moving everything to https://lore.kernel.org/ and https://b4.docs.kernel.org/en/latest/ witch mostly side steps the E-Mail part of the flow.
The amount of people who have the free time to massage `.muttrc` for patch based flow is pretty small. And https://sr.ht/ does not work for the volume that Linux kernel sees.
The amount of people who have the free time to massage `.muttrc` for patch based flow is pretty small. And https://sr.ht/ does not work for the volume that Linux kernel sees.
>tooling
I don't see why we should still use email when half of that requires "non-email" tooling then. I like using emails for person-to-person communication, not this.
And what better tooling could it be if not a tool explicitly designed for software development, like GitHub/GitLab/Gitea?
>Conventions are good. It's part of being human.
It definitely won't keep the creative juices flowing when 99% of said conventions can be automated out. Rather, having to do everything manually impedes my ability to work on actual creative things. This paragraph is also semi-contradictory to your earlier paragraphs on tooling.
I am replying to you on HN without manually typing "From:" "To:" because the website has automated that process for us.
Furthermore, you are wholly sidetracking the core issue here which is "How can we enforce conventions?" The more laborious following a convention is, the harder it is to enforce the convention.
I don't see why we should still use email when half of that requires "non-email" tooling then. I like using emails for person-to-person communication, not this.
And what better tooling could it be if not a tool explicitly designed for software development, like GitHub/GitLab/Gitea?
>Conventions are good. It's part of being human.
It definitely won't keep the creative juices flowing when 99% of said conventions can be automated out. Rather, having to do everything manually impedes my ability to work on actual creative things. This paragraph is also semi-contradictory to your earlier paragraphs on tooling.
I am replying to you on HN without manually typing "From:" "To:" because the website has automated that process for us.
Furthermore, you are wholly sidetracking the core issue here which is "How can we enforce conventions?" The more laborious following a convention is, the harder it is to enforce the convention.
> And what better tooling could it be if not a tool explicitly designed for software development, like GitHub/GitLab/Gitea?
It would be better if the user could actually select his tool instead of being forced upon a tool by a project or company. The former used to be the standard with email. Today, I have the impression half of my colleagues never used a mail program that wasn't called Outlook or Gmail. Spoiler alert: Both are abysmal mail readers for the purpose of following and participating in technical discussions. To fix that, they should at least support proper threading and encourage selective inline replies.
Making the tools a user choice over an established protocol/data model creates lots of possibilities to innovate. As long as Outlook-ordering decisions are made at the C* level it will never support software developers properly.
It would be better if the user could actually select his tool instead of being forced upon a tool by a project or company. The former used to be the standard with email. Today, I have the impression half of my colleagues never used a mail program that wasn't called Outlook or Gmail. Spoiler alert: Both are abysmal mail readers for the purpose of following and participating in technical discussions. To fix that, they should at least support proper threading and encourage selective inline replies.
Making the tools a user choice over an established protocol/data model creates lots of possibilities to innovate. As long as Outlook-ordering decisions are made at the C* level it will never support software developers properly.
>Making the tools a user choice over an established protocol/data model creates lots of possibilities to innovate
If that were the case we wouldn't have had this discussion today. Email workflow is abysmal and the limited innovations it has (patchwork comes to mind) is not enough to attract new developers.
What's worse is that the email workflow is very resistant to changes[0], and arguably, the people supporting the email workflow are too. It's hard for one to imagine there is a chance of innovation given the current predication. Even a complementary system like patchwork has remained relatively unadopted according to my non-scientfic observations (most people are likelier to link to the mail directly instead of the patch series on patchwork).
[0]: Building a more complicated system akin to the forges on top of emails will likely require modifications to the original email workflow, e.g. to add metadata. I don't know how well people will receive it, I'd imagine very badly.
If that were the case we wouldn't have had this discussion today. Email workflow is abysmal and the limited innovations it has (patchwork comes to mind) is not enough to attract new developers.
What's worse is that the email workflow is very resistant to changes[0], and arguably, the people supporting the email workflow are too. It's hard for one to imagine there is a chance of innovation given the current predication. Even a complementary system like patchwork has remained relatively unadopted according to my non-scientfic observations (most people are likelier to link to the mail directly instead of the patch series on patchwork).
[0]: Building a more complicated system akin to the forges on top of emails will likely require modifications to the original email workflow, e.g. to add metadata. I don't know how well people will receive it, I'd imagine very badly.
> Building a more complicated system akin to the forges on top of emails will likely require modifications to the original email workflow, e.g. to add metadata.
Emails do have header, there is no problem storing metadata in those.
Emails do have header, there is no problem storing metadata in those.
"Metadata" here refers to everything surrounding the git repo, e.g. CI status, milestones, or even reactions. Those metadata are constantly updated and since there are no mechanisms to retroactively update previous emails to include the new metadata, the only way to do it is to send even more emails to the already-voluminous mailing list to keep the email-only people updated.
This is why I have serious doubts on the possibility to build forges (with accessibility and feature set on par with GitHub/GitLab) on top of emails. And please, don't use the minimalism excuse because those extra features of forges _are_ being used. Removing them for the sake of forge-on-email is a strict UX degradation and you only end up making both forge people and email people angry.
Another way to share those metadata through emails is to send an email that links to an external HTTP website which displays the latest updated data, as is done by some projects for CI. But at that point, it ceases to be an "email workflow" in my opinion -- if you are already hosting a HTTP server, you might as well host a git forge on it.
This is why I have serious doubts on the possibility to build forges (with accessibility and feature set on par with GitHub/GitLab) on top of emails. And please, don't use the minimalism excuse because those extra features of forges _are_ being used. Removing them for the sake of forge-on-email is a strict UX degradation and you only end up making both forge people and email people angry.
Another way to share those metadata through emails is to send an email that links to an external HTTP website which displays the latest updated data, as is done by some projects for CI. But at that point, it ceases to be an "email workflow" in my opinion -- if you are already hosting a HTTP server, you might as well host a git forge on it.
You bring up valid points. I am not at all arguing we should strive for minimalism and reduce features that are actually used. If we are already using html emails for everything, why can't we embed the little build status widgets, plugins, tags -- whatever they are called -- that you find in many readme file on Github into html emails?
Or it is great idea to have a plugin for your mail program showing the build status of your ci plugin next to the email about the pull/merge request?
Or it is great idea to have a plugin for your mail program showing the build status of your ci plugin next to the email about the pull/merge request?
So your advice is to reinvent to very good and battle tested wheel of GitHub and GitLab around multiple different extra tools which don't even come close?
Do you also DIY your dishwasher with an assembly line, a rotating robotic arm with a sponge, industrial chemicals? Or do you just use an off the shelf dishwasher if you're at the sufficient scale needed for one?
Do you also DIY your dishwasher with an assembly line, a rotating robotic arm with a sponge, industrial chemicals? Or do you just use an off the shelf dishwasher if you're at the sufficient scale needed for one?
> So your advice is to reinvent to very good and battle tested wheel of GitHub
GitHub isn't analogous to a wheel. GitHub is a proprietary service owned by one company. Any patent on the wheel has long expired.
GitHub isn't analogous to a wheel. GitHub is a proprietary service owned by one company. Any patent on the wheel has long expired.
A web-based collaborative Git-based VCS is a wheel. There are like 10 different projects, the majority of which are open source or at least open core.
Wait, are you saying email is reinventing the wheel that is GitLab etc.? I think your history might be a bit backward here.
My advice is to develop your own personal tools in such a way that you can handle all kinds of interactions with other developers and projects. It's pointless saying "I prefer this or that" when you probably don't get to make those decisions. Projects develop workflows and common tooling like forges for practical reasons. But you, as an individual, shouldn't be tied to any one of them.
My point isn't at all about trying to switch projects from forges to email based workflows, it's merely saying that you can do things to improve your tools such that you can interact with those projects. If you find it difficult to work with a successful project with many contributors then you are the problem, not them.
My advice is to develop your own personal tools in such a way that you can handle all kinds of interactions with other developers and projects. It's pointless saying "I prefer this or that" when you probably don't get to make those decisions. Projects develop workflows and common tooling like forges for practical reasons. But you, as an individual, shouldn't be tied to any one of them.
My point isn't at all about trying to switch projects from forges to email based workflows, it's merely saying that you can do things to improve your tools such that you can interact with those projects. If you find it difficult to work with a successful project with many contributors then you are the problem, not them.
> Wait, are you saying email is reinventing the wheel that is GitLab etc
Bolting a million custom tools around email to force it to do something it was never meant to do is reinventing the wheel, yes.
> Projects develop workflows and common tooling like forges for practical reasons. But you, as an individual, shouldn't be tied to any one of them.
Yes, and very very few of them prefer arcane workflows such as patches over email. Some highly critical ones like the Linux kernel do, but the vast vast vast majority of products use well oiled machines like GitHub, GitLab, Gogs, Gitea, etc.
Bolting a million custom tools around email to force it to do something it was never meant to do is reinventing the wheel, yes.
> Projects develop workflows and common tooling like forges for practical reasons. But you, as an individual, shouldn't be tied to any one of them.
Yes, and very very few of them prefer arcane workflows such as patches over email. Some highly critical ones like the Linux kernel do, but the vast vast vast majority of products use well oiled machines like GitHub, GitLab, Gogs, Gitea, etc.
> why are we like this
It's not clear about what you're complaining here. What exactly is ridiculous?
This just offers a different channel through which to circulate patches. Unlike email, which requires everyone follow some ad-hoc convention in the email message, with ActivityPub the protocol itself can support structured data about the patch.
It's not clear about what you're complaining here. What exactly is ridiculous?
This just offers a different channel through which to circulate patches. Unlike email, which requires everyone follow some ad-hoc convention in the email message, with ActivityPub the protocol itself can support structured data about the patch.
You know that even Linus recently said that Linux has outgrown the email workflow and needs to find an alternative?
Do you have a source for that? I would like to learn more about that
E-mail based workflow for Linux is starting to break down as the amount of patches is too huge.
* https://lwn.net/Articles/860607/
* https://lwn.net/Articles/952034/
* https://lwn.net/Articles/952146/
* https://lwn.net/Articles/950567/
* https://lwn.net/Articles/959069/
* https://lwn.net/Articles/815332/
* https://lwn.net/Articles/860607/
* https://lwn.net/Articles/952034/
* https://lwn.net/Articles/952146/
* https://lwn.net/Articles/950567/
* https://lwn.net/Articles/959069/
* https://lwn.net/Articles/815332/
Very interesting, thanks for sharing. It’s nice to see a side of this which isn’t just about a clash of tech cultures (it seems).
Sure:
> What is really needed, he said, is to find ways to get away from the email patch model, which is not really working anymore. He feels that way now, even though he is "an old-school email person". [0]
[0]: https://lwn.net/Articles/952034/
> What is really needed, he said, is to find ways to get away from the email patch model, which is not really working anymore. He feels that way now, even though he is "an old-school email person". [0]
[0]: https://lwn.net/Articles/952034/
Last thing I want in my workflow is fucking email.
I understand that for some people digging through their email (and mailing lists archives) is fun but this is just a tiny minority.
I understand that for some people digging through their email (and mailing lists archives) is fun but this is just a tiny minority.
I think a lot of people get annoyed by email because they're used to using it in crappy web-based clients. In 2021 I switched back to using Thunderbird after many years using web gmail and my god it's a breath of fresh air.
I'm not opposed to web based git Forges provided they're reasonably responsive and not sluggishly slow like GitLab has become.
I'm not opposed to web based git Forges provided they're reasonably responsive and not sluggishly slow like GitLab has become.
I've used Outlook, Thunderbird, The Bat, Airmail, Spark and a few others I think.
Nothing beats not using email at all.
Fastmail has a good web client though. But what is more important it has aliases and "Masked email". They kind of make you life with email a bit more bearable.
Still - best email is dead email.
Nothing beats not using email at all.
Fastmail has a good web client though. But what is more important it has aliases and "Masked email". They kind of make you life with email a bit more bearable.
Still - best email is dead email.
The difference is, I can customize my mail reader to my preferences. I can use macros to streamline my repetitive work with it. Neither is easily done with forges.
Not every thing needs customization.
Good defaults and good UI UX allow you to be done with your work quickly and even with some satisfaction from the process.
Neither applies to email in my opinion.
Good defaults and good UI UX allow you to be done with your work quickly and even with some satisfaction from the process.
Neither applies to email in my opinion.
But email does not have an UI, only mail reader application do have a UI. And many modern default mail reader applications have an awful UI, but that is not a sign of email being somehow bad.
That email clients is the way they are by default, should already say something, no?
The majority of people use emails like electronic mails because that's what email is designed for! Source code sharing is a separate protocol bolted onto email, and the fact that you have to use a specific email client (which I should mention, is largely unheard of outside of a small circle) is indeed an admittance of email being bad.
It's possible that you can fix a car with just a knife. But considering the difficulties and how unintuitive it is - is that not a sign of knife being somehow bad for the job?
The majority of people use emails like electronic mails because that's what email is designed for! Source code sharing is a separate protocol bolted onto email, and the fact that you have to use a specific email client (which I should mention, is largely unheard of outside of a small circle) is indeed an admittance of email being bad.
It's possible that you can fix a car with just a knife. But considering the difficulties and how unintuitive it is - is that not a sign of knife being somehow bad for the job?
> Source code sharing is a separate protocol bolted onto email, and the fact that you have to use a specific email client (which I should mention, is largely unheard of outside of a small circle) is indeed an admittance of email being bad.
No, email is better suited for meaningful communication than most forums and code review web interfaces. And that is a direct consequence of the fact that it was designed to facilitate communication between humans. Github is simply missing a way to see easily and intuitively which message responded which other. I am thinking of something like the classic threading tree of an email client. That information makes it much easier to follow a discussion between more than two people.
That same tree is also great at showing what I have already read and what is new. How do you do that in GitHub? As far as I know there is no way to do that. I can even label certain messages just for me. In order to keep the overview. I can move emails between folders virtual or not to organize all the communication threads that I am participating in. Neither of which is possible with pull requests in GitHub or almost every other forge.
No, email is better suited for meaningful communication than most forums and code review web interfaces. And that is a direct consequence of the fact that it was designed to facilitate communication between humans. Github is simply missing a way to see easily and intuitively which message responded which other. I am thinking of something like the classic threading tree of an email client. That information makes it much easier to follow a discussion between more than two people.
That same tree is also great at showing what I have already read and what is new. How do you do that in GitHub? As far as I know there is no way to do that. I can even label certain messages just for me. In order to keep the overview. I can move emails between folders virtual or not to organize all the communication threads that I am participating in. Neither of which is possible with pull requests in GitHub or almost every other forge.
Okay, but what other choice do I have? Neuralink?
But why do you need email if git is already built for decentralized communication? That's the core of the problem. Just add the ability to ask for pull requests, to comment, etc into git and nobody will build those insane protocol-on-top-of-a-protocol-to-communicate-with-a-side-protocol monstrosities.
git-appraise[1] implements that concept. From Google, no less.
I've never used it, or seen it used in the wild, but it always seemed intriguing, and like the obvious approach. The web UI traction is far greater for this to have any serious usage, but I wonder if Git had that ability from the start, if the web UI concept would've taken off as it did.
[1]: https://github.com/google/git-appraise
I've never used it, or seen it used in the wild, but it always seemed intriguing, and like the obvious approach. The web UI traction is far greater for this to have any serious usage, but I wonder if Git had that ability from the start, if the web UI concept would've taken off as it did.
[1]: https://github.com/google/git-appraise
Similarly Gerrit stores everything, including permissions, in Git as well. I'm not sure there is an offline review flow yet, though, but it's certainly possible.
> Just add the ability to ask for pull requests, to comment, etc into git
That's a major understatement. To "just" add this into mainline git, you'd essentially need to either fork git itself in order to add these features or figure a way to add this without making breaking changes, and then convince git maintainers that your PR is worth adding, and then convince enough people to actually use this new standard in place of what they already have (which will also need them to integrate this with their existing forge infrastructure to mitigate XKCD Standards).
That's a major understatement. To "just" add this into mainline git, you'd essentially need to either fork git itself in order to add these features or figure a way to add this without making breaking changes, and then convince git maintainers that your PR is worth adding, and then convince enough people to actually use this new standard in place of what they already have (which will also need them to integrate this with their existing forge infrastructure to mitigate XKCD Standards).
I've wondered if there might be room for services that use email as their communication channel. Something like this would be perfect for it. The forges would send emails to communicate in issues, information is distributed via mailing lists, but forges parse and display the information in their own way. They become fancy single-purpose email clients basically.
With such a system, people could also contribute by writing the same emails by hand, as long as the format remains accessible. And no special protocols necessary, all existing mailing list infrastructure can be used instead of designing new complicated ways of doing the same thing.
With such a system, people could also contribute by writing the same emails by hand, as long as the format remains accessible. And no special protocols necessary, all existing mailing list infrastructure can be used instead of designing new complicated ways of doing the same thing.
I’ve used email a bit and there are some pros and cons.
For email: It’s just there already, like you mention. Once you are setup you can do things like comment on a “line of code” very straightforwardly. It’s already distributed and all that. There are bespoke (project-specific probably) bridges from forges (maybe mostly GitHub) to mailing lists.
For this new thing: You don’t have to worry about all the legacy of email. You don’t have to worry about 90% of the world using email “wrong” according to techies. You can probably track changes more easily than keeping track of where you sent patches. You don’t have to make bespoke forge-to-email bridges.
For email: It’s just there already, like you mention. Once you are setup you can do things like comment on a “line of code” very straightforwardly. It’s already distributed and all that. There are bespoke (project-specific probably) bridges from forges (maybe mostly GitHub) to mailing lists.
For this new thing: You don’t have to worry about all the legacy of email. You don’t have to worry about 90% of the world using email “wrong” according to techies. You can probably track changes more easily than keeping track of where you sent patches. You don’t have to make bespoke forge-to-email bridges.
> Contemplating this through the lens of simply using floppy disks and FedEx (ala Real Actual Serious Programming) to share, review and consume patches, among other things, I can't help but conclude that ultimately this is all totally fucking ridiculous.
> Sure, it's cool I can send an email with a patch to another user instantly, but... why are we like this
> Sure, it's cool I can send an email with a patch to another user instantly, but... why are we like this
Different tools, different audiences. Sibling comments show that many people prefer the rich UI's that Gitlab, Github, Gitea etc. offer, while others prefer more hardcore brutal minimalism. Each audience is served with their favorite tools. For instance Sourcehut is a great product if you like mail and sending patches. What I find a bit tiresome, and witness mostly 'the minimalists' doing so, is people coming in with "This is shite" religious notions on what is 'the right way'. There is choice. And that is wonderful.
Enabling devs to be "social" in their way is a good trend.
> simply using email and git (ala Linux) to share, review and consume patches
yeah, but when was the last time any of us did that...?
yeah, but when was the last time any of us did that...?
Because people don't know about https://sr.ht
I'm intrigued, can you elaborate?
does sourcehut support shat gitlab is trying to achieve here?
Does sr.ht support cross instance patches? Yes. Even better, you don't even need an account on any sr.ht instance to send a patch, or receive one for that matter.
It's just email. And it can do many of the things other forges do. Trigger builds, comment on patches, track issues, etc.
It's just email. And it can do many of the things other forges do. Trigger builds, comment on patches, track issues, etc.
"Why are people making new tools instead of using the antiquated ones I'm familiar with?"
why are we like this? because decentralization removes power from big corps. thats justification enough.
One of gitlab's programmers comments on implementing ForgeFed in this context: https://gitlab.com/groups/gitlab-org/-/epics/11247#note_1529...
The comment you linked is not from a GitLab employee but a community contributor.
Okay, let's think this a little further:
I now have the possibility to open PRs and comment on them for a repo that is hosted on another instance. I still have to deal with user permission. Just because others can interact with my GitLab instance and repos I don't necessary want them to see everything. So user permissions is still a thing.
It would just have the time of creating an external user on my instance (or paying premium for them). Buth this could also be archived via OIDC logins of specific allowed accounts.
Am I missing the advantages here?
I now have the possibility to open PRs and comment on them for a repo that is hosted on another instance. I still have to deal with user permission. Just because others can interact with my GitLab instance and repos I don't necessary want them to see everything. So user permissions is still a thing.
It would just have the time of creating an external user on my instance (or paying premium for them). Buth this could also be archived via OIDC logins of specific allowed accounts.
Am I missing the advantages here?
Sharing of private resources is explicitly stated as a non-goal.
Does ActivityPub even support interactions that are actually private? Last time I worked with it, the private messaging was more akin to "please don't read this postcard" in the mailbox.
I guess it depends on your definition of privacy but if you're thinking about end-to-end encryption then there's nothing like that in ActivityPub. Admins of the receiver and the sender can see all messages including direct messages. They are not visible to the broader public though.
ActivityPub supports authorized requests from federated actors, which would allow access to private resources. It would be a trivial exercise (speaking here as someone that implements fediverse software) to add permissions for users on other gitlab instances.
Does GitLab have an existing Fediverse presence, for example on a Mastodon instance?
> People want a single, global GitLab network
This sounds like they're trying to make a proprietary GitLab-only alternative to Forgefed. I don't understand who would want this.
Edit:
Ah, this sounds like the opposite: https://gitlab.com/groups/gitlab-org/-/epics/11247#note_1529...
Good!
This sounds like they're trying to make a proprietary GitLab-only alternative to Forgefed. I don't understand who would want this.
Edit:
Ah, this sounds like the opposite: https://gitlab.com/groups/gitlab-org/-/epics/11247#note_1529...
Good!
A tool that automatically scraped github issues etc into a standard format and committed them to the repo could accomplish the same thing, no activitypub needed!
Then collaborating peer forges could clone the info straight from git and submit changes etc. I think git already has all the sharing tools necessary, what is needed is standards and converters.
Then collaborating peer forges could clone the info straight from git and submit changes etc. I think git already has all the sharing tools necessary, what is needed is standards and converters.
GitHub has a number of weird repos from popular projects which are just copies of other repos. You can look, but you can't touch. (WordPress and Linux are the big ones).
It would be brilliant to look at a project in my preferred UI and raise issues / PRs without having to sign up to yet another service.
Very excited to see how this pans out.