A free and open source solution to sync issues, discussions etc on different platforms, such as GitHub, GitLab, Gitea, Sourcehut and Bugzilla

[KOLANICH]

Project description

It may make sense to bidirectionally synchronize issues and comments in repos on different platforms, but there is no free (as in "freedom") and open source solution for that now, and there is no free (as in "free beer") solution for that too. There are some proprietary solutions:

• https://exalate.com/
• https://unito.io/connectors/github/

Relevant Technology

So called integratin solutions like

• https://github.com/huginn/huginn
• https://github.com/PipedreamHQ/pipedream

should provide the lowest layer, upon which a repo sync solution can be built.

Complexity and required time

Complexity

• Advanced - The project requires the user to have a good understanding of all components of the project to contribute

Required time (ETA)

• Much work - The project will take more than a couple of weeks and serious planning is required

Categories

• Web app
• APIs/Backend
• Developer Tooling
• Bots

[KaKi87]

Who would, as a maintainer, respond to issues on 5 platforms simultaneously ?

[KOLANICH]

The purpose of a syncing solution is syncing. When an issue is posted on 1 platsorm, the syncing solution creates it on all other platforms. When a comment is added to one of platforms, it is replicated to all other platforms. Identifiers are remapped to keep the references on a local platform. When a comment is edited, it is also edited on other platforms. The same for deletions, locks, etc. 5 different platforms essentially become a single platform.

Why to have 5 platforms instead 1 own server with single signon? IDK. I'm pretty sure that the replication solution can be implemented via GitHub Actions and repo hooks, but in this case I guess one has to not to use the integration solutions mentioned and build an own one from scratch centered around event-driven execution.

[KaKi87]

And what would be the purpose of this syncing in particular ?

[KOLANICH]

For redundancy. To allow users not to sign up the platforms they don't want to sign up. For example there is GitHub, which was bought by Micro$oft. So now M$ is in power to do nasty things with it. Not everyone wants to depend on M$. But GH has a large already signed-up audience and this class of services is suspectable to network effects. Network effects mean that benefit of using a service for a user is proportional to count of its existing users. Almost noone will sign-up your custom service just to be able to leave an issue on it. Using single sign-on like OAuth and OpenID can make the count of signed up more, but only in the case when no scopes other than public are requested and when it is very visible that SSO is available.

The sync solution solves the problem by just allowing users to use the platforms they are already signed up. And even if GH does very nasty thing and cuts access to API in future, all the data will be already mirrored, in that case one can just drop GitHub platform with all uts users completely without the loss of the prior data and say to that users "you have to use the alternative platforms to participate to that project". And more the alternative platforms supported, more the probability that a contributor has an account in one of them. Some have accs on GitLab, some have accs on Codeberg, some have accs somewhere else. Those GH users can just use their accs on those platforms, so are not lost as contributors to a project.

[KOLANICH]

ForgeFed protocol can be helpful for syncing, but IRL none of the forges has it working.

[Bessonov]

This is precisely the issue I regularly encounter. When a project utilizes its own instance of GitLab or Jira, creating an issue becomes a nightmare due to the account creation process. If the issue is less than critical, I often choose not to create it. It would be greatly beneficial if issues could be seamlessly synced to GitHub.

[KaKi87]

1. Internet is already a disaster because of people receiving the same spam email every day. Imagine the new disaster that duplicating every git repository on all hosts would be.
2. People who post content on one host agrees for it to be processed by said host, but not for it to be processed by another one.
3. Federation is indeed a much better solution, which AFAIK only the Forgejo team is seriously working on.
4. This brings me to social media, which is the best-known federation implementation so far : see how that solves issues much better than syncing, imagine what an even worse disaster it would be for Facebook and Twitter and Tiktok to sync or something.
5. Refusing to create an account on a project's self-hosted git is refusing independency and therefore promoting big tech, also like refusing to buy food from local farmers and promoting large industries instead, etc.

[KOLANICH]

