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?
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.
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!
You have options for self-hosting one or all of three pieces: a headless git host (the knot) which you get direct ssh access to through a limited ssh interface like other forges use, a CI service (the spindle), and the service that provides your user identity and metadata (the PDS). Account metadata such as which repos are in your account, and public SSH keys are recorded in the PDS, while repo data such as pull requests are recorded in the knot (I think. There might be some cross-over for publishing user activity via the PDS, I'm not sure).
Tangled owns the frontend, which everyone accesses through tangled.org. That's the web interface for both git features, and for CI. The frontend is an "AppView" which is difficult to self-host because it requires ingesting and aggregating a lot of network data. That's what assembles the network-wide activity feed you see on tangled.org, and that's where "Bobbin" comes in. But you _could_ access everything through a different AppView because your identity, data, and metadata are all owned by your PDS and knot.
The AppView concept is a point where Atmosphere differs from the Fediverse. In all my Fediverse experiences the service that I log into is the same service that runs the app frontend. With Atmosphere an AppView uses OAuth to authenticate you with your PDS. So I can log in to both Bluesky and Tangled with the same identity, compared to Fediverse where I need different Mastodon and Lemmy accounts to use both "apps". (Bluesky is also an AppView btw.) Instead of many federated frontend+backend instances, Atmosphere tends toward many federated, headless backends, with a small number of centralized frontends.
The PDS provides your DID which is your unique identifier in the atmosphere. It seems like the knot, in addition to hosting git repos and providing SSH access, does some PDS-like things. The knot provides DIDs for your repos, and holds metadata. But again, the metadata in the knot applies to the repo - metadata that applies to you as a person lives in your PDS.
I'm self-hosting a knot, and I'm planning to self-host a spindle. But for the moment I'm using a PDS provided by Bluesky.
i just found this too, more recent, possibly better! https://tangled.org/darko.mx/tangledart
From my very limited testing private repos were the big missing piece; interested in other areas yet to be filled in.
What can I expect as a developer using Tangled to build (and deploy) my app? What is the native platform? What are typical other CI systems that have been adapted to work on Tangled (Dagger, Drone, whatnot, especially if there are repos to demonstrate the adaption)? What can I expect as enterprise or lone developer using Tangled or self-hosting or federation?
The system is called Spindle, but what about it? What does it take inspiration from, what are things like it that would help us spool up on this?
The way that spindles work is that they basically just get events from repos when something happens, like a push or whatever. The spindle, if it's going to respond, eventually responds with what the results were, if any. If it looks like a spindle and quacks like a spindle, it's a spindle.
Tangled's CI happens to do this by way of receiving an event, looking at your Tangled workflow files, and using those to determine when it should actually run your CI. There's no reason it has to stay like that though.
I personally am planning on implementing a Tangled spindle that, instead of looking at Tangled workflow files, looks at just my Nix flake and builds and deploys things based on that. It's a very open solution, everything is just a protocol, there's no lock in.
Tangled's Spindle itself, as a product that conforms to the informal Spindle protocol, is pretty decent. You put in Nix dependencies and some scripts and when it should run, and you get out working CI. I have no complaints about it
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!