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
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.
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.
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"]
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.
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 :)
https://codemadness.org/stagit.html
Does Pgit support branches?
They don't need to be, but it's very convenient.
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!
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?
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.
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.
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)
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)
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.
We will work on more first party backup/migrate solutions though.
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...
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.
"Take everything with you" is just downstream from "find or be a trustworthy node."
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 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.
[0]: https://tangled.org/@tangled.org/core/blob/master/docs/spind...
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.
git remote set-url --add --push tangled [repo]
Looks like a hobby project that made it out of Google and into open source. Not really worked on, but very cool concept
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
Is it meant to be some kind of filtered sampling from the stream of ATProto events?
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.
iirc, a few things are not in lexicon/PDS yet, but intend to be