Support Atproto-Repo-Rev header for sync awareness #30

New issue

Closed

opened 2026-04-12 17:30:15 +00:00 by Grandiras · 1 comment

Grandiras commented

2026-04-12 17:30:15 +00:00

Owner

Summary

ATProto.NET should support the Atproto-Repo-Rev HTTP response header for synchronization awareness. This header allows clients to know if a service has processed recent repository updates.

Spec Reference

From the Data Synchronization spec:

"Services can indicate synchronization status using the Atproto-Repo-Rev HTTP response header, which should contain a single commit revision (TID) of the account making the API request."

What's needed

Response header parsing - Extract Atproto-Repo-Rev from XRPC responses
Read-after-write awareness - When a client writes to the PDS and then reads from an App View, compare the known revision with the received header to detect if the read service is up-to-date
Expose revision info - Make the latest known revision available to consumers
Optional waiting/retry - Optionally wait/retry if the service hasn't caught up to the expected revision

Why this matters

Improves UX: after creating a post, fetching timeline from App View may not show it immediately
Enables clients to show "syncing" indicators
Important for apps that do rapid read-after-write patterns

## Summary ATProto.NET should support the `Atproto-Repo-Rev` HTTP response header for synchronization awareness. This header allows clients to know if a service has processed recent repository updates. ## Spec Reference From the [Data Synchronization spec](https://atproto.com/specs/sync#repository-revisions): > "Services can indicate synchronization status using the `Atproto-Repo-Rev` HTTP response header, which should contain a single commit revision (TID) of the account making the API request." ## What's needed 1. **Response header parsing** - Extract `Atproto-Repo-Rev` from XRPC responses 2. **Read-after-write awareness** - When a client writes to the PDS and then reads from an App View, compare the known revision with the received header to detect if the read service is up-to-date 3. **Expose revision info** - Make the latest known revision available to consumers 4. **Optional waiting/retry** - Optionally wait/retry if the service hasn't caught up to the expected revision ## Why this matters - Improves UX: after creating a post, fetching timeline from App View may not show it immediately - Enables clients to show "syncing" indicators - Important for apps that do rapid read-after-write patterns