Several years in the making, GitLab is now very actively implementing #ActivityPub!
https://gitlab.com/groups/gitlab-org/-/epics/11247
The end-goal is to support AP for merge requests (aka pull requests), meaning git.alice.dev can send a merge request to gitlab.com/Bob/project.git
First bite-sized todo on the implementation path there is ‘subscribe to project releases’.
Smart move by #GitLab; through ActivityPub they’re getting a distributed version of GitHub’s social layer.
@erlend @fediversenews Awesome! I read the thread and saw no mention of @forgefed either, do you folks know anything about these efforts?
@astrojuanlu @erlend @fediversenews I'm also a little worried so see so little mention of @forgefed, and especially the idea that it's something that will be used for some small parts later without necessarily considering compatibility from the beginning. I hope I'm just misinterpreting what's been written and that ForgeFed compatibility will be taken into account at every stage.
@caesar @astrojuanlu @erlend @fediversenews
A contributor discussed @forgefed in the comments on that issue a few hours ago: https://gitlab.com/groups/gitlab-org/-/epics/11247#note_1529285198
@caesar @astrojuanlu @erlend @fediversenews @forgefed
Excerpt:
“Yep, I saw it, it looks awesome. :) It will be a good protocol [for] cross-instance discussions and merge requests.
The current [proposal] allow people on the fediverse to follow activity on Gitlab instances, without write access,[…] I prefer to avoid using an extension of ActivityPub
Given how ForgeFed already did all the design work, I don't see any reason not to use it”