I'm looking forward to this. As of now, if you want to contain development of your software to your personal gitea instance, you are actually raising the complexity for new contributors, as they have to create a new account on your instance to create issues and pull requests. This is even worse if the instance is with closed registration and others are not supposed to create accounts there.
Note that Forgejo is specifically planning on contributing ForgeFed upstream when they're done:
> We're planning on merging federation into Forgejo first, then upstreaming it to Gitea.
There are other reasons to switch to the fork, but I think you'll get ForgeFed either way, which is as it should be. The more participation in the protocol the better!
How split is the community over this? I had front row seats to the gogs vs gitea split and it was clear that gitea had the upper hand when it came to momentum there. Is there a similar consensus now?
My impression is that Forgejo is at this point mostly a "swap the names" fork, along with a few features that Gitea dropped the ball on like ForgeFed. At the same time, Gitea has developed some pretty big enhancements to CI in that time so there's definitely a lot more development going on in Gitea.
The largest hosted instance, Codeberg has thrown in behind the Forgejo fork, which is the largest endorsement it has, but I think a lot of smaller instance operators are either continuing with Gitea or adopting a wait and see approach.
I think the real test for Forgejo is how sustainable it will be once the codebases diverge to the extent that it can't just rebase on Gitea for the feature work Gitea does.
> The plan is to stay close enough for that not to happen, at least that’s how I understand it.
That's a shame. I have no interest in CI and other "enterprise-y" features and was hoping to side-grade to Forgejo. I run my instance on an Raspberry Pi Zero and my non-latest version of Gitea is a memory-hog as it is. I'll be giving Gogs another look.
Before I learned about that I usually dismissed Forgejo as an unimportant fork which will die off pretty quickly, but support of ForgeFed makes me seriously consider migrating from Gitea. I still believe that Gitea's org strategy is the right one in the long run, however.
Until you say a naughty word on some forum, and Google bans your account and you cannot log in anywhere.
Or you say a naughty word on some forum and Microsoft bans you, so your GH account gets closed, your xbox stops working and you have to wipe Windows and install Linux and hope like hell that you have a local copy of all your 365 docs.
Far fetched? Maybe it is, but I feel less anxiety by having separate accounts everywhere.
If you're afraid of Google and Microsoft, you don't need to create a Google or Microsoft account with federated websites.
It's not like Google or Microsoft are ever going to bother with ForgeFed or any other type of ActivityPub for that matter. They would totally drop email if they could convince their customers to exclusively communicate through Teams/GChat.
For federated protocols, you can run your own server, or use a medium sized hosted service. If this gets merged upstream into Gitea eventually, you could use Codeberg or one of the many other Gitea servers out there.
If you want to deal with a million accounts, you can. There's nothing stopping you from registering accounts for every service you use even if this takes off and everyone else moves on to federated services.
> If you want to deal with a million accounts, you can. There's nothing stopping you from registering accounts for every service you use even if this takes off and everyone else moves on to federated services.
I apologise for any confusion; I wasn't contending that ForgeFed would prevent me from using individual accounts, I was contending the statement
> What happened is that it massively sucks.
IMO, it doesn't. It sucks, but not massively so!
Maintaining individual accounts across, maybe, six or seven providers[1], does indeed suck, but not massively so, and not enough to go to the trouble of maintaining my own instance within a federated system.
[1] I will probably never have anywhere close to a million individual accounts at code-hosting providers, even if it were federated. There will also never be more than a handful of providers where 99.9% of everyone goes.
As we've seen again, and again, and again ... any distributed system (like cryptocurrency exchanges, federated social networking, etc) slowly consolidates into three, maybe four places that get almost all the traffic/users.
It becomes centralised.
Is there any reason you think that this time, with ForgeFed, it will be different?
Federated systems are a technical solution to a social problem, which is why it always fails - i.e. results in centralisation eventually. If you have any examples where the result truly is normally distributed amongst all the instances I'd really like to see that.
> [1] I will probably never have anywhere close to a million individual accounts at code-hosting providers, even if it were federated. There will also never be more than a handful of providers where 99.9% of everyone goes.
I think we're talking past each other. I celebrate the move towards federated systems because if done right I won't need accounts on a bunch of individual systems. Unlike today where I do have individual accounts on multiple different code hosting sites.
> Is there any reason you think that this time, with ForgeFed, it will be different?
It's irrelevant to me if 99% of users are on a single ForgeFed instance as long as it's still federated so I don't need to be there if I don't want to but can still interact.
ActivityPub support also means that even if they do nothing to provide easy migration, spidering all the relevant content to move it elsewhere if a dominant ForgeFed instance goes rogue is easy.
> It's irrelevant to me if 99% of users are on a single ForgeFed instance as long as it's still federated so I don't need to be there if I don't want to but can still interact.
Only if you're running your own instance, otherwise you're at the mercy of whoever's instance you are on: if they decide to cut off some other instance for whatever reason, then, no, you won't see that other instance without running your own instance.
And if you do federate with rogue instances, your own instance will be rejected from the popular ones anyway.
It's a social problem, not a technological one, so you get all the downsides of centralisation with none of the upsides.
> Only if you're running your own instance, otherwise you're at the mercy of whoever's instance you are on: if they decide to cut off some other instance for whatever reason, then, no, you won't see that other instance without running your own instance.
And if I sign up to individual servers, they could ban me. There are risks in every model, but unlike in a centralised model, with a federated system I get to choose along a wide spectrum with respect to which risks I'm prepared to take. I could just sign up to the dominant server if I'm comfortable with that. I can pay someone to run an instance for me, I can run my own, I can find an instance run by someone I trust. The worst case is that I get the same upsides and downsides as in a centralised system.
> It's a social problem, not a technological one, so you get all the downsides of centralisation with none of the upsides.
To me this notion that there are upsides is comical, because of the above. I get choice. That's an upside. For my Mastodon setup I opted to run my own private instance because it gives me a level of control of the interface, and who I federate with and a number of other things that I don't get from the big instances. For Lemmy, I couldn't be bothered, because it's not (for now anyway) important enough. For ForgeFed, who knows, we'll see. But unlike with a centralised system, when I make that choice I don't choose away communication with all of those on other instances.
So to me, it is strictly better, and your hypotheticals are irrelevant because my worst case is to go back to the centralised model and register an account with a dominant instance.
The premise of ForgeFed is that you'd have one account but that one account would not need to be under the control of a corporation, you could have a private instance that you used interact with all open source software projects.
> The premise of ForgeFed is that you'd have one account but that one account would not need to be under the control of a corporation, you could have a private instance that you used interact with all open source software projects.
Yes, but maintaining my own private instance sucks more than remembering a handful of account credentials.
You don't need to. You get the choice. So if you want separate accounts on multiple sites, nobody stops you. If you want to run your own, nobody stops you. If you want to trust a given instance nobody strops you.
But likewise, if you don't want to trust provider A, but do trust provider B, nobody stops you *even if you want to interact with projects at provider A.
ActivityPub instances can relay messages, but generally they don't unless it's a dedicated relay that instances have to specifically sign up to receive messages from. Most instances are not subscribed to any relays, but only receives messages addressed to at least one user on that instance.
2FA, for one. The only time I created an account and someone's dedicated GitLab instance, they had mandatory 2FA enabled, which is a lot of hassle to just be able to submit an issue.
Most of the point of running your own Gitea instance is to help move FOSS away from GitHub's stranglehold. A proper federation protocol for the decentralized alternatives would be far more useful for that goal than enabling GitHub OAuth.
Look, I'm aware of the point of Gitea/etc. I also don't really care.
I want people to be able to easily contribute so they don't give up and just go back to GitHub. OAuth with a GitHub access level solves this, full stop.
A proper federation protocol is correct and the right option long term but there is no need to knock what actually works right this moment. Doing the right option often takes far longer than is ideal.
I host a number of services for me and close friends and family, and I limit the access by manually creating accounts for them. I could enable OAuth via 3rd party service, but that would mean I'll have to pay much more attention to setup of ACLs, as these users will have a new account created for them with a link to their Github account.
Besides, I want to stay more or less independent from 3rd party services, particularly I'm bothered by the need to explicitly register an OAuth client. AP has a much better flow in that regard, services can interoperate without a given permission to do so.
