Gitlab's ActivityPub architecture blueprint

https://docs.gitlab.com/ee/architecture/blueprints/activity_pub/

by p4bl0 • 2 years ago

232 106 2 years ago

docs.gitlab.com

ocdtrekkie2• 2 years ago

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?

EspadaV93• 2 years ago

Don't suppose you have links to the work they have been doing towards this?

ocdtrekkie2• 2 years ago

Of course: https://forgefed.org/

EspadaV93• 2 years ago

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

xyzzy_plugh4• 2 years ago

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

crotchfire• 2 years ago

Because people don't know about https://sr.ht

RamblingCTO• 2 years ago

I'm intrigued, can you elaborate?

joshxyz• 2 years ago

does sourcehut support shat gitlab is trying to achieve here?

SushiHippie• 2 years ago

https://git-send-email.io/

DANmode• 2 years ago

Enabling devs to be "social" in their way is a good trend.

alufers• 2 years ago

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.

madeofpalk2• 2 years ago

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.

JoshTriplett4• 2 years ago

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.

argulane3• 2 years ago

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

anentropic• 2 years ago

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

orf• 2 years ago

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

orangeboats5• 2 years ago

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.

bmacho• 2 years ago

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

globular-toast2• 2 years ago

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.

konart4• 2 years ago

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.

funcDropShadow6• 2 years ago

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.

treyd3• 2 years ago

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.

LudwigNagasena2• 2 years ago

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.

imiric• 2 years ago

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

phoe-krk• 2 years ago

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

Hendrikto3• 2 years ago

You know that even Linus recently said that Linux has outgrown the email workflow and needs to find an alternative?

aloisdg• 2 years ago

Do you have a source for that? I would like to learn more about that

rapnie• 2 years ago

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.

mariusor6• 2 years ago

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.

ekianjo• 2 years ago

why are we like this? because decentralization removes power from big corps. thats justification enough.

badrequest2• 2 years ago

"Why are people making new tools instead of using the antiquated ones I'm familiar with?"

avgcorrection4• 2 years ago

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.

radarsat13• 2 years ago

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.

wielebny• 2 years ago

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.

rvense• 2 years ago

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.

kodama-lens• 2 years ago

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?

emaro• 2 years ago

Sharing of private resources is explicitly stated as a non-goal.

manfre• 2 years ago

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.

mariusor6• 2 years ago

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.

smilingsun• 2 years ago

Does GitLab have an existing Fediverse presence, for example on a Mastodon instance?

edent• 2 years ago

This is fantastic. I stick my personal projects on GitLab and Codeberg - but if I want people to contribute, I use GitHub; that's where the people are.

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.

meekins• 2 years ago

It would be awesome to see Git becoming decentralized again but what's the likelihood of GitHub implementing this?

tazjin• 2 years ago

Everyone knows the answer to that ;)

znpy• 2 years ago

None, that’s why github is awful

ragebol• 2 years ago

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.

rglullis• 2 years ago

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?"

pera• 2 years ago

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

westurner• 2 years ago

- "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?

treyd3• 2 years ago

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.

ubertaco• 2 years ago

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.

grey_earthling2• 2 years ago

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!

radarsat13• 2 years ago

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.

alex_duf• 2 years ago

what is needed is standards and converters.

You mean a standard like activitypub? /s

radarsat13• 2 years ago

No, I mean a standard for the forge things like issues and comments and pull requests. The things that would be carried over activitypub here.

vaylian• 2 years ago

One of gitlab's programmers comments on implementing ForgeFed in this context: https://gitlab.com/groups/gitlab-org/-/epics/11247#note_1529...

leipert• 2 years ago

The comment you linked is not from a GitLab employee but a community contributor.

Gitlab's ActivityPub architecture blueprint

Related Stories