# Knot 2 This is an alternate implementation of a Tangled knot server! In Tangled, a "knot" is simply a git server that does its auth layer over the AT Protocol. Essentially, it tastes like this: 1. Atproto users declare their public SSH key for themselves, in their PDS. 2. A knot admin (defined by atproto DID in the knot config) makes a request to the knot to allow membership to a given atproto user. 3. Said user can now create/update/delete a git repo on the knot, and do normal git things to that git repo over SSH. 4. Said user makes a request to the knot to allow more atproto users as collaborators on their specific git repo. The reader will notice this disconnect between making requests to the knot, vs. making requests to atproto (individual users' PDSes). The social side of git repos (PRs, issues, etc.) are "owned" by atproto at time of writing; in contrast, important ACL data (members, collaborators), lives on the knot as the source of truth. As time goes on we are re-assessing the idea of users owning what is "collaborative data" (issues, PRs, etc.) on their PDSes - soon may come the day that an issue also lives on the knot as a source of truth, with an accompanying pointer record on user PDS to attest that it's theirs. Back to knot 2 today: - **It has no database, or should I say, git is the only database, along with a secret-key-file.** - It aims to be small, fast, and modern - for example: http3/quic support, SHA256 by default, and no need for unix `git` user, to name a couple of features. - Config variables are in example.toml, just make a config.toml from that and go ham. Have fun! # Running a knot2 The following is how I actually run `knot.oyster.cafe`. Please treat it as one possible setup. The soon-to-be knot operator will need 3 things before beginning: 1. A remote computer, preferably one that stays online 1. A domain name directed at the remote computer 1. The operator's own atproto DID, which becomes the knot's admin If the operator doesn't know their DID, resolve the handle at [pds.…