Community maintained Docker config for the knot server
knot
This is a Knot server: a git host on a network of federated servers that make up Tangled.
Migrating to the new Tangled knot2 | jola.dev
Tangled is a Github alternative built on atproto. I've previously shown you how to set up the self-hosted repo server, here I go through migrating to knot2.
Tangled docs
Tangled is a decentralized code hosting and collaboration platform. Every component of Tangled is open-source and self-hostable. tangled.org also provides hosting and CI services that are free to use.
Database file is seemingly never created #2
Tested on Debian Bookworm x64 & Ubuntu aarch64 Upon making a new knot instance the log is spammed with `level=ERROR msg="failed to load db: unable to open database file: no such file or directory"` and `level=INFO msg="successfully finished setting up hooks" command=knot`. The `server` directory is made but is empty
proposal: ingest repo records #282
`sh.tangled.repo` records are one of the last few records that need atprotation (2-way sync between appview/pds). this one is tricky because we want consistency between knot state, appview state and PDS state. the path forward is described below: - migration to did/rkey syntax universally: in several places, we utilize `did/repo-name` as a globally unique identifier for a repository, we should migrate this to `did/rkey`: * for the tangled appview: this means reworking our ACLs, routers and DB to use `did/rkey` or ATURI as a globally unique identifier for a repo * for knots: this means changing paths on disk to be `did/rkey`, allowing git ops to `host:did/rkey` , updating ACLs, and XRPC endpoints * for spindles: this means updating ACLs and XRPC endpoints - once this is done, we can define ingestion logic for all services in the network to pull sh.tangled.repo records * for the tangled appview, this should create/delete/update a repo pointer record * for knots: this should create-or-ignore/delete-or-ignore/update-or-ignore a repo on disk. migration of repos needs to be thought out here. * for spindles: as above - define edge-case behaviors: * when referring to repos by rkey, it is possible for clever users to create duplicate records with the same repo-name, appview routers must handle this ambiguity with a new interstitial page that offers a redirect, knots must return an error upon push/pull on ambiguous git URLs * the `knot` cli can introduce a command `backfill` or `sync` to bring knot state up to sync with the rest of the world (repos, collaborators, pubkeys, ACLs etc.).
ewancroft.uk/tangled-sync
[READ-ONLY] Mirror of https://github.com/ewanc26/tangled-sync. Move from GitHub to Tangled.org
ewancroft.uk/tangled-sync
[READ-ONLY] Mirror of https://github.com/ewanc26/tangled-sync. Move from GitHub to Tangled.org
Ok, continuing the series on the atproto self-hosted components that make up covetown, here's how you set up a knot and spindle for @tangled.org Caveat: they're in the process of rolling out new components, but there's a migration path, and I'll write about that too! jola.dev/posts/self-hosting-and-tangle…
Self-hosting and Tangled
jola.devSharing this! Wish I'm not late for #IETF126 Tangled found PDS doesn't fit well for contributions even with upcoming permissioned space spec. So, we are planning to store record-like data outside of PDS, in Knot. This is a post explaining the reasons & upstream spec change we need. #atproto #atdev
tangled-cob.md · by boltless.me
tangled.orgahhhh it works! I have an atproto PDS, knot, spindle, and hold, all driven by a repo hosted on the knot, running on container images created by the spindle and hosted on the hold. The accounts that tie it together all live on the PDS. tangled.org/cove.town/cove.town
cove.town/cove.town
tangled.org
