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.
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?
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 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).
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 :)
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.
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.
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) :)
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.
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!
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.
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.
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.
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.