I've been setting up my own self-hosted knot, with excitement - this is the kind of forge I've been wishing for! There's an architecture document, but I'll leave some notes on how I've come to understand things so far.
https://tangled.org/permadeath.com/atgc/blob/main/docs/archi...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.
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.