A diskless, API-only AppView for Tangled
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.).
Can atproto scale down?
Decomposing the Bluesky appview and self-hosting the pieces
Cobalt: apps and an SDK for Kobo e-readers
A launcher, a signed App Store, a Rust SDK, and a capability-isolated runtime for the Kobo Clara BW.
Am I Building the Torment Nexus? - What happens when an AppView gets an easy window into atproto spaces.
I built a tool that lets HappyView operators browse the contents of atproto spaces, and the moment I saw it working I got a pit in my stomach. Here's what the community had to say about whether it should exist, and what it needs to look like if it does.
Introduction | HappyView
HappyView is the best way to build an AppView for the atproto. Upload your lexicon schemas and get a fully functional AppView, complete with XRPC endpoints, OAuth, real-time network sync, and historical backfill, without writing a single line of server code.
Hosting websites on Tangled
You can serve static websites directly from your git repositories on Tangled. If you’ve used GitHub Pages or Codeberg Pages, this should feel familiar.
Hosting websites on Tangled
You can serve static websites directly from your git repositories on Tangled. If you’ve used GitHub Pages or Codeberg Pages, this should feel familiar.
calendar pt. 1: ATProtocol beyond AppViews - building [at] habitat
our approach to permissioned data (part 1!)
tldraw: Infinite Canvas SDK for React
The tldraw SDK provides tools, services, and APIs to build beautiful whiteboards and infinite canvas applications with real-time collaboration and a powerful React-based canvas.
Flutterby • A fun little Bluesky app for your iPhone and iPad
Create Bluesky widgets on your iPhone and iPad desktops. Flutterby dynamically updates news, art, posts and more!
Slingshot: atproto edge record cache
API Documentation for Slingshot, a firehose-listening atproto edge record and identity cache.
The code is here: tangled.org/tyler.fun/chalky.town/tree/ma… I rushed through the sync bits a bit to get a thing working, but those two methods are in the branch I have to clean it up 😅
