Request for Architectural Modification - Decentralized and Federated Gitea


#1

Hey all,

I wanted to know if there was any interest or any effort currently underway to take advantage of the recent deluge of support for decentralized technologies (Twitter becomes Mastodon, as an example). I want to start down the rabbit hole, but before I do, I wanted to make sure I wasn’t reinventing the wheel with respect to Gitea.

Thanks!

nicnicnic


#2

Hello there!

Sounds interesting. I’m an avid Mastodon user myself (well, from time to time really, some periods I slack off more than others), and there are already some issues in regard to making Gitea instances ‘federated’:

While I’m totally cool on making Gitea support federation, I don’t think it is a good idea to shift its aim to have federation in mind. Nevertheless, I’m pretty sure we can support federation well enough without breaking much of the existing infrastructure or doing any particular breaking change.

Thank you for taking interest in this! Looking forward to any contribution :smiley:


#3

I’m really in support of this. What would be needed for having a Github like collaboration experience would be at least having (federated) forking, push/pull and access to the issue tracker (including pull requests).

  1. Forking: This should be fairly easy, since it’s basically a combination of current forking (I think, not sure if gitea does anything overly complex when forking currently) + current mirroring.
  2. Push/Pull: For SSH push/pull, it shouldn’t be too hard to provide some API for remote gitea instances to pull in public ssh keys. For HTTPS push/pull, I’m not sure how the authentication works exactly, but since that uses passwords this is a bit harder, since we definitely don’t want to send our password to a remote instance. IMO it would be fine to just skip HTTPS though, since SSH is better anyway :stuck_out_tongue:
  3. Issue tracker: This is probably not as bad either, if OpenID is set as a dependency for git federation. Just authenticate with that and use the issue tracker as you normally would. Pull requests are a bit harder, since we now have federated forks too, but it shouldn’t be too much work.

Hacking together a solution that does basically work should be doable, and I’d even donate a bit if it’s done, but making it feel good is going to be a really tough UX challenge. On the donation, is there any place where I can donate? Perhaps something like Liberapay?


#4
  1. Forking at the moment does not auto-update the repo, so it would pretty much just be a clone from remote, perhaps adding a link to say “Repo forked from …” on the repo header. But yeah, thanks to Git itself it’s not much of a challenge.
  2. Skipping HTTPS is not an option. Either way, the way I see it right now is that if we want to have federated pull requests, the best way to go is to have some kind of .patch file sent across the network to the “upstream” instance, which will then create a pull request using the base and the branch name specified by the patch. Kind of like email and how patches are made to the Linux kernel, but cooler :sunglasses:.

The biggest challenge seems to be, as you said, to do this correctly in the UX. Forking and making a pull request should be at the very least as seamless as they are now, otherwise the goal is not achieved.

Gitea does not have donations at the moment. Looking through discord, it seems like the issue was not actually really discussed (Liberapay might be a good idea, but this should be discussed thoroughly with owners).


#5

Got a little idea for https pulling/pushing: What if the “home” instance was acting as a proxy, pushing through to the instance where the repository was located? So basically me pushing to https://git.jcg.re/try.gitea.io/someuser/somerepo.git, because my account is on git.jcg.re? This would be kinda not nice because it’s a lot of text, but since most people copy paste the clone URLs anyway, this could actually work.


#6

Yeah, that was what I was thinking as well. But I would definitely not want to implement a system where SSH access is granted to everyone because of a federation protocol, because I can see it going wrong already. So I agree with you, with the proxying mechanism


#7

Forking at the moment does not auto-update the repo

What exactly do you mean by that?


#8

If you fork a repository and make contributions through PRs coming from your fork, it is still your duty (chore) to, every so often, do a git pull upstream master, to ensure that there are no merge conflicts with the upstream. In other words, Gitea will not do git pull upstream master for you, whereas for mirrors, gitea will update them every x hours (12 by default if I recall correctly)


#9

Ahh okay, yeah :smiley:
I didn’t mean mirroring, but the migration feature, got the terminology wrong.


#10

Shall we find a place to start a design document about what we want and how we want it? I’m open to suggestions about hosting, but would want to mandate that there be open collab with versioning.

n


#11

I’ll post this on the chat (#gitea @ freenode) to bring attention to the topic. Also to hopefully get the owners involved, because as much this would be a great thing to do, it’s probably best if we hear from everyone first.


#12

Idea is great but for instances to start communicating with each other there have to be some kind of trust made at first, either repo/org/instance-wise. Also it needs to think out how access to private repos would be granted. But all in all it much looks like that at first gitea needs to become oauth2/openid connect provider and than we could use scopes/tokens etc


#13

I don’t think gitea needs to become an oauth2/openid connect provider. It would make a lot more sense to just split that out to a different component which would be set up next to gitea. To quote @bkc:

If you can setup your own gitea-instance you can setup your own OpenID provider. I really don’t get why Gitea has to be a provider for everything :unamused:

On the trust issue: I don’t think trust is a big issue here. To do anything meaningful, people need to be added as a collaborator, and I don’t see how federation changes this. The only trouble federation might cause (that I can think of right now) is spammers, but that could be handled by blacklisting evil instances.