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?
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
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!
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.
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.
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!
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 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.
The point of doing it declaratively is that you can easily expose all that information in the UI, and process it to set up the pipeline in the first place (multiple runners, which OS they run, dependencies between steps).
I agree most of your `run` steps should just be one or two lines to call out to another script though, and you shouldn't split things into multiple steps unless necessary.
How does Buildkite do it? Their website doesn't seem clear but it looks like it also uses YAML, you can just use a script to generate it. Gitlab supports that somewhat awkwardly, and I've definitely had one project where that would have been useful (though I couldn't convince my colleagues to do it).
I don't think it would be difficult to add support for it anyway.
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
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."
25 comments
[ 3.2 ms ] story [ 48.5 ms ] threadiirc, a few things are not in lexicon/PDS yet, but intend to be
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
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.
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!
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.
I agree most of your `run` steps should just be one or two lines to call out to another script though, and you shouldn't split things into multiple steps unless necessary.
How does Buildkite do it? Their website doesn't seem clear but it looks like it also uses YAML, you can just use a script to generate it. Gitlab supports that somewhat awkwardly, and I've definitely had one project where that would have been useful (though I couldn't convince my colleagues to do it).
I don't think it would be difficult to add support for it anyway.
"Take everything with you" is just downstream from "find or be a trustworthy node."
https://worrydream.com/Tangle/