Federation between gogs instances

[yookoala]

Description

The elevator pitch would be this:

"It would be great to fork / send pull request between public repositories across different gogs installation. So it would be great to have a way to federate between gogs instances."

My suggestion would be to look at ActivityPub, in-particular the "Federation Protocol", and see if we can federate through that protocol. The protocol is for building decentralized social network. But I think it is extensible with custom message type like "Fork" or "Pull-request".

[bachy]

ho yes please please please (begging dog face)

[ghost]

This is the github-killer feature.

[wakawakaeldondolero]

Yes please add federation! For me this is the n1 priority! Definitely the github killer feature!

[link2xt]

ActivityPub is for stars (called likes in ActivityPub) and following.

For forks, there is https://webmention.net/ This protocol can be used to notify source repository whenever it is cloned via gogs mirror/migration feature. It is indented for mentioning in blog posts, but can be easily adopted for forks and pull requests.

[yookoala]

We may consider "Fork" as a custom "ActivityType" as described by ActivityStreams Vocabs, an ActivityStreams extension.

[Skehmatics]

Another project that may be of use: https://github.com/go-fed/activity

[yookoala]

Relevant proposal in gitea repository:
go-gitea/gitea#1612

In Gitlab's repository:
https://gitlab.com/gitlab-org/gitlab-ee/issues/4517

[yookoala]

Let's lay down (and discuss) what needed to be done first.

Terms

Git Service: Web based Git service like Gogs, Gitea, Gitlab.
Web Repository: Web based entity on a Git Service that represents an underlying Git repository branch.
upstream: A git repository where a PR is being sent TO.
downstream: A git repository where a PR is being sent FROM.

Features

For federation, these are the base line features:

1. Allow user to create a Pull Request to a remote upstream Web Repository.
2. Allow an upstream Web Repository to receive a Pull Request from a downstream Web Repository.
3. Allow a downstream Web Repository to report updates (e.g. git push) of a branch to an upstream Web Repository that it previously sent Pull Request to.
4. Allow an upstream Web Repository to notify a remote Git Service that a Pull Request is commented, tagged, assigned, reviewed, closed, re-openned or otherwise updated.

Based on these feature needs, It might also be essential to allow any Web Repository (specific branch) to be properly addressable and discover-able by query protocol (e.g. Like how Mastodon use Web Finger). This universal address should be differ from user or organization.

[cwebber]

Hi! ActivityPub co-editor here. I'm fairly busy at the moment but I'd like to see this happen... if you need questions feel free to ping me, or ask in #social on irc.w3.org

[cjslep]

Please do not hesitate to reach out to me on Mastodon for any questions/concerns/comments surrounding the https://github.com/go-fed/activity library that @Skehmatics mentioned. I obviously have a vested interest in the outcome of the decision, but would happy to provide candid information about my experiences working in the go+ActivityPub intersection.

(I saw the gitea issue first but I wanted to extend the same offer here...)

[benyanke]

This would indeed be killer - my main concern with moving off github is the lack of "social interface" that you get.

If this can somehow replicate that to some degree....that'd be amazing.

[yookoala]

Some more thoughts: We'd also need to cater for Forking.

Downstream should notify the upstream about their forking address (so upstream could tell the owner). Potentially, a downstream would wants to know about upstream changes and vice verse. So a general subscription would be needed (which should comes natural to ActivityPub).

Features (appending to this comment)

5. Allow user to create a Fork notification to a remote upstream Web Repository.
6. Allow an upstream Web Repository to receive a Fork notification from a downstream Web Repository (not branch specific).
7. Allow any agent to subscribe to any Web Repository updates.

[tobast]

An even more killer feature would be to make sure every major git tracking system uses the same standard, so that it would be able to federate Gogs with Gitlab, Gitea, … and why not even Github if the protocol gets big enough.

[yookoala]

@cwebber: I plan to draft a specification document in this repository:
https://github.com/git-federation/gitpub

I feel like it is the best move to kick this off. But I'm have no experience in drafting such a thing. Please advice / join the effort. Thanks.

[jaywink]

An even more killer feature would be to make sure every major git tracking system uses the same standard, so that it would be able to federate Gogs with Gitlab, Gitea,

I think this should even be the most important thing to consider before implementing anything - getting some specs agreed so that platforms can actually talk to each other.

Good stuff! <3

[ppwfx]

just to be clear, the look and feel would be something like if I have a private gog instance and I search for a repo, and it's hosted on e.g. a gitlab instance, I would see that repo, issues etc. in my gog ui, right?

and the clone address would still point to the gitlab instance or?

so in the end it's going to turn all participating git services in "uis", that allow the user to browser the gitpub net?

[tobast]

just to be clear, the look and feel would be something like if I have a private gog instance and I search for a repo, and it's hosted on e.g. a gitlab instance, I would see that repo, issues etc. in my gog ui, right?

This looks a bit overkill to me. The original idea, as I understand it (please correct me if I'm wrong) would be (at least in a first place) to federate PRs and forks, to make them behave "as if" the two repos were on the same gogs/gitlab/whatever instance.

Eg., I would be able to fork the gitlab project (hosted on gitlab) on my own Gogs instance, and this fork would be referenced there, so that the original project can track public forks. Then, I would be able to submit painlessly a PR to the original repo.

[ppwfx]

hm.. to me federation is when a lot of people share n bigger instances that are interconnected with each other

if only prs and forks are shared how can somebody open an issue or comment?

[yookoala]

@21stio: Federation does mean what you say. Gogs / Gitea / Gitlab instances are those n bigger instances. And the goal for confederation is to have their major workflow inter-connectable. So the specification of such federation needs to answer "what should be connected".

I think on the baseline, issues and comments are to be handled by the target repository server. But if the federation does not handle PRs and Forks, the federation does not make any sense.

In longer terms, issues and comments can be federated the same way as Post as specified in ActivityPub. We might not need to specify what is already an open standard.

[ppwfx]

besides the overall vision, adding something like activitypub or gitpub will have huge implications to the underlying data model and persistence layer of gogs/gitea/gitlab.. something that can only work with the consent of the maintaners @unknwon

[yookoala]

I'd love to have @unknwon in the discussion / drafting of the specification.

[unknwon]

@yookoala The idea of gitpub sounds interesting, I would love to implement if we have an open standard.

[drequivalent]

We have an ActivityPub library in Go now!

https://github.com/go-fed

[jaywink]

ForgeFed is a work in progress specification for extensions to ActivityPub for supporting forges. Would be great to get someone from Gogs involved.

Repository: https://notabug.org/peers/forgefed/
Forum: https://talk.feneas.org/c/forgefed

[Aspie96]

This is a great idea.

Is there any progress on this issue?

[cjslep]

FYI: the github.com/go-fed/activity library has been released at v1.0.0, which includes complete support for the ForgeFed Vocabulary.