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