Struct Repo 

pub struct Repo<'a> {
    pub http: &'a Client,
    pub pool: &'a SqlitePool,
    pub session: &'a OAuthSession,
    pub key: &'a SigningKey,
}

An authenticated handle on one account’s repo.

Fields

http: &'a Client

pool: &'a SqlitePool

session: &'a OAuthSession

key: &'a SigningKey

The session’s DPoP key, already unsealed.

Implementations

impl Repo<'_>

pub async fn list_records( &self, collection: &str, limit: Option<u32>, cursor: Option<&str>, ) -> Result<(Vec<RecordEntry>, Option<String>)>

One page of a collection.

pub async fn list_all_records( &self, collection: &str, ) -> Result<Vec<RecordEntry>>

Every record in a collection, following the cursor.

Bounded at [MAX_LIST_PAGES]: the repo is user-controlled, so an unbounded walk is a denial-of-service against ourselves. A cursor that does not advance also terminates the walk rather than spinning.

pub async fn create_record<T: WritableRecord>( &self, collection: &str, record: &T, ) -> Result<WriteResult>

Create a record, letting the PDS assign the key.

pub async fn put_record<T: WritableRecord>( &self, collection: &str, rkey: &str, record: &T, ) -> Result<WriteResult>

Create or replace a record at a known key.

pub async fn delete_record(&self, collection: &str, rkey: &str) -> Result<()>

pub async fn apply_writes(&self, writes: &[WriteOp]) -> Result<()>

A batch of writes in one round trip.

impl Repo<'_>

The reader’s typed surface, over Repo.

Deliberately thin: each method is one repo call plus a parse, and the orderings come from crate::lexicon::sort, SHARED with the sidecar client so the two cannot disagree across the cutover. A divergence there would not be subtle — it would reorder the user’s feed list the moment the implementation swapped.

pub async fn list_subscriptions(&self) -> Result<Vec<(String, Subscription)>>

pub async fn list_subscriptions_sorted( &self, ) -> Result<Vec<(String, Subscription)>>

Every subscription, in the reader’s deterministic order.

pub async fn add_subscription(&self, sub: &VettedSubscription) -> Result<String>

Subscribe to a feed. Returns the new record’s rkey so the caller can address it (rename, delete) without re-listing.

pub async fn remove_subscription(&self, rkey: &str) -> Result<()>

pub async fn update_subscription( &self, rkey: &str, sub: &VettedSubscription, ) -> Result<WriteResult>

Replace a subscription in place — retitle, refile, change cadence. Returns the WriteResult rather than discarding it: the caller logs the resulting record URI, and a () here would have silently dropped that field from the log line after the cutover.

pub async fn add_subscriptions_bulk( &self, subs: &[VettedSubscription], ) -> Result<Vec<String>>

Batch-add many subscriptions in one applyWrites — the OPML-import path.

One round trip rather than N: an import of several hundred feeds is the case this exists for. Returns the new rkeys, which are assigned HERE rather than by the server: client-side TIDs keep the imported feeds in input order and make the batch reproducible. The sidecar client does the same, with the same generator.

pub async fn list_folders(&self) -> Result<Vec<(String, Folder)>>

pub async fn list_folders_sorted(&self) -> Result<Vec<(String, Folder)>>

pub async fn add_folder(&self, folder: &Folder) -> Result<String>

pub async fn remove_folder(&self, rkey: &str) -> Result<()>

Delete a folder. Subscriptions referencing it are left alone; a dangling reference reads as “unfiled”, which is the same behaviour the sidecar client has.

pub async fn rename_folder( &self, rkey: &str, folder: &Folder, ) -> Result<WriteResult>

Returns the WriteResult, matching the sidecar client — the caller logs the record URI from it.

pub async fn list_saved(&self) -> Result<Vec<(String, Saved)>>

pub async fn list_saved_sorted(&self) -> Result<Vec<(String, Saved)>>

Saved entries, newest first.

pub async fn add_saved(&self, saved: &VettedSaved) -> Result<String>

pub async fn remove_saved(&self, rkey: &str) -> Result<()>

pub async fn list_read_states(&self) -> Result<Vec<(String, ReadState)>>

pub async fn put_read_state(&self, rkey: &str, state: &ReadState) -> Result<()>

Upsert one read cursor at its feed-derived rkey.

pub async fn flush_read_states( &self, cursors: &[(String, ReadState, bool)], ) -> Result<()>

Flush many dirty read cursors in one applyWrites.

Read state changes on nearly every page view, so this is the hottest write path in the app; one round trip per flush rather than per feed is the whole point. The bool is whether the record already exists in the PDS. It is not optional bookkeeping: an #update on a missing record ERRORS, and applyWrites is atomic per repo, so one not-yet-created cursor in the batch would drop the whole DID’s flush. The op builder is shared with the sidecar client so the two cannot decide create-vs-update differently.