







Just about every app built on AT needs data from a repository at some point. For many use cases – feed generators, labelers, bots – streaming live data through a Relay or Jetstream works well. But some applications need to go beyond what Jetstream was designed for, like tracking specific subsets of a repo, automatically backfilling a database when adding new repos to monitor, or even mirroring the entire Atmosphere.
Jake Lazaroff — Building more resilient local-first software with atproto
About — AT Proto Collection Tracker
A bottom-up tool for discovering activity across the AT Protocol network by watching live record types on the Jetstream firehose.
Bitesize Proto: Upserting ATProto Records - Hitchhiker's Guide to the Atmosphere
Tired of creating duplicate records in a repo from your atproto app?
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.).
y-atproto - npmx
A [Yjs](https://yjs.dev/) CRDT provider that syncs documents over the [AT Protocol](https://atproto.com/). Documents are stored as ATProto records and real-time updates are delivered via [Jetstream](https://github.com/bluesky-social/jetstream).



neodb-social/neodb
🧩 a self-hosted server tracking what you read/watch/listen/play, powering a global distributed community federating via ActivityPub and ATProto.
Personal sync servers for composable data
Exploring the possibilities of interoperability and composability for local-first software & data by using a personal sync server tied to an atproto identity

Personal sync servers for composable data
Exploring the possibilities of interoperability and composability for local-first software & data by using a personal sync server tied to an atproto identity

LiveStore
LiveStore is a next-generation state management framework based on reactive SQLite and git-inspired syncing (via event-sourcing). - LiveStore
Building More Resilient Local-First Software with atproto | jakelazaroff.com
atproto has the potential to become a rock-solid replacement for the most fragile part of any local-first app: the sync server.

What would premium or subscription based Feeds look like for AT Protocol? github.com/bluesky-social/atproto/pull/4… That's something I think would be interesting to explore. Maybe a feed could do freemium too, like it'll give you x% of content for free, but by paying it becomes more frequently updated?

import.py
Archivers AT

Brickster — Build anything, together.

BlueHarbor

Kimbia - A training journal that belongs to you.

Currents