Really looking forward to seeing Tangled develop! I've got a side project that's main repo and CI is on my self-hosted Gitea but code and releases are mirrored to Github; I'm hoping to move it off Gitea and onto Tangled for code/releases/potentially CI and just keep Github for discoverability/backups/namespace "squatting".
Just need git-bug to add a Tangled bridge so I can keep issues synced and (ideally) for there to be instructions for running the client self-hosted. It doesn't have to be a full featured client but I also don't want to be SOL for web visibility if the main Tangled appview is down.
One musing: I did run into my first "issue" with federated Git hosting the other day while setting up Neovim on a new machine. One of the plugins I use is hosted on Tangled and I guess its backing Knot was down. This was awkward for two reasons:
1. It as unclear to me from the Tangled website the backing knot was the issue (for a while I thought it was something on my end)
2. I really had no backup plans for something like a Neovim plugin's source forge being down and, clearly, neither did the Neovim package manager as it just kept showing an error on every session I started with no way to fix it :).
I suppose in the long run we really shouldn't be assuming that code storage is just Always There or easily cached somewhere, but I anticipate some growing pains in the mean time. ATProto doesn't seem to have the benefit ActivityPub has where if the instance I wanted to view content on was down I can usually find some other instance that's gotten the messages.
> I suppose in the long run we really shouldn't be assuming that code storage is just Always There or easily cached somewhere, but I anticipate some growing pains in the mean time.
Pretty much. We want to make running your own git remotes as easy as possible. Lets you scale on your own too.
> ATProto doesn't seem to have the benefit ActivityPub has where if the instance I wanted to view content on was down I can usually find some other instance that's gotten the messages.
It does give you (or anybody) the ability to index this data independently, and not miss messages -- which AP doesn't afford. Different tradeoffs!
> It does give you (or anybody) the ability to index this data independently, and not miss messages -- which AP doesn't afford. Different tradeoffs!
Someone (or some group) could also in theory go fully content-addressing with their data store, and make content available based on their hash, effectively layering that missing benefit on top of the existing architecture. Someone could probably vibecode this together in some hour(s) :)
> I really had no backup plans for something like a Neovim plugin's source forge being down
this problem could exist with any package manager, the go package manager is one example, where it allows specifying packages from any git url. we host a mirror of all git repositories on our infra, and serve that when the backing knot is down. you could choose to trust that and pull from there (verifying that the tarball has a known correct hash), the way the go package manager pulls from proxy.golang.org.
Ah, I didn't realize the tarballs on the Tangled site were cached. If it happens again I'll try that :)
But yeah I recognize it's an issue for any package manager. I suppose I just forgot that even something like my local editor is reliant on remote forges now unless I go out of my way to mirror it all.
Hi! Tangled co-founder here. We're super stoked with this launch -- we've stabilized our AT Protocol lexicons, completely overhauled our architecture and UI, and made self-hosting the entire stack (or parts of it!) incredibly easy. We've also shipped support for organizations, and have private repos rolling out in the following couple weeks.
I’m excited about this direction. I’ve moved most of my own projects onto my own Forgejo, but miss it being easy for remote strangers to open PRs and such without registering in my system, which I have zero desire to allow.
So what’s the state of Tangled today? Say I have a Tangled server (instance? host?) up and running with my repos. Some stranger wants to contribute. What do they have to do before they can open issues or send PRs or whatever?
That's exactly the problem we want to solve. Of course, they still need identity of some kind -- in this case, they'll need an AT Protocol account -- either by self-hosting a Personal Data Server[0], or signing up with a provider such as Tangled or Bluesky/Blacksky, etc. This is the last ever account they'll need (and it's theirs, and portable!). They can then begin contributing; they'll use this same account for all of Tangled and other AT Protocol services.
Your Tangled git server that you'd want to run is a 'knot'[1]. It's not exactly analogous to Forgejo because it's headless, but that makes it super light on resources to run.
Got it. I'm still trying slightly unsuccessfully to wrap my head around this, but I've run a Mastodon instance for about 10 years and it took me a little while to wrap my head around that, too.
This is great. I'm delighted at the idea of having my own knot hosting my projects, talking to my friend's knot, and coordinating on a global project's knot, all without having to lock everyone into one centralized point of failure (even mine). Amazing. I love it!
all they would need is an atproto account. you can get one of these on Tangled itself, or bring your own. they can then open issues on your repository.
soon, repos will be able to declare a contribution policy: presently its open to all (anybody can open an issue), but owners can choose to limit this to just contributors for example.
How soon will that be, do you suppose? It's not a blocker for most of my projects, but I can think of a few that I'd like to keep more closed (while still making them publicly cloneable). That doesn't keep me from using Tangled today for the open repos. It just means I'd need to have at least a couple of sharing setups - Tangled plus Forgejo - going at the same time for a while.
Also, will Tangled support private repos that are only visible or fetchable to specific people? Would that even make sense in its model?
Tangled looks great, and I may consider self-hosting a knot. But what I am curious about, and what I weigh in such decision, is what your business model is. Right now it isn't clear from the website, so I hope you are perhaps willing to share a bit on that here.
Are there plans to add http(s) support to knot? I was planning on hosting my own knot at home, but didn't want to expose my home IP (I use cloudflared for other services that need to be exposed)
One of my biggest questions about the forged about is what kind of CI (and somewhat CD) do they offer?
What can I expect as a developer using Tangled to build (and deploy) my app? What is the native platform? What are typical other CI systems that have been adapted to work on Tangled (Dagger, Drone, whatnot, especially if there are repos to demonstrate the adaption)? What can I expect as enterprise or lone developer using Tangled or self-hosting or federation?
The system is called Spindle, but what about it? What does it take inspiration from, what are things like it that would help us spool up on this?
Tangled has its own CI named Spindle. However it is not limited to that as there is for example https://tangled.org/mitchellh.com/tack which allows connecting different CIs to Tangled.
> made self-hosting the entire stack (or parts of it!) incredibly easy
Back when you first launched, I thought running a knot was already pretty easy :) Could you expand on how it's different now, and what part(s) aren't now easy to self-host, if there is any?
self-hosting the appview was a bit trickier back then, but we have worked towards making that trivial. it now runs entirely in-memory, and is completely stateless (rebuilds the state of the network from scratch each time).
* I found the UI on the homepage/timeline a bit busy - lots going on. Notifications, Recents, Announcements don't seem like they need to live on this page?
* The Activity chart on a users profile page seems a bit wild to me. I'd suggest simplifying it or just using what GitHub/GitLab use with their square grid activity chart - it's what users are most familiar with. It's kind of analagous to all the LLM/Chat applications in recent years - they all converged on the same UI because that's what works - no need to reinvent the wheel when users understand an existing pattern. Plus - it's better for marketing:- people like to share their activity on GitHub/GitLab as it quickly conveys how much work they've done over the year - your current page doesn't.
I see in the post that lexicon has been finalized. Does that include putting the issue, pr & comment records under the repo scope instead of the user scope?
I am asking because I have been waiting for that change. I intend to make all the public repos from https://juju.bi (code forge I am building) interoperable with Tangled and basically behave as knot server.
Indeed. Repos own issues and pulls now! We will publish a post on how we do this very soon (hint: we store them as git objects within the repository and project them as an AT Protocol MST -- hence making knots PDS-like).
Cloning into 'core'...
warning: redirecting to https://knot1.tangled.sh/did:plc:j5hmlfdrwkvtxm7cjmu7j2is/
remote: Thanks for using knot1.tangled.sh!
remote: Enumerating objects: 99191, done.
remote: Total 99191, done.
Receiving objects: 100% (99191/99191), 122.19 MiB | 39.12 MiB/s, done.
Resolving deltas: 100% (49286/49286), done.
error: invalid path 'localinfra/fixtures/blobs/did:plc:igzuueb63dytyy3tpaweofuu bafkreieify5bix4cmrj4iuxiceb6srr2boltkbbf7yizwtgwurqv42sltm'
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
and retry with 'git restore --source=HEAD :/'
You can inspect what was checked out with 'git status'
It's not a great look when the very first thing I'd want to try to do:
1. Redirects from .org to .sh suspiciously
2. falls over.
I now have to try to work out whether that other domain is deliberate or compromised.
Afaict that's an issue with your operating system, not with tangled's git implementation. You're trying to check out a file with a colon in its name, and Windows can't handle that because of DOS baggage. If you mirrored that to GitHub or wherever and then tried to clone, you'd probably get the same error again.
Try cloning on WSL, in the VM's filesystem, and let us all know how that goes.
Thanks, you've correctly identified the issue, although I wouldn't call it a problem with "my" OS unless it's my configuration.
I just wanted to read the source locally. I know things are getting worse by the month for developers on Windows because other developers are increasingly not giving a shit to support it, but it's odd to have a repo that doesn't even clone on windows.
Not building is common, not passing tests even if it builds is extremely common, but not even cloning is a new one.
I guess eventually I'll give up and switch to linux, but I'm still paid to work on Windows. I guess maybe it's finally time to look into a real dev-container setup for this kind of thing and I can do this all a bit more securely too.
I feel that people still need to support Windows for a while. I for example am stuck on Windows because it (still) has the best accessibility out of all of the operating systems (and Wine is not a replacement for that). It's unfortunate, and I'm hoping it will change in the future.
If it's your configuration, it's not a problem with your OS, it's a problem with your configuration. Your problem is specifically that your OS has chosen not to support certain characters in filenames, and you want to write files containing those characters.
Pre-update, code review UI was horrific compared to GitHub.
Post-update, code review is much better, but "Comments" section without a "Comment" button is unforgivable. People are probably closing PRs right and left without knowing it. Shift-Enter is a submit action.
I'm a keyboard-first user, but for something which can end up in somebody's inbox notifications, UI button is the way to go.
I just don't understand how such a prolific pattern is being ignored.
Not currently, Tangled's data model is entirely built around Atproto, which at least at the moment assumes everything posted is public. There's work in progress at the moment to layer access controlled data on top of that which I think Tangled could use with time though.
we have already got a working demo of private repositories that works very similarly to atproto spaces alpha, but without requiring spaces to be stabilized, we will have something to show off in the next couple weeks :)
For a federated system they sure talk a lot about their struggles around scaling centralized infrastructure. ATProto seems like it's entirely the wrong protocol for this sort of application.
Having worked on it for a while, I now disagree. The permission primitives should be baked in from the start rather than the bolted on after spaces because people continued to ask for these things and eventually Bluesky came around. There are many use cases for permissioned data and experiences that have to be built outside of the protocol, leading to fragmentation and loss of interoperability.
> For a federated system they sure talk a lot about their struggles around scaling centralized infrastructure. ATProto seems like it's entirely the wrong protocol for this sort of application.
Huh that's surprising to hear? What makes you think that? It feels like the whole point of this release is to make it easier to allow people to self host or federate whatever parts they want? That's what I got from their intro/opener!:
> But the centralised forge is crumbling. Relying on someone else for uptime, for features, and to be a good steward of your code hasn’t played out well. What has stood the test of time is email: Git to move the code, and email — an open protocol — to talk about it. At the cost of user experience, however.
> But the centralised forge is crumbling. Relying on someone else for uptime, for features, and to be a good steward of your code hasn’t played out well. What has stood the test of time is email: Git to move the code, and email — an open protocol — to talk about it. At the cost of user experience, however.
> Tangled aims to give you the best of both: the longevity of an open protocol, with the convenience and polish of a proper forge.
> It’s the first truly federated code forge — you can host code on your own servers and still collaborate seamlessly with others. Our approach is pragmatic: self-host just the parts you want, like Git hosting or CI runners, or all of it, including the API server and UI. Whatever you choose, you can still talk to everyone else.
The comment here from @icy emphasizes similar ability to let whomever host whatever parts of this they please:
> Hi! Tangled co-founder here. We're super stoked with this launch -- we've stabilized our AT Protocol lexicons, completely overhauled our architecture and UI, and made self-hosting the entire stack (or parts of it!)https://news.ycombinator.com/item?id=50306205
I don't see any mention of "their struggles around scaling centralized infrastructure". Is that just typical run of the mill low grade slander attack we see against atproto, more reflexive negativity? Or is there some actual interesting point here, that is perhaps even relevant to this tangled release?
They had the mostly-centralized offering up immediately, and now they're spending a lot of time making the parts easier to self-host one by one. What does that say about the protocol? And I assume Tangled also suffers from the general ATProto AppView problem, where your AppView has to consume all the content in the entire network even though 99% of it is likely uninteresting to you.
Code hosting platforms are probably much more disjointed than microblogging platforms, so something like ActivityPub, where servers only keep track of content that users are actually interested in, would make much more sense. It's a shame that the people working on ForgeFed and/or Forgejo federation seemingly aren't making much progress.
I think you fundamentally
misunderstand how the protocol works.
First, Tangled has been entirely self-hostable since the beginning! We've just made it much easier to run for everyone.
Second, the "appview" is simply an indexer. It consumes records from the firehose and only those that it cares about. In our case, those are org.tangled.*. There's no reason we'd consume all of the firehose.
ActivityPub categorically does not make sense here because of how coupled identities are to instances.
> Tangled has been entirely self-hostable since the beginning!
As has BlueSky, as long as you had enough hardware to keep up with the firehose. The protocol heavily lends itself to centralization due to this design. I think this should be obvious by the fact that you haven't considered self-hosting to be the default case.
> In our case, those are org.tangled.*.
I suppose my wording was inaccurate, but this is what I meant by "the entire network". My indexer would have to consume "all of Tangled" instead of the things related to the repos, orgs and people I am interested in. Correct?
> ActivityPub categorically does not make sense here because of how coupled identities are to instances.
I feel like this is more of an inconvenience rather than a dealbreaker. Having to point people to a new account ID on the off-chance you lose your domain seems like much less of a problem than having to deal with ATProto's firehose architecture.
You already could host either the web app, the knot (the repo), or the spindle (the runner) yourself, they were just harder to run yourself. I think it says a lot of good things that you can one by one pick which pieces of the system you want to host where!
It is a social network so I'm not sure what the issue about yes needing to read the network is. There are really good relays designed to help aggregate and filter the network. They can run on $5 VPS, processing the entire network, which is awesomely cheap, not just Tangled, which is awesome, what I would call a huge win. Paul has a talk on designing for scalability, about how it's possible to have such small boxes doing the network aggregation with so little resources, that appviews can then consume their interests from. solving for scale in open social networks, https://youtu.be/BoJnj2yPf14
The servers are definitely not keeping the whole network. The post talks to this some, but the new Knot2 retains a local copy of repo-relevant material (comments prs etc) in its own git tree, that collects what the network has done together, and makes it easy to ship/replicate, while also using that as a sync source to replicate back into atproto too, to make network visible.
Agreed that I really wish ForgeFed were showing much more clear progress. It seems like such a good idea, but it's been a number of years now and it's super murky what the progress is and where we are. Having >1 viable player in the decentralization of forges would be great. I haven't checked in a bit but I do read Forgejo release notes and my impression is it's been a very slow trickle.
> Having >1 viable player in the decentralization of forges would be great.
There are other projects other than Forgejo implementing ForgeFed. Forgejo itself has some federation support but AFAIK not based on ForgeFed. But they have a community contrib project that does.
When you say "they can run on a $5 VPS", do you mean that the entire server will be dedicated exclusively to processing ATProto data? I run an ActivityPub server on my $5 VPS that allows me to interact with everyone else on ActivityPub, and that VPS is hosting a lot more services than just that.
Forgejo was supposed to, but that feature has been in limbo forever. For better or worse, ATProto is easier to implement, because most of the important details of ActivityPub are undocumented compatibility details of implementations like Mastodon (the spec alone isn't very useful for a working, compatible implementation).
AI would make it easier to implement and test complex protocols like this, but the community using Forgejo is mostly against it, which means it'll likely stay in limbo for a long time.
I'm disappointed that issue tracking inside the VCS (probably as a separate repository, or at least a special branch) never got popular. That would reduce the importance of web-based code forges and make moving between them easy.
I would really love to use it but when are you going to support SHA256? I have SHA256 repo and I don’t want to rewrite all history especially when Git 3 is moving to SHA256 anyway.
One musing: I did run into my first "issue" with federated Git hosting the other day while setting up Neovim on a new machine. One of the plugins I use is hosted on Tangled and I guess its backing Knot was down. This was awkward for two reasons:
1. It as unclear to me from the Tangled website the backing knot was the issue (for a while I thought it was something on my end)
2. I really had no backup plans for something like a Neovim plugin's source forge being down and, clearly, neither did the Neovim package manager as it just kept showing an error on every session I started with no way to fix it :).
I suppose in the long run we really shouldn't be assuming that code storage is just Always There or easily cached somewhere, but I anticipate some growing pains in the mean time. ATProto doesn't seem to have the benefit ActivityPub has where if the instance I wanted to view content on was down I can usually find some other instance that's gotten the messages.
Pretty much. We want to make running your own git remotes as easy as possible. Lets you scale on your own too.
> ATProto doesn't seem to have the benefit ActivityPub has where if the instance I wanted to view content on was down I can usually find some other instance that's gotten the messages.
It does give you (or anybody) the ability to index this data independently, and not miss messages -- which AP doesn't afford. Different tradeoffs!
Someone (or some group) could also in theory go fully content-addressing with their data store, and make content available based on their hash, effectively layering that missing benefit on top of the existing architecture. Someone could probably vibecode this together in some hour(s) :)
I do agree that the sweet spot in federated git hosting could be a system merging the features of tangled with the features of radicle
But I have to admit that the design tradeoffs are really different
this problem could exist with any package manager, the go package manager is one example, where it allows specifying packages from any git url. we host a mirror of all git repositories on our infra, and serve that when the backing knot is down. you could choose to trust that and pull from there (verifying that the tarball has a known correct hash), the way the go package manager pulls from proxy.golang.org.
But yeah I recognize it's an issue for any package manager. I suppose I just forgot that even something like my local editor is reliant on remote forges now unless I go out of my way to mirror it all.
Happy to answer any questions at all.
So what’s the state of Tangled today? Say I have a Tangled server (instance? host?) up and running with my repos. Some stranger wants to contribute. What do they have to do before they can open issues or send PRs or whatever?
Your Tangled git server that you'd want to run is a 'knot'[1]. It's not exactly analogous to Forgejo because it's headless, but that makes it super light on resources to run.
[0]: https://atproto.com/guides/the-at-stack#pds [1]: https://tangled.org/docs/knots/self-hosting/
This is great. I'm delighted at the idea of having my own knot hosting my projects, talking to my friend's knot, and coordinating on a global project's knot, all without having to lock everyone into one centralized point of failure (even mine). Amazing. I love it!
soon, repos will be able to declare a contribution policy: presently its open to all (anybody can open an issue), but owners can choose to limit this to just contributors for example.
Also, will Tangled support private repos that are only visible or fetchable to specific people? Would that even make sense in its model?
private repos are coming very soon, we have a working demo of private repositories.
its undocumented at the moment but you push over https as well.
somebody has set up a git credential helper here: https://tangled.org/pds.dad/tangled-core/blob/feature%2Fgit-...
What can I expect as a developer using Tangled to build (and deploy) my app? What is the native platform? What are typical other CI systems that have been adapted to work on Tangled (Dagger, Drone, whatnot, especially if there are repos to demonstrate the adaption)? What can I expect as enterprise or lone developer using Tangled or self-hosting or federation?
The system is called Spindle, but what about it? What does it take inspiration from, what are things like it that would help us spool up on this?
Back when you first launched, I thought running a knot was already pretty easy :) Could you expand on how it's different now, and what part(s) aren't now easy to self-host, if there is any?
https://tangled.org/docs/self-hosting/indexer/
we have also stabilized lexicons, so if you are a selfhoster, you can expect to not require a breaking upgrade!
Some feedback:-
* I found the UI on the homepage/timeline a bit busy - lots going on. Notifications, Recents, Announcements don't seem like they need to live on this page?
* The Activity chart on a users profile page seems a bit wild to me. I'd suggest simplifying it or just using what GitHub/GitLab use with their square grid activity chart - it's what users are most familiar with. It's kind of analagous to all the LLM/Chat applications in recent years - they all converged on the same UI because that's what works - no need to reinvent the wheel when users understand an existing pattern. Plus - it's better for marketing:- people like to share their activity on GitHub/GitLab as it quickly conveys how much work they've done over the year - your current page doesn't.
I am asking because I have been waiting for that change. I intend to make all the public repos from https://juju.bi (code forge I am building) interoperable with Tangled and basically behave as knot server.
Try cloning on WSL, in the VM's filesystem, and let us all know how that goes.
I just wanted to read the source locally. I know things are getting worse by the month for developers on Windows because other developers are increasingly not giving a shit to support it, but it's odd to have a repo that doesn't even clone on windows.
Not building is common, not passing tests even if it builds is extremely common, but not even cloning is a new one.
I guess eventually I'll give up and switch to linux, but I'm still paid to work on Windows. I guess maybe it's finally time to look into a real dev-container setup for this kind of thing and I can do this all a bit more securely too.
Pre-update, code review UI was horrific compared to GitHub. Post-update, code review is much better, but "Comments" section without a "Comment" button is unforgivable. People are probably closing PRs right and left without knowing it. Shift-Enter is a submit action.
I'm a keyboard-first user, but for something which can end up in somebody's inbox notifications, UI button is the way to go.
I just don't understand how such a prolific pattern is being ignored.
Huh that's surprising to hear? What makes you think that? It feels like the whole point of this release is to make it easier to allow people to self host or federate whatever parts they want? That's what I got from their intro/opener!:
> But the centralised forge is crumbling. Relying on someone else for uptime, for features, and to be a good steward of your code hasn’t played out well. What has stood the test of time is email: Git to move the code, and email — an open protocol — to talk about it. At the cost of user experience, however.
> But the centralised forge is crumbling. Relying on someone else for uptime, for features, and to be a good steward of your code hasn’t played out well. What has stood the test of time is email: Git to move the code, and email — an open protocol — to talk about it. At the cost of user experience, however.
> Tangled aims to give you the best of both: the longevity of an open protocol, with the convenience and polish of a proper forge.
> It’s the first truly federated code forge — you can host code on your own servers and still collaborate seamlessly with others. Our approach is pragmatic: self-host just the parts you want, like Git hosting or CI runners, or all of it, including the API server and UI. Whatever you choose, you can still talk to everyone else.
The comment here from @icy emphasizes similar ability to let whomever host whatever parts of this they please:
> Hi! Tangled co-founder here. We're super stoked with this launch -- we've stabilized our AT Protocol lexicons, completely overhauled our architecture and UI, and made self-hosting the entire stack (or parts of it!) https://news.ycombinator.com/item?id=50306205
I don't see any mention of "their struggles around scaling centralized infrastructure". Is that just typical run of the mill low grade slander attack we see against atproto, more reflexive negativity? Or is there some actual interesting point here, that is perhaps even relevant to this tangled release?
Code hosting platforms are probably much more disjointed than microblogging platforms, so something like ActivityPub, where servers only keep track of content that users are actually interested in, would make much more sense. It's a shame that the people working on ForgeFed and/or Forgejo federation seemingly aren't making much progress.
First, Tangled has been entirely self-hostable since the beginning! We've just made it much easier to run for everyone.
Second, the "appview" is simply an indexer. It consumes records from the firehose and only those that it cares about. In our case, those are org.tangled.*. There's no reason we'd consume all of the firehose.
ActivityPub categorically does not make sense here because of how coupled identities are to instances.
As has BlueSky, as long as you had enough hardware to keep up with the firehose. The protocol heavily lends itself to centralization due to this design. I think this should be obvious by the fact that you haven't considered self-hosting to be the default case.
> In our case, those are org.tangled.*.
I suppose my wording was inaccurate, but this is what I meant by "the entire network". My indexer would have to consume "all of Tangled" instead of the things related to the repos, orgs and people I am interested in. Correct?
> ActivityPub categorically does not make sense here because of how coupled identities are to instances.
I feel like this is more of an inconvenience rather than a dealbreaker. Having to point people to a new account ID on the off-chance you lose your domain seems like much less of a problem than having to deal with ATProto's firehose architecture.
It is a social network so I'm not sure what the issue about yes needing to read the network is. There are really good relays designed to help aggregate and filter the network. They can run on $5 VPS, processing the entire network, which is awesomely cheap, not just Tangled, which is awesome, what I would call a huge win. Paul has a talk on designing for scalability, about how it's possible to have such small boxes doing the network aggregation with so little resources, that appviews can then consume their interests from. solving for scale in open social networks, https://youtu.be/BoJnj2yPf14
The servers are definitely not keeping the whole network. The post talks to this some, but the new Knot2 retains a local copy of repo-relevant material (comments prs etc) in its own git tree, that collects what the network has done together, and makes it easy to ship/replicate, while also using that as a sync source to replicate back into atproto too, to make network visible.
Agreed that I really wish ForgeFed were showing much more clear progress. It seems like such a good idea, but it's been a number of years now and it's super murky what the progress is and where we are. Having >1 viable player in the decentralization of forges would be great. I haven't checked in a bit but I do read Forgejo release notes and my impression is it's been a very slow trickle.
There are other projects other than Forgejo implementing ForgeFed. Forgejo itself has some federation support but AFAIK not based on ForgeFed. But they have a community contrib project that does.
- https://codeberg.org/forgejo-contrib/federation
- https://codeberg.org/activitypub-rs/activityforge
- https://frogue.vit.am/~ololduck/Frogue
Gitlab has a community epic to add ActivityPub support, but that needs contributors:
- https://gitlab.com/groups/gitlab-org/-/work_items/11247
AI would make it easier to implement and test complex protocols like this, but the community using Forgejo is mostly against it, which means it'll likely stay in limbo for a long time.
At this point it's really the only forge I want to use going forward, considering that it sits nicely alongside all my other social data with ATProto.