This is a really cool project and I’ve been following it for awhile. I’m also keen on breaking up the code forges monopolies.
I’ve been dipping my toes into this space mainly because I think code forges as they exist are trying to solve multiple problems at the same time. I think there’s value in splitting this functionality up into discrete services.
For example, most forges: host your git repo, web view, collab tool, ci/cd pipeline, and task management.
I don’t see why these necessarily need to be bundled together.
For example, as long as we are comfortable not having direct access to the git repo, we can have a purely static web viewer for git: https://pgit.pico.sh
For collab, as long as we are comfortable sharing patchsets and reviewing locally, we can have a collab server that doesn’t need a git repo in order to function: https://pr.pico.sh
Then self hosting your own bare git repo on a VPS is trivial.
Git is already decentralized, centralizing it because all the other services require it is the anti pattern
If multiple services have multiple owners it becomes also a question of trust. You either validate one service that fits 80% of your requirements, or validate ten services where each solves one specific requirement.
Also, of course - economy of scale for the infrastructure / integrations between features. Monoliths are still a thing.
But yeah, I agree developer experience may be traded here.
Git was really useful because it allowed decentralization but didn’t require it like CVS or SVN. It catered to the “just clone the repo and create a new branch when you hop on the airline and push updates to origin when you land” model. But it’s really unusual that people really want a hugely distributed model. Typically, people want to go to The Blessed Repo and get The Blessed Code. For example, Linus’s got kernel tree is more important than everyone else’s clone.
It is trivial to set up a VPS with a git remote. Access it with ssh. Done. Git clone fred@fooda.com:/hubs/frog gets you hopping instantly.
I think the issue behind the curtain (attempt at an obscure reference to the wizard of oz) is lock in. And why is lock in such an issue all around us? Why is github so completely focused on lock in rather than service? Behind the curtain of lockin is funding. Paying for it. A business model.
Maybe centralization => lockin => money? Like gmail. Like github. Etc.
If you have no business model for service => money (and we do not!) then this is what you get.
While there may be no technical reasons why these functions need to be bundled together in a forge, there may still be economic reasons (can’t support development as a standalone function) and usability reasons (people want it to arrive “batteries included”). The counter might be “open source proves this can work because people ignore the economics there, too,” but remember that most open source projects die with a single maintainer and the most successful ones have some sort of corporate patrons contributing sponsorship money, engineers, etc.
I see you hand waved people who pay money so that forges can operate.
If you have a company you don’t want to pay 20 invoices to different vendors.
If you have a company you don’t want to deal with debugging integration between your CI/CD and web view and git providers, you want to make a ticket and have it fixed.
When you are developing a project you don’t want to spend time figuring out which task management will integrate with other parts.
As a developer you also don’t want to jump through 5 different tools and waste time you want integrated and streamlined experience.
Git being decentralized doesn’t have value besides the fact that I can have my local copy and work on it separately from whatever is there on the central server my company uses.
Inevitably someone will end up paying for Tangled. Their architecture demands an infrastructure piece that actually hosts the forges and PDSs through BlueSky won't always be free. They're also non-trivial to run.
A PDS is just a docker image of a TS node app w/ sqlite that can run on effectively no hardware at all (someone got one running on a microwave once upon a time).
A relay is also fairly trivial to set up and can be orchestrated via docker I believe. You can run them on a raspberry pi as long as you have a half decent internet connection.
The tangled appview runs on a single machine w/ like 4 cores and a few gigs of ram.
You can run a knot (git host for tangled) on pretty much any hardware.
And a spindle (CI runner for tangled) on anything that meets the requirements for your CI ops.
It's multiple moving parts which increases complexity but IIRC they also all have nix flake support as well so orchestrating all of the moving parts together via nix is increasingly trivial.
The infrastructure to host the forges is still a problem yes, but PDSes are VERY trivial to run, they’re just a Node.js app and they have a Compose file to make running it a quick shell script to run. And they will always be free, Bluesky is well aware that making access to the platform a paid thing would kill the project outright, and even then the code is open source and in the process of being written up as an RFC, so… please fact check your comments before posting :)
Regardless that increases the barrier to entry for the median developer compared to e.g. Github. In any case, there are several other providers for PDSs coming up and infra is one of the hot areas in the atproto community
We recently shipped a change to switch out our OAuth library—which introduced a regression, preventing new users from being added to the default knot and spindle (the git hosting server & CI runner). We just discovered this and pushed a fix—please log out and log back in again and you should be able to create repositories!
First Question: is it possible to change your handle or delete your account on the tngl.sh PDS instance?
Second Question: how much resource does creating and hosting a new AppView entail? For example let's say I make an appview that's essentially the PDS-hosted equivalent of Cloudflare Pages, where a user upload a folder of a static website and the appview just forwards it verbatim at a hypothetical https://atprotocities.org/@cool.guy/... , would you need to bear the brunt of the traffic cost as an AppView host?
Cool product! Knowing a little bit of AT protocol, I can assume that the expression you used, “social-enabled”, is related to that. Does Tangled have plans for more social features or social-enabled simply means AT protocol?
We definitely want to be very social-first down the line! Our focus at present is to nail the core features first, however. The vision is to build Tangled to be a indie/community-focused code forge.
Yeah this thing has actual support for stacked PRs which Github has somehow failed to do for decades. If I ever need some self hosting thing I'll definitely check this out.
My only hesitation is that I'd want it for private use in a company, and it isn't clear to me how to avoid connecting your Tangled instance to the rest of the public network.
Github is no longer a trusted nor a reliable platform. Moving at least the oss stack to atproto (or any other open network) is an excellent way to safeguard it against Big Tech, Government censorship etc. Love to see this.
I'm increasingly becoming convinced that atproto is pointless. Federation is good, but this idea of implementing "take everything with you" at the protocol level is unnecessarily complicated and centralizing. With Bluesky it might make a little more sense, but with Git? So many better, easier options here. Archive your repo and a) learn how to the do the real decentralized thing OR b) make your own centralized thing OR c) just move to Gitlab or similar.
"Take everything with you" is just downstream from "find or be a trustworthy node."
What’s the “real decentralised thing”? You can already archive your repo—Tangled doesn’t prevent that.
AT Protocol is great for when you’re working with the data surrounding your code: issues, pulls etc. which are much harder to move around, or even just archive from GitHub.
Case in point: Gitea (ironically), they’re stuck on GitHub because their 30k+ issues and PRs cannot be migrated from GitHub due to API rate limits.
I was in the first ~100 users to sign up for tangled after seeing that they were roadmapping stacked patch style pull request review and being generally impressed with how quickly they were building and shipping features all off the excitement from a budding community in the world of atproto. I am very excited to see where this goes and how they continue shipping.
There are a lot of opportunities here that could be levered to offer much better experiences and fundamental control and long term viability if they continue to execute this way.
I really like the idea of more decentralized git collaboration. What do people think are the biggest blockers to adoption in this space? Having to run a server or manage some kind of private keys? Is it purely network effect?
Spam, illegal content, and moderation in general. How do you protect against new account spam when any domain could be a PDS and any PDS could host an arbitrary number of users? What do you do about people stuffing ebooks and TV shows in git repositories? If a project is getting piled on with all its issued spammed because of political views of the repo's maintainer, is this considered a problem, and if so how is it fixed?
The advantage of an AppView is that, like BlueSky, you can actually have a central moderation team and consistent moderation policy. Even if people post whatever they want on their own PDS it is possible to curate what people normally see. However, even though I avoid following the drama I can see that the BlueSky moderation team is constantly under fire for some decision or other. Choose your poison.
Nowadays I don't have the appetite for fully decentralised public networks and all the responsibilities and problems they bring. It's nice that AT's content is completely open compared with something like Twitter, but it's so helpful that the day-to-day administration is centralised when you want an authority to appeal to without ending up with the quagmire of "defederation".
A question to ponder: is anyone here going to volunteer to run a "permissive" radicle seed node? (i.e. providing storage and access to arbitrary git repos uploaded anonymously)
But doesn't the decentralized firehose make it easy to build curation? You decide what/whom you want to subscribe to---rest of social media be damned. Why do you care what unmoderated crap is flooding the world outside your cosy corner?
And if you choose to receive a broader sampling, you can subscribe to someone who will curate it for you---either manually, or through algorithms. It seems like an elegant way to have a web-of-trust layer for curation, composed with an algorithmic curation layer---and be able to tune the latter separately to suit user needs, without being beholden to the interests of the platform operator. You can easily switch your subscriptions if you don't like the way someone is curating it, without wholesale losing access to the network!
> A question to ponder: is anyone here going to volunteer to run a "permissive" radicle seed node?
Doesn't opening up curation+subscription solve this problem too? Anyone can curate in opinionated ways, and offer to "host" whatever they are okay with accepting responsibility for (at whatever level of endorsement, so long as it is clearly communicated) and users have the choice to subscribe.
The problem today is that curation is tangled with access to the network, so you're forced to accept the curation provided to you by the owner of the walled garden (and incentives are misaligned)
AtProto does have platform and user managed labelers for the moderation piece, so it's at least built into the protocol. The jury is still out on how well that concept will scale.
Sure, you can mooch off their centralized server for a while. In an actually decentralized network there have to be multiple servers which cost money to run and that money is never recouped.
Tangled very nicely gets rid of the having to run a server problem, yet still gives you a sovereign platform for doing git from. Truly divine.
The barrier is largely that Tangled is so new. People don't know about it. People don't know what Bsky & the Personal Data Server offer or they haven't been enticed out of the zero energy local minima.
There's some need for more features. For more tangled dev. Ideally for alternate clients, just because. But it's already enormously solid, the early adopters are living the better life, the future is already here and we are just waiting for devs to redistribute themselves appropriately.
Hi! Knots just serve up git repositories over an XRPC API. The actual state on disk is really just a sqlite + your git bare repositories—the two can be tarballed and moved elsewhere easily!
We will work on more first party backup/migrate solutions though.
Git repos don't get replicated anywhere. They live on disk, either on our knot server or yours. Knots are essentially our extension to the AT architecture, allowing user ownership of what's essentially "off-protocol data" (git).
I was pleased to see that this has CI pipeline support, but am saddened to see that it looks roughly GitHub-actions shaped.
I don't see the point in writing a sequence of serial steps in YAML. A bash script can already do that. YAML configuration for pipelines should be focused on expressing the dependencies of a DAG, not the serial execution of a program.
Why not improve upon https://radicle.xyz? It's been running for a while now with promising future. From my naive understanding of running a radicle node, it consumes around 40G of storage for the current network of 5k repos
The social factor. As someone who is very active on Bluesky, the social inertia of Tangled is great. I like Radicle too, but it's harder to collaborate with people, because it's harder to sell to people.
I am obliged to use a public GitHub org for work. Is it “blessed path” to try do the CR part in tangled and sync back to GitHub? I would love to profit from my nice jj habits at the review stage!
Looks cool but I would really like to have this as a mirror of my local git repo server. If tangled goes down or my internet goes I won't be able to work.
Nothing preventing that! You can run a knot server[0] on top of your local git server—which I assume you push to using SSH. Knots serve up your git bare repos over an API (and federate over AT Protocol).
If Tangled’s appview is down, you can still access your own box as you would. Alternatively, you can mirror using git natively by simply adding a push-only remote.
Think of these as names of tables (or collections) in a distributed database. Or as type definitions. Or as app-defined data formats.
Each lexicon is a schema for a model. So you’re looking at a list of such “types” — a “repo”, a “follow”, a “star” etc.
There’s a “Tangled repo” lexicon, a “Bluesky post” lexicon, a “Leaflet publication” lexicon, and so on. Lexicons are specified and evolved by developers of each concrete application. Other apps can use those type definitions to read or write that kind of data.
The UFO tool samples the global event stream and keeps stats on which lexicons are showing up in it (i.e. types of JSON that are being created on the network). You can expand the “samples” tab to show a few concrete JSON blobs so you get the idea of what the data represents.
The fact that all the data is open means not only that you could plausibly exit to other providers and keep all your projects data, (issues, prs, etc), but also that it's dramatically easier to build other tools that work on that same data. Triage, labelers, bots, etc, I know these are all possible on GitHub today with their API, but I think the programming model of ATProto removes a lot of friction in building and composing them.
I think there is a sort of thing built on top of Git where the wiki and issues are actually part of the repo itself, I forget the name, a bit like the Fossil SCM.
The forges aren’t decentralized though (barring bits like Sourcehut pushing for email patch workflows). Thats part of what ATP is potentially helping to solve for here.
This is a really cool project and I’ve been following it for awhile. I’m also keen on breaking up the code forges monopolies.
I’ve been dipping my toes into this space mainly because I think code forges as they exist are trying to solve multiple problems at the same time. I think there’s value in splitting this functionality up into discrete services.
For example, most forges: host your git repo, web view, collab tool, ci/cd pipeline, and task management.
I don’t see why these necessarily need to be bundled together.
For example, as long as we are comfortable not having direct access to the git repo, we can have a purely static web viewer for git: https://pgit.pico.sh
For collab, as long as we are comfortable sharing patchsets and reviewing locally, we can have a collab server that doesn’t need a git repo in order to function: https://pr.pico.sh
Then self hosting your own bare git repo on a VPS is trivial.
Git is already decentralized, centralizing it because all the other services require it is the anti pattern
If multiple services have multiple owners it becomes also a question of trust. You either validate one service that fits 80% of your requirements, or validate ten services where each solves one specific requirement.
Also, of course - economy of scale for the infrastructure / integrations between features. Monoliths are still a thing.
But yeah, I agree developer experience may be traded here.
"Git is already decentralized"
Decentralized is a big word.
Git never tackled the decentralized aspect, being served over a master-slave protocol like HTTP means you have a tendency to centralize it again.
Git was really useful because it allowed decentralization but didn’t require it like CVS or SVN. It catered to the “just clone the repo and create a new branch when you hop on the airline and push updates to origin when you land” model. But it’s really unusual that people really want a hugely distributed model. Typically, people want to go to The Blessed Repo and get The Blessed Code. For example, Linus’s got kernel tree is more important than everyone else’s clone.
This!!
It is trivial to set up a VPS with a git remote. Access it with ssh. Done. Git clone fred@fooda.com:/hubs/frog gets you hopping instantly.
I think the issue behind the curtain (attempt at an obscure reference to the wizard of oz) is lock in. And why is lock in such an issue all around us? Why is github so completely focused on lock in rather than service? Behind the curtain of lockin is funding. Paying for it. A business model.
Maybe centralization => lockin => money? Like gmail. Like github. Etc.
If you have no business model for service => money (and we do not!) then this is what you get.
[Edit: "funding" => "is funding"]
While there may be no technical reasons why these functions need to be bundled together in a forge, there may still be economic reasons (can’t support development as a standalone function) and usability reasons (people want it to arrive “batteries included”). The counter might be “open source proves this can work because people ignore the economics there, too,” but remember that most open source projects die with a single maintainer and the most successful ones have some sort of corporate patrons contributing sponsorship money, engineers, etc.
I see you hand waved people who pay money so that forges can operate.
If you have a company you don’t want to pay 20 invoices to different vendors.
If you have a company you don’t want to deal with debugging integration between your CI/CD and web view and git providers, you want to make a ticket and have it fixed.
When you are developing a project you don’t want to spend time figuring out which task management will integrate with other parts.
As a developer you also don’t want to jump through 5 different tools and waste time you want integrated and streamlined experience.
Git being decentralized doesn’t have value besides the fact that I can have my local copy and work on it separately from whatever is there on the central server my company uses.
Inevitably someone will end up paying for Tangled. Their architecture demands an infrastructure piece that actually hosts the forges and PDSs through BlueSky won't always be free. They're also non-trivial to run.
A PDS is just a docker image of a TS node app w/ sqlite that can run on effectively no hardware at all (someone got one running on a microwave once upon a time).
A relay is also fairly trivial to set up and can be orchestrated via docker I believe. You can run them on a raspberry pi as long as you have a half decent internet connection.
The tangled appview runs on a single machine w/ like 4 cores and a few gigs of ram.
You can run a knot (git host for tangled) on pretty much any hardware.
And a spindle (CI runner for tangled) on anything that meets the requirements for your CI ops.
It's multiple moving parts which increases complexity but IIRC they also all have nix flake support as well so orchestrating all of the moving parts together via nix is increasingly trivial.
The vast majority of this comment is false, btw
The infrastructure to host the forges is still a problem yes, but PDSes are VERY trivial to run, they’re just a Node.js app and they have a Compose file to make running it a quick shell script to run. And they will always be free, Bluesky is well aware that making access to the platform a paid thing would kill the project outright, and even then the code is open source and in the process of being written up as an RFC, so… please fact check your comments before posting :)
Regardless that increases the barrier to entry for the median developer compared to e.g. Github. In any case, there are several other providers for PDSs coming up and infra is one of the hot areas in the atproto community
> I don’t see why these necessarily need to be bundled together.
They don't need to be, but it's very convenient.
There is stagit as well, but it does not support branches:
https://codemadness.org/stagit.html
Does Pgit support branches?
Yes it lets you generate a tree for any revision
Hey HN, co-founder of Tangled here!
We recently shipped a change to switch out our OAuth library—which introduced a regression, preventing new users from being added to the default knot and spindle (the git hosting server & CI runner). We just discovered this and pushed a fix—please log out and log back in again and you should be able to create repositories!
Otherwise, happy to answer any questions!
First Question: is it possible to change your handle or delete your account on the tngl.sh PDS instance?
Second Question: how much resource does creating and hosting a new AppView entail? For example let's say I make an appview that's essentially the PDS-hosted equivalent of Cloudflare Pages, where a user upload a folder of a static website and the appview just forwards it verbatim at a hypothetical https://atprotocities.org/@cool.guy/... , would you need to bear the brunt of the traffic cost as an AppView host?
Since its just a regular ol' PDS, you can simply login to Bluesky and change it there!
Cool product! Knowing a little bit of AT protocol, I can assume that the expression you used, “social-enabled”, is related to that. Does Tangled have plans for more social features or social-enabled simply means AT protocol?
We definitely want to be very social-first down the line! Our focus at present is to nail the core features first, however. The vision is to build Tangled to be a indie/community-focused code forge.
Learned recently about their support for Jujutsu at JJ Con last week: https://blog.tangled.org/stacking
Yeah this thing has actual support for stacked PRs which Github has somehow failed to do for decades. If I ever need some self hosting thing I'll definitely check this out.
My only hesitation is that I'd want it for private use in a company, and it isn't clear to me how to avoid connecting your Tangled instance to the rest of the public network.
Github is no longer a trusted nor a reliable platform. Moving at least the oss stack to atproto (or any other open network) is an excellent way to safeguard it against Big Tech, Government censorship etc. Love to see this.
But nobody will pay for his own servers. Big OSS orgs might, but you cannot even provide PR's other than by email.
> but you cannot even provide PR's other than by email
Are you referring to Tangled? If so, that’s patently false.
That was the right way from the start
I'm increasingly becoming convinced that atproto is pointless. Federation is good, but this idea of implementing "take everything with you" at the protocol level is unnecessarily complicated and centralizing. With Bluesky it might make a little more sense, but with Git? So many better, easier options here. Archive your repo and a) learn how to the do the real decentralized thing OR b) make your own centralized thing OR c) just move to Gitlab or similar.
"Take everything with you" is just downstream from "find or be a trustworthy node."
What’s the “real decentralised thing”? You can already archive your repo—Tangled doesn’t prevent that.
AT Protocol is great for when you’re working with the data surrounding your code: issues, pulls etc. which are much harder to move around, or even just archive from GitHub.
Case in point: Gitea (ironically), they’re stuck on GitHub because their 30k+ issues and PRs cannot be migrated from GitHub due to API rate limits.
I was in the first ~100 users to sign up for tangled after seeing that they were roadmapping stacked patch style pull request review and being generally impressed with how quickly they were building and shipping features all off the excitement from a budding community in the world of atproto. I am very excited to see where this goes and how they continue shipping.
There are a lot of opportunities here that could be levered to offer much better experiences and fundamental control and long term viability if they continue to execute this way.
I really like the idea of more decentralized git collaboration. What do people think are the biggest blockers to adoption in this space? Having to run a server or manage some kind of private keys? Is it purely network effect?
Spam, illegal content, and moderation in general. How do you protect against new account spam when any domain could be a PDS and any PDS could host an arbitrary number of users? What do you do about people stuffing ebooks and TV shows in git repositories? If a project is getting piled on with all its issued spammed because of political views of the repo's maintainer, is this considered a problem, and if so how is it fixed?
The advantage of an AppView is that, like BlueSky, you can actually have a central moderation team and consistent moderation policy. Even if people post whatever they want on their own PDS it is possible to curate what people normally see. However, even though I avoid following the drama I can see that the BlueSky moderation team is constantly under fire for some decision or other. Choose your poison.
Nowadays I don't have the appetite for fully decentralised public networks and all the responsibilities and problems they bring. It's nice that AT's content is completely open compared with something like Twitter, but it's so helpful that the day-to-day administration is centralised when you want an authority to appeal to without ending up with the quagmire of "defederation".
A question to ponder: is anyone here going to volunteer to run a "permissive" radicle seed node? (i.e. providing storage and access to arbitrary git repos uploaded anonymously)
But doesn't the decentralized firehose make it easy to build curation? You decide what/whom you want to subscribe to---rest of social media be damned. Why do you care what unmoderated crap is flooding the world outside your cosy corner?
And if you choose to receive a broader sampling, you can subscribe to someone who will curate it for you---either manually, or through algorithms. It seems like an elegant way to have a web-of-trust layer for curation, composed with an algorithmic curation layer---and be able to tune the latter separately to suit user needs, without being beholden to the interests of the platform operator. You can easily switch your subscriptions if you don't like the way someone is curating it, without wholesale losing access to the network!
> A question to ponder: is anyone here going to volunteer to run a "permissive" radicle seed node?
Doesn't opening up curation+subscription solve this problem too? Anyone can curate in opinionated ways, and offer to "host" whatever they are okay with accepting responsibility for (at whatever level of endorsement, so long as it is clearly communicated) and users have the choice to subscribe.
The problem today is that curation is tangled with access to the network, so you're forced to accept the curation provided to you by the owner of the walled garden (and incentives are misaligned)
AtProto does have platform and user managed labelers for the moderation piece, so it's at least built into the protocol. The jury is still out on how well that concept will scale.
Github is free and decentralization isn't.
git is. GitHub notsomuch.
The whole point of the submission here is that that's no longer true?
Sure, you can mooch off their centralized server for a while. In an actually decentralized network there have to be multiple servers which cost money to run and that money is never recouped.
After learning about ActivityPub and ATProto, people that talk about them literally cannot agree on what decentralized means.
Tangled & other folks run their own AppServers for doing Tangled views of the network. Those aren't insanely expensive by any measure.
Many of the people on Tangled especially host their own Personal Data Service themself. It's fantastically cheap.
This seems like you either don't know much or you are super super cheapening out on credit. Fear uncertainty & Doubt is a low motive.
It'd be great if you share concrete details: this type of machine on this type of connection, costing X. And what traffic and load does that see?
Here's a somewhat random exampe: "consuming the firehose for less than $2.50/mo" https://bsky.bad-example.com/consuming-the-firehose-cheaply/
Tangled very nicely gets rid of the having to run a server problem, yet still gives you a sovereign platform for doing git from. Truly divine.
The barrier is largely that Tangled is so new. People don't know about it. People don't know what Bsky & the Personal Data Server offer or they haven't been enticed out of the zero energy local minima.
There's some need for more features. For more tangled dev. Ideally for alternate clients, just because. But it's already enormously solid, the early adopters are living the better life, the future is already here and we are just waiting for devs to redistribute themselves appropriately.
Does Tangled offer any solutions or suggestions for backing up data stored on the Knots?
Hi! Knots just serve up git repositories over an XRPC API. The actual state on disk is really just a sqlite + your git bare repositories—the two can be tarballed and moved elsewhere easily!
We will work on more first party backup/migrate solutions though.
That sounds reasonable, but do your repos get replicated into your PDS? Where else does the data end up?
Git repos don't get replicated anywhere. They live on disk, either on our knot server or yours. Knots are essentially our extension to the AT architecture, allowing user ownership of what's essentially "off-protocol data" (git).
Thanks. What does get replicated?
I'm not sure what I'm looking at, but I see records that look like source code here:
https://ufos.microcosm.blue/collection/?nsid=sh.tangled.stri...
I mean you can self host your own knot if you want, so it's at bare minimum possible to back it up if you're doing that
I'm reminded of Brett Victor and his tangle library (2013).
https://worrydream.com/Tangle/
I was pleased to see that this has CI pipeline support, but am saddened to see that it looks roughly GitHub-actions shaped.
I don't see the point in writing a sequence of serial steps in YAML. A bash script can already do that. YAML configuration for pipelines should be focused on expressing the dependencies of a DAG, not the serial execution of a program.
Buildkite got this right.
New tomorrow: "Spaghetti", a no-code platform to run your business on, and "Lock-in", a vault to keep all your important data safe.
Why not improve upon https://radicle.xyz? It's been running for a while now with promising future. From my naive understanding of running a radicle node, it consumes around 40G of storage for the current network of 5k repos
The social factor. As someone who is very active on Bluesky, the social inertia of Tangled is great. I like Radicle too, but it's harder to collaborate with people, because it's harder to sell to people.
Is there any story for private/enterprise work here? the tangled stacked diff review flow looks very good for work stuff.
Potentially! We’ve discussed offering a fully airgapped, non-AT version of Tangled. It’ll be a bit of an undertaking so probably not anytime soon.
Not really: https://tangled.org/@tangled.org/core/issues/60
I am obliged to use a public GitHub org for work. Is it “blessed path” to try do the CR part in tangled and sync back to GitHub? I would love to profit from my nice jj habits at the review stage!
You could mirror it, yeah! Perhaps write a spindle pipeline[0] to push back to GitH*b on merge. :)
[0]: https://tangled.org/@tangled.org/core/blob/master/docs/spind...
since ATProto had a Merkle Tree of its own, I wonder if tangled utillize this internally to interop with git
No, they are very different merkle trees and mixing protocols is hard
Looks cool but I would really like to have this as a mirror of my local git repo server. If tangled goes down or my internet goes I won't be able to work.
Nothing preventing that! You can run a knot server[0] on top of your local git server—which I assume you push to using SSH. Knots serve up your git bare repos over an API (and federate over AT Protocol).
If Tangled’s appview is down, you can still access your own box as you would. Alternatively, you can mirror using git natively by simply adding a push-only remote.
[0]: https://tangled.org/@tangled.org/core/blob/master/docs/knot-...Ah cool thanks!
For stacked diffs, check out https://gitpatch.com/
Not receiving the signup code on email for tangled.org
It doesn’t seem to address this, but I’m curious whether this could be used for trivially relocatable package identifiers.
I don't really get it. What if anything gets stored in your PDS, versus somewhere else?
One easy way to tell is to browse lexicons (https://ufos.microcosm.blue/) and filter by "sh.tangled".
For example, I can see:
- https://ufos.microcosm.blue/collection/?nsid=sh.tangled.repo
- https://ufos.microcosm.blue/collection/?nsid=sh.tangled.publ...
- https://ufos.microcosm.blue/collection/?nsid=sh.tangled.repo...
Here's a link to all of them: https://ufos.microcosm.blue/collection/?prefix=sh.tangled
Having a hard time understanding what that website is showing (eg. what is a lexicon?). Could you explain?
Is it meant to be some kind of filtered sampling from the stream of ATProto events?
Yes.
Think of these as names of tables (or collections) in a distributed database. Or as type definitions. Or as app-defined data formats.
Each lexicon is a schema for a model. So you’re looking at a list of such “types” — a “repo”, a “follow”, a “star” etc.
There’s a “Tangled repo” lexicon, a “Bluesky post” lexicon, a “Leaflet publication” lexicon, and so on. Lexicons are specified and evolved by developers of each concrete application. Other apps can use those type definitions to read or write that kind of data.
See https://www.pfrazee.com/blog/why-not-rdf#lexicon for a short intro.
The UFO tool samples the global event stream and keeps stats on which lexicons are showing up in it (i.e. types of JSON that are being created on the network). You can expand the “samples” tab to show a few concrete JSON blobs so you get the idea of what the data represents.
I believe the rough separation is, code in git, all the other stuff around it (like what GitHub provides) as lexicon
iirc, a few things are not in lexicon/PDS yet, but intend to be
i just hope, this is really a thin service and not again running with javascript and also works over tor..
This is interesting, what does it give that hosted git doesn't?
The fact that all the data is open means not only that you could plausibly exit to other providers and keep all your projects data, (issues, prs, etc), but also that it's dramatically easier to build other tools that work on that same data. Triage, labelers, bots, etc, I know these are all possible on GitHub today with their API, but I think the programming model of ATProto removes a lot of friction in building and composing them.
I think there is a sort of thing built on top of Git where the wiki and issues are actually part of the repo itself, I forget the name, a bit like the Fossil SCM.
Maybe git-bug[1]?
[1]: https://github.com/git-bug/git-bug
git-annotate uses git notes and embeds a webserver for the frontend
Looks like a hobby project that made it out of Google and into open source. Not really worked on, but very cool concept
It's actually its own distinct version control _system_. And yes, it is Fossil SCM: https://fossil-scm.org/
No, he’s talking about git-bug.
decentralization out of the box for the most part. Its built on ATproto protocol which is used by bluesky/created by them
Git is decentralized.
We know.
The forges aren’t decentralized though (barring bits like Sourcehut pushing for email patch workflows). Thats part of what ATP is potentially helping to solve for here.
I'm not touching anything related to atproto with a ten foot pole