Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gitlab's ActivityPub architecture blueprint

docs.gitlab.com

Post reply on HN
Print view View original

71–80 of 107 posts

Re: Gitlab's ActivityPub architecture blueprint

#71

Post by orangeboats »

funcDropShadow wrote: post #65
orangeboats wrote: post #48

Earlier quoted context omitted.

>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 conventio…

> 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 aler…

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

Re: Gitlab's ActivityPub architecture blueprint

#72

Post by westurner »

meekins wrote: post #31
edent wrote: post #30

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 havin…

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

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

Re: Gitlab's ActivityPub architecture blueprint

#74

Post by mariusor »

madeofpalk wrote: post #58
mariusor wrote: post #46

Earlier quoted context omitted.

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 be…

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

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

Re: Gitlab's ActivityPub architecture blueprint

#75

Post by mariusor »

ezst wrote: post #61
mariusor wrote: post #46

Earlier quoted context omitted.

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 be…

> 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+…

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.

Re: Gitlab's ActivityPub architecture blueprint

#76

Post by treyd »

meekins wrote: post #31
edent wrote: post #30

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 havin…

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.

Re: Gitlab's ActivityPub architecture blueprint

#77

Post by taeric »

madeofpalk wrote: post #16
alufers wrote: post #13

Earlier quoted context omitted.

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…

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?

Re: Gitlab's ActivityPub architecture blueprint

#78

Post by Aachen »

pera wrote: post #59
meekins wrote: post #31

Earlier quoted context omitted.

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

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

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

Re: Gitlab's ActivityPub architecture blueprint

#79

Post by treyd »

Aachen wrote: post #78
pera wrote: post #59

Earlier quoted context omitted.

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

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 (…

Fwiw, GitHub has been on the news occasionally in at least the US.

Re: Gitlab's ActivityPub architecture blueprint

#80

Post by treyd »

konart wrote: post #20
xyzzy_plugh wrote: post #3

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

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

Post reply on HN