ForgeFed
forgefed.org
forgefed.org
Forgejo in turn, is a fork of Gitea.
So anyone currently running their own instance of Gitea should consider keeping an eye on Forgejo.
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.
> 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!
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.
Yes, but maintaining my own private instance sucks more than remembering a handful of account credentials.
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.
Maybe I am understanding it wrong: when your instance (inA) federates with inB, doesn't that make inB available to everyone who is federated with inA?
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.
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.
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.
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.
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.
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.
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.
The point is to allow people not using GitHub to contribute easily.
OAuth and ForgeFed solve different, though related, problems.
I understand his reasoning, but there needs not to be a single protocol for federalization. You can support both email and AP and let users choose what is best for them. "Email simply being a better choice" is a controversial opinion (as most of other statements there). Protocols can evolve and compete with each other, but only if software gives them space to do that.
I also don't buy the idea that email is great for all this. It... kinda sucks. He brings up Patchwork; to me, the existence of Patchwork is an acknowledgement that email doesn't work all that well for stuff like this.
Email is by its very nature unstructured. Unstructured data sucks for things like this. And if you're going to define a standard for how this sort of data should be structured over email, then it seems like you might as well use a better protocol than SMTP/IMAP/POP/whatever, that's purpose-built for this use. An ActivityPub extension (regardless of the merits of ActivityPub itself) seems like a much better fit.
Federation (and fediverse) can run on different protocols, by deciding to implement ActivityPub only we are still living in a walled garden of sorts, only this time the bubble is not bounded by a single service provider, but by a protocol and its sphere of reach.
AP is certainly all the rage now, but email-based federation is older and it is already implemented in sourcehut. Do other software forges implement multiprotocol federation? Would they agree to implement email-based federation?
[1]: https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3Cjwvfs5o9e0f.f...
I'm bummed they chose ActivityPub for it, as it's not a great system. That aside, I'm just happy it exists.
Identities independent of account is an important concept, spearheaded by the At Protocol but their design is quite complicated and requires users to own a domain and I'm not convinced (yet) that it'll work in practice.
Mastodon does nothing with many types of ActivityPub and ActivityStreams objects because they don't make sense for what Mastodon is. When you send a Create status for a Polygon or a Service object to Mastodon, there's very little Mastodon can do with all the data you provide it, because that type of object doesn't really make sense. There are uncommon types that could be rendered in a timeline, I suppose, but I hardly expect to see Mastodon render "Sally indicates that Mark is her brother-in-law".
The project would be greatly helped by having more contributors put their eyes over the specs and adding support. Gitlab is working on ActivityPub-based federation [1] and will hopefully become a great reference implementation.
My main concern with ActivityPub right now is operators that are serious about keeping the lights on long-term. I think community-run servers are way better in terms of the ceiling of quality, atmosphere, etc. vs corporate servers and servers ran by VC-funded startups. Having a lot of people posting software on ActivityPub federated instances might not be so bad, though: at the very least, it does offer some natural replication across instances, so presumably anything popular enough would tend to travel around.
I know there's a lot of fervor over whether Mastodon is good or Twitter is good or whatever. I think that right now, today, the "fediverse" as it is is still nascent and far from its full potential. The software is still clunky, there's a lot of inter-instance drama to sort out, etc. I strongly believe, for one thing, that instances and software need to get serious about the overall health of the federation: allowing users to communicate and interact with eachother are more important than instance-related squabbles, so I think discouraging full defederation is important for the fate of the federation long-term. (Importantly, having better tools to solve issues with a less heavy-handed approach would be preferred.)
Even with all of these problems, though... There's just a little glimmer of hope that maybe, the modern web does not have to be so shit. Outside the influence of poorly moderated, massive, corporate-ran social media, there's an undercurrent of a different kind of web. Open networks, real moderation, and even the coveted "nuance" exists, in some small corners. Yes, there's a lot of stupidity too, but the thing about it is, stupidity on massive borderline-unmoderated networks is impossible to avoid. On federated services, it can in fact be compartmentalized to a degree, and if instances really are causing trouble and refusing to moderate themselves, the nuclear option always remains a viable one.
A part of me does wonder if all of these defederated networks just want to be P2P networks but the technology and platform just isn't there today. The most advanced P2P technology I'm aware of is in the IPFS stack, but I'm unconvinced it would be a good foundation to build much on today. One must wonder, though...
Which is still really cool, but there's only a few free pinning services and they don't have a very good UI.
I think what we really need is semi-P2P, everything still hosted on centralized servers, but you can choose more than one and your identity isn't tied to either, and with cache-ability through other servers. Then you can still pay with fiat money, you can still kick individuals off your server, you can still choose to use free youretheproductware, and most importantly you can use community servers without it just being madness to invest too much time.
Either that, or we git-like fork-able and mergable forums with all content creative commons like Wikipedia. Old forums were amazing for community building.
There have been 2 commits about "compilation improvements" this year after 3 years of inactivity. I like the idea of the project, but whether the roadmap will get to AP support... hopefully.
Hey, I fixed some typos, you can pull from `https://example.com/repo.git`, branch `typos`. Cheers!
git pull https://example.com/repo.git typos
The code review part doesn't necessarily need to be web stuff. It also doesn't need to be email patches, because just because it's not web doesn't mean it has to be email. Hopefully these ActivityPub initiatives make it more obvious that this is a false dichotomy, and that pull requests and code review are different things.
Like, for example, maybe my repo is hosted in a cgit instance, but I can review (and respond to) your suggested changes from nvim, and you receive the comments through ActivityPub. Just because I don't publicly display code review comments on my website doesn't mean you can't use Forgejo on your side as usual.
[1]: Though you can leave inline comments in your repo's branch, and I can read them with `git diff` on my side, fix them, do another push, and then you'll see the fixes when you do your next pull.
Git cannot be used in any other way. When you clone a repository, you make a new repository, with references to the previous one that can optionally be interacted with (pull, push, etc).
Unfortunately git hosting and communication related to git repositories (merge requests, issues) have become almost completely centralized over time, but those are mostly outside of git itself, even in the traditional model (HTTP, SMTP).