Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upFederation between gogs instances #4437
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
bachy
commented
Apr 24, 2017
|
ho yes please please please (begging dog face) |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ghost
commented
May 30, 2017
|
This is the github-killer feature. |
Unknwon
added
kind/feature
priority/low
labels
Jun 8, 2017
Unknwon
changed the title from
[Feature] Federation between gogs instances
to
Federation between gogs instances
Jun 8, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
wakawakaeldondolero
Nov 19, 2017
Yes please add federation! For me this is the n1 priority! Definitely the github killer feature!
wakawakaeldondolero
commented
Nov 19, 2017
|
Yes please add federation! For me this is the n1 priority! Definitely the github killer feature! |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
labdsf
Dec 6, 2017
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.
labdsf
commented
Dec 6, 2017
|
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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
yookoala
Dec 6, 2017
We may consider "Fork" as a custom "ActivityType" as described by ActivityStreams Vocabs, an ActivityStreams extension.
yookoala
commented
Dec 6, 2017
|
We may consider "Fork" as a custom "ActivityType" as described by ActivityStreams Vocabs, an ActivityStreams extension. |
labdsf
referenced this issue
in go-gitea/gitea
Jan 8, 2018
Open
Support federated pull requests #184
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Skehmatics
commented
Jun 3, 2018
|
Another project that may be of use: https://github.com/go-fed/activity |
yookoala
referenced this issue
in go-gitea/gitea
Jun 4, 2018
Open
Federation for organization, repositories and users #1612
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
yookoala
Jun 4, 2018
Relevant proposal in gitea repository:
go-gitea/gitea#1612
In Gitlab's repository:
https://gitlab.com/gitlab-org/gitlab-ee/issues/4517
yookoala
commented
Jun 4, 2018
•
|
Relevant proposal in gitea repository: In Gitlab's repository: |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
yookoala
Jun 4, 2018
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:
- Allow user to create a Pull Request to a remote upstream Web Repository.
- Allow an upstream Web Repository to receive a Pull Request from a downstream Web Repository.
- 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.
- 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.
yookoala
commented
Jun 4, 2018
•
|
Let's lay down (and discuss) what needed to be done first. TermsGit Service: Web based Git service like Gogs, Gitea, Gitlab. FeaturesFor federation, these are the base line features:
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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
cwebber
Jun 4, 2018
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
cwebber
commented
Jun 4, 2018
|
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 |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
cjslep
Jun 4, 2018
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...)
cjslep
commented
Jun 4, 2018
|
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...) |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
benyanke
Jun 5, 2018
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.
benyanke
commented
Jun 5, 2018
|
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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
yookoala
Jun 5, 2018
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)
- Allow user to create a Fork notification to a remote upstream Web Repository.
- Allow an upstream Web Repository to receive a Fork notification from a downstream Web Repository (not branch specific).
- Allow any agent to subscribe to any Web Repository updates.
yookoala
commented
Jun 5, 2018
•
|
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)
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tobast
Jun 5, 2018
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.
tobast
commented
Jun 5, 2018
|
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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
yookoala
Jun 5, 2018
@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.
yookoala
commented
Jun 5, 2018
|
@cwebber: I plan to draft a specification document in this repository: 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. |
yookoala
referenced this issue
in git-federation/gitpub
Jun 5, 2018
Open
Need to provide a baseline specification #1
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
jaywink
Jun 5, 2018
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
jaywink
commented
Jun 5, 2018
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 |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
21stio
Jun 5, 2018
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?
21stio
commented
Jun 5, 2018
•
|
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? |
EorlBruder
referenced this issue
in git-federation/gitpub
Jun 5, 2018
Open
ask w3c/activitypub how to extend the activitypub protocol #2
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tobast
Jun 5, 2018
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.
tobast
commented
Jun 5, 2018
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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
21stio
Jun 5, 2018
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?
21stio
commented
Jun 5, 2018
•
|
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? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
yookoala
Jun 5, 2018
@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.
yookoala
commented
Jun 5, 2018
|
@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 |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
21stio
Jun 5, 2018
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
21stio
commented
Jun 5, 2018
|
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 |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
yookoala
commented
Jun 5, 2018
|
I'd love to have @Unknwon in the discussion / drafting of the specification. |
Unknwon
removed
the
priority/low
label
Jun 5, 2018
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Unknwon
Jun 5, 2018
Member
@yookoala The idea of gitpub sounds interesting, I would love to implement if we have an open standard.
|
@yookoala The idea of gitpub sounds interesting, I would love to implement if we have an open standard. |
yookoala commentedApr 20, 2017
Description
The elevator pitch would be this:
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
typelike "Fork" or "Pull-request".