[HN Gopher] Gitlab's ActivityPub architecture blueprint
___________________________________________________________________
Gitlab's ActivityPub architecture blueprint
Author : p4bl0
Score : 203 points
Date : 2024-01-31 08:37 UTC (14 hours ago)
(HTM) web link (docs.gitlab.com)
(TXT) w3m dump (docs.gitlab.com)
| ocdtrekkie wrote:
| 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?
| EspadaV9 wrote:
| Don't suppose you have links to the work they have been doing
| towards this?
| ocdtrekkie wrote:
| Of course: https://forgefed.org/
| EspadaV9 wrote:
| :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 :-)
| EspadaV9 wrote:
| 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_plugh wrote:
| 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 wrote:
| Because people don't know about https://sr.ht
| RamblingCTO wrote:
| I'm intrigued, can you elaborate?
| joshxyz wrote:
| does sourcehut support shat gitlab is trying to achieve here?
| themk wrote:
| 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.
| SushiHippie wrote:
| https://git-send-email.io/
| DANmode wrote:
| Enabling devs to be "social" in their way is a good trend.
| alufers wrote:
| 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.
| madeofpalk wrote:
| 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.
| xyzzy_plugh wrote:
| 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.
| taeric wrote:
| I'm a little confused, there are interfaces on top of email
| based patch workflows? What do you mean?
| JoshTriplett wrote:
| > 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.
| LudwigNagasena wrote:
| 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.
| JoshTriplett wrote:
| Hopefully federated forges will make that easier, since
| it'll be easy for anyone to interface with using whatever
| technology they prefer.
| mariusor wrote:
| 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.
| madeofpalk wrote:
| > 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.
| mariusor wrote:
| 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. :)
| ezst wrote:
| > 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.
| mariusor wrote:
| 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.
| ezst wrote:
| >> 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.
| mariusor wrote:
| Sourcehut can host mercurial repositories.
| avgcorrection wrote:
| 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.)
| JoshTriplett wrote:
| > 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`.
| avgcorrection wrote:
| 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)
| argulane wrote:
| 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.or
| g/pub/scm/linux/kernel/git/torvalds/lin...
| anentropic wrote:
| > 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 wrote:
| > 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
| orangeboats wrote:
| 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 wrote:
| > (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).
| myaccountonhn wrote:
| 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?
| couchand wrote:
| 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.
| xyzzy_plugh wrote:
| 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.
| globular-toast wrote:
| 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.
| Hendrikto wrote:
| > a lot of this could be solved with better tooling
|
| Yeah, better tooling like GitLab.
| argulane wrote:
| 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.
| orangeboats wrote:
| >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.
| funcDropShadow wrote:
| > 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.
| orangeboats wrote:
| >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.
| sofixa wrote:
| 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?
| grey_earthling wrote:
| > 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.
| sofixa wrote:
| 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.
| globular-toast wrote:
| 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.
| sofixa wrote:
| > 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.
| konart wrote:
| 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.
| funcDropShadow wrote:
| 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.
| konart wrote:
| 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.
| treyd wrote:
| 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.
| konart wrote:
| 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.
| LudwigNagasena wrote:
| 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 wrote:
| 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
| xyzzy_plugh wrote:
| 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.
| phoe-krk wrote:
| _> 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).
| Hendrikto wrote:
| You know that even Linus recently said that Linux has outgrown
| the email workflow and needs to find an alternative?
| aloisdg wrote:
| Do you have a source for that? I would like to learn more
| about that
| Hendrikto wrote:
| 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/
| argulane wrote:
| 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/
| avgcorrection wrote:
| 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).
| rapnie wrote:
| 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.
| mariusor wrote:
| > 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 wrote:
| why are we like this? because decentralization removes power
| from big corps. thats justification enough.
| badrequest wrote:
| "Why are people making new tools instead of using the
| antiquated ones I'm familiar with?"
| avgcorrection wrote:
| 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.
| wielebny wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Sharing of private resources is explicitly stated as a non-
| goal.
| manfre wrote:
| 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.
| wiktor-k wrote:
| 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.
| mariusor wrote:
| 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 wrote:
| Does GitLab have an existing Fediverse presence, for example on a
| Mastodon instance?
| edent wrote:
| 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 wrote:
| It would be awesome to see Git becoming decentralized again but
| what's the likelihood of GitHub implementing this?
| tazjin wrote:
| Everyone knows the answer to that ;)
| znpy wrote:
| None, that's why github is awful
| ragebol wrote:
| 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 wrote:
| 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 wrote:
| 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
| Aachen wrote:
| 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
| treyd wrote:
| Fwiw, GitHub has been on the news occasionally in at
| least the US.
| westurner wrote:
| - "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?_
| treyd wrote:
| 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.
| badrequest wrote:
| Pages predates Microsoft's acquisition, and I can use
| Copilot on the repos I commit to any other source control
| system.
| paulddraper wrote:
| > Microsoft knew that GitHub had no moat
|
| GitHub had the best moat: network.
|
| But yes, the additions have only deepened it.
| grey_earthling wrote:
| > 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!
| radarsat1 wrote:
| 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 wrote:
| >what is needed is standards and converters.
|
| You mean a standard like activitypub? /s
| radarsat1 wrote:
| 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 wrote:
| One of gitlab's programmers comments on implementing ForgeFed in
| this context: https://gitlab.com/groups/gitlab-
| org/-/epics/11247#note_1529...
| leipert wrote:
| The comment you linked is not from a GitLab employee but a
| community contributor.
___________________________________________________________________
(page generated 2024-01-31 23:02 UTC)