#28 Cross instance federation?

I have this https://pagure.io/pagure/issue/2335 open upstream bug and it is hinted to be easy.

With secushare we are moving from gitlab to our own pagure at the moment (which could imply infotropique moving aswell or at least getting a 2nd or 3rd location). I would be open to test this feature with you. Not so much capable in time to code on this, but it is one step closer to git federation without just using the CLI.

The idea of federation is super interesting, the question is "who will get it done"?

I could ask upstream to be more precise about what needs to be done and how one can help?

The problem is that nobody of us is highly familiar with the Gogs source code, therefore adding a feature like this would take a lot of time. It would be better if the Gogs/Gitea/Pagure developers could somehow agree on the way to add federation (for example supporting the same protocol).

I think you are discussing moving to pagure here, at least that was the idea I got from reading the bugtickets. The ticket on pagure.io simply dealt with pagure. I'm not even interested in gogs personally, from a packagers perspective pagure is for my systems more approachable. Of course having one shared protocol would be good, but it's highly optional in my question.

to be clear - there is much misunderstanding expressed here

this repo is not related to either gogs or pagure - some months ago it began as an exploration of moving from gogs to pagure - since then it has been decided that no existing git hosting platform was adequate for the future needs of notabug but most of the existing issues were left open because they are general features that are still desired and we still may use the pagure front-end

instead, a new project has been started to create a new platform with federation as a core hallmark feature by means of a unified federation API that could be implemented by any other git host rather than trying to adapt and retro-fit the disparate APIs that currently exist in gogs, pagure, github, and others - this repo is now for discussion of the next gen notabug 2.0 platform and will be the eventual home of it's web front-end code after the back-end is sufficiently capable

this is not at all to say that notabug will not be able to federate with pagure - the system is designed to be modular and 100% API accessible so that user's could use any server software they choose (e.g. gogs, pagure, or gitweb+redmine) and federate as many or as few of it's features as desired - all that would be required for this to work with pagure (or any other server) would be to implement the communications protocol appropriately for the host environment and create/validate the compatible security tokens - the README of this repo has most of the details

Okay, thanks for clearing that up. I didn't see the connection between the README and these issues before. Now this is interesting! I don't have the time to get involved*, but if I meet people who are willing to work on this would it be okay to send them your way?

* Later on I might have the time, just need to sort out some much more tasks in my main project.

yes plz do - the back-end is written in C and the front-end will be most likely python/flask - as i said, perhaps even a gutted version of pagure - as the system will be fully API-based, the various parts are intentionally orthagonal so it is not necessary for contributors to know everything (both C and python for example) - there is also room for additional clients of any kind that one can imagine (command-line, desktop or mobile GUIs, IRC bot agent)