Intro
This is an attempt to describe the "knot" pattern used by tangled.org and where it might fit in the AT Proto developer arsenal
Scenario
You want one or more users to create data using your app/platform, but you don't want to store it in their PDS
Terminology
AppView: an aggregator of AT Proto events that you can browse
PDS: personal data server, the place where users store their data
Knot: Tangled's headless self-hostable servers, responsible for Git remote hosting and triggering CI
Why Not Be "Fully ATProtated"
I've long thought of the PDS as the place you want to store everything relating to your app, but that might not fit every use case
A git repo is highly file system dependent, which makes it not sensible to store in a PDS. Also any git user is used to interacting with a repo in a git-native way, possibly cloning and pushing it to several remotes and clients.
One of the main points to a git repo is also collaboration! If all the repo contents live in your PDS, then how would multiple people interact with it? Would a commit made by someone else be stored in my P(ersonal)DS? In theirs as well? It gets weird.
Honorable mention goes to Tangled's pastebin alternative called strings, which appears to store entries entirely in the user's PDS, since it makes sense to do that
Is a Knot a PDS?
Sometimes it's hard to keep these terms apart. A knot exposes enpoints under /xrpc, much like a PDS. But it doesn't support the same commands, and has no identity of its own
A Secret Third Thing
So! A knot is mostly a standalone concept, mixing together the git parts and atproto. It has /xrpc endpoints and indexes some atproto records to e.g. verify identities. It mostly holds data that doesn't belong in a PDS. When users interact with a repo on Tangled's AppView, their interactions are stored in the user's PDS, and when necessary the AppView talks to the knot to request information or execute actions on the user's behalf
When I asked @anirudh.fi on Discord, he described it thusly:
i like to call it as a "user hostable" component of the wider tangled appview. a knot indexes atproto records (pubkeys, pulls, collaborators, members, …), and does things based on these ingested records. it's a mini/scoped appview!
The Knot Pattern
A separate thing exists and holds state
It can be easily self hosted
An AppView can interact with it
A user interacts with it and when it makes sense their interactions are stored in collections on their PDS
I'm curious if this pattern will (or already does) exist for other services in the AT Proto ecosystem. It seems like a great way to go!