If I want to create 100 repos of vibe coded projects every month someone will have to pay for it.
At this point, just give me an honest version of GitHub that tells me what things actually cost. 5$ a repo, and another 1 per gb stored in LFS, cool.
I find Tangled's language a bit annoying because I'm pretty sure if this caught on it's even more single word concept rather needlessly. If the protocol is called Knot, then call a server a Knot instance or Knot server. If the runner protocol is called Spindle, each server which responds to that could be a Spindle runner. That'll serve two functions: It'll let people contextually hook the terms up against existing terms and still retain the option of evolving into singular word concepts if they prove successful enough for that to happen.
From my point of view as a non-native speaker, the frequent overloading of commonplace words add to the confusion of learning English. I don't like that. It's far from a big hurdle, but just big enough to earn a soft little sigh from me.
Your comment was the only thing that made me even care to comment: Isn't it rather unlikely that the person you're commenting on takes issue with a kink rather than any other reason why "knot" and "spindle" might be poor choices? Who knows, they might even have a good reason, but you started out with assuming bad faith and at least I tend to just leave conversations at that point.
Tangle: the appview server of the tangled network.
Knot: the git server that holds an arbitrary quantity of git repos.
Spindle: CI servers/runners/nodes.
Each one is the name of a component and the name for those components is pretty arbitrary.
That really proves his point though - the cute names are pretty much useless for an outsider.
The equivalent of a knot in gitlab is a gitlab instance or for forgejo a forgejo instance. There's just not really a clean equivalent.
A knot is a git server but it's not the git host/remote. The remote is the appview (which is the software stack called "the tangle"). The knot isn't just a storage backend either.
The knot is a little bit of a lot of things from the existing models so it just does not and cannot fit cleanly into an existing definition. Doubly so because what the knot does today is not the only things it will do. It will likely gain additional functionality in the future so to give it a reductive label now will only add to the confusion.
Instead it's a knot. That's what it is. And you can explain what a knot is if someone asks but at the end of the day it's a knot and what that means is specific to this project and network.
Fixed low cost but different UI: sourcehut.org
Getting my friends to feel comfortable moving ( so they can view the UX ) too will be a challenge.
Although it doesn't have all the "plugins" and other stuff that CI tools have today, it provides fairly "standard" points of integration
For more info: https://man.sr.ht/builds.sr.ht/
I agree the website is a bit confusing at first, but after spending a couple of hours on it you can easily see how it's organised, for example to display branches and files it uses the more basic git terminology (e.g. main branch -> tree, list of commits -> log, branches and tags -> refs)