1. since moderation actions are also replicated it is not a bigger problem than with a single platform
2. your permission is not needed in order to copy and use your texts freely available in the Internet. You may start crying "it's illegal" but noone gives a f*ck. You will have bad luck with prosecuting someone who lives in DPRK, Somalia, having legal immunity, like a high-ranked official of some state, pr just being a big company with a lot of money, like Google, Microsoft or OpenAI. Copyright must be abolished. If you don't want anything being seen or used by other entities - just don't publish it, or use TEE-WEI-based DRM. And then make bug eyes ::eyes:: when it turned out that your content will have 0 (zero) visitors because of that. Platforms promoting vendor lock-in must be boycotted. MS promotes FIDO2 passkeys by discriminating against users not using it, and this is the reason I'm migrating my repos from GitHub and it is likely I'd not be able to use it in a few days. See https://codeberg.org/KOLANICH/Fuck-GuanTEEnomo for more info. Also, GH ToS contain wordings that if a repo contains a license, the content you put there is licensed under it. It is clearly possible to put a license saying that putting any content into a repo you allow everyone in the world to copy, use and modify it. Such licenses are called free licenses. If someone is not into free licenses, he should not use public repos in public forges, which are instruments developed for creating content under free licenses.
3. Federation requires a decision to support it from platform owner and developer and effort to implement and integrate it. M$ GitHub has no incentive to have it. It has the most of users, M$ GH has incentive to lock content to own platform to force people to use M$ GH. Network effects, nothing personal. Small forges have incentives, but these incentives will diminish with forges growth.
4. Those independent platforms demand personal data like email addresses in order to register. Even if they have GitHub SSO, they demand access to profile, and if I deny it by manipulatiin with the address in address line, the majority of them denies access. Also there are own platforms containing the wordings like:

Because of spam, account creation through this form is restricted. If creating an account fails, contact gcc-bugzilla-account-request@gcc.gnu.org to request a GCC Bugzilla account. You should receive a response within 24 hours.

It's a miracle if they have anyone registered there with such attitude to users.

Some other platforms require users to execute malware like Googlag reCAPTCHA, Cloudflare HCaptcha, Fingerprint2.js, or just a picasso-based fingerprinter (Cloudflare has based own one on it).

[KaKi87]

1. I'm not actually talking about risks of spam, I'm only saying that spam consumes email a lot of resources especially considering that almost everyone receive some.
2. So you don't want to create big tech accounts but you want to have them use everyone's data without having an account ? That's bad faith.
3. First part is true, big tech won't federate indeed. But at least, there will be a git Fediverse equivalent that everyone will be welcome to use.
4. So you're comfortable with big tech exploiting your personal data but not with independent developers storing one piece of data that doesn't even have to be linked to your real identity ? That's bad faith as well.

It's a miracle if they have anyone registered there with such attitude to users.

It's easy to criticize them when you're not the one dealing with their issues. I'd like to see you in their position.

[KOLANICH]

1. yeah, it's true. But for now I don't see a lot of spam in forges in general and in this repo in particular. Though it doesn't mean it will be so ethernally.
2. Yes. If I share anything in Internet, I share it to allow people use it (except of my biometrics, I don't share photos, but text modality contains some amount of behavioral biometric info). Sharing content in Internet in order to sue people using it is surely misuse of the Internet.
3. Yeah, fediverse is good. But combination of fediverse and fully decentralized tech is even better.
4. demanding me to provide any piece of data not strictly necessary for operation is extremily entitled. Especially if it is a email. Currently one cannot even get a permanent email address and mailbox with using a phone. They have used a kinda cut-and-choose protocol: if I used a temp address for a forge, then that temp address provider can use it to take over my forge account, so I had to use my email address. So the mere requirement to provide a email is a discrimination against the ones who don't want to provide own phone number to assholes. Fortunately my email address has been registered when no phone verification was required, but they can introduce it any time and deny my access to the acc untill I bind a phone. The company where my mailbox is hosted had done similar tricks multiple times with some minor (and increasingly major, to the point that they have cut IMAP access to the ones who haven't bound a phone) functionality, also it had acquired a company that has done exactly that with own web service (a social network, I have there an account too and can neither sign in nor delete the acc (according to the law I can demand deletion of data, but it would require providing a scan of my ID document to them, it us even worse than providing a phone number to them; and using a service of temporary phone numbers carries legal risks) ), the question is not if it happens, but when. I had to provide my email when signing up to some platforms. It doesn't mean it is a right thing to do. Usually I use temporary emails if I don't value an account and the content in it much. But it is not the case for a forge. My position is that services shouldn't require any credentials other than required for access control (those can vary, it can be a public key for example, or it can be a login and password pair, but a email or a phone is surely not needed for access control, they are needed just to have a database of them).

[KaKi87]

1. I'm not talking about risks of spam on git platforms, I'm saying that if all repos were synced on all platforms then we'd have the same desastrous waste of space issue as email spam because of duplication.
2. Having git platforms process user data coming from another platform, is also misusing the Internet.
3. Fediverse is fully decentralized.
4. ProtonMail, for example of a privacy-friendly provider, doesn't store your phone number when performing human verification.

[NoxideLive]

Ultimately there does not need to be full sync of all issues. In certain cases different teams of a company works on seperate issue trackers such as ZenDesk and proprietary issue loggers from inside their codebases. The potential here could be to consolidate the issues to where they "need to go" by escalating or moving an issue between teams and subsequently platforms. Ideally should be self hosted and possible to setup "routes" and "rules" for issues