Delay between posting and API availability

[GreenFootballs]

I'm working on a client, and one of the things I need to do is save a copy of the post data immediately after posting. I was doing this by calling com.atproto.repo.createRecord, then passing the returned uri to app.bsky.feed.getPosts. But in some cases (not always!), it seems like the post data is not available through the API that quickly, and getPosts doesn't return an error -- it's just a null array. If I wait a little while, then try the getPosts call again, it works as expected.

Is there some kind of caching that would cause this delay? And is there any way to work around this?

[snarfed]

Hi! This is probably because of the PDS/BGS/AppView architecture.

Originally, the PDS handled all of those API calls itself, so they were strongly consistent more or less automatically. The team is now migrating toward serving reads from the AppView instead, either directly and/or proxied through the PDS. Commits take time to propagate from the PDS through the BGS to the AppView via subscribeRepos, so that's probably causing the eventual consistency you're seeing.

(I don't know what the team thinks of this eventually consistency. I'm curious to hear!)

[bnewbold]

We have thought about the eventual consistency a whole lot!

The situation we find the most important and time sensitive is that folks "read their own writes", meaning that if they take any action (create a record), then immediately do a fetch from the appview, it should be clear if the action is included, and best-case the action is represented. Many apps handle this in clients using a local cache, but we are trying to move this responsibility to the PDS.

One helper for this is to have the AppView return the most recently indexed repo rev value (logical clock, as a TID) in an HTTP header. These requests are proxied by the PDS, and the PDS always knows the current actual rev clock for the repo (the end app client probably also knows, but in a multi-device situation it could be out of date). So the PDS (and probably app) know if it got a stale read from the AppView or not.

One thing an application-aware PDS could do in this situation is inject in known local info to the response before returning it to the end client. For example, if you liked a post very recently, and the appview hasn't indexed that, then the "my account state" in a feed response might not include the correct "have I liked this post" metadata. The PDS "knows" that you recently liked it and can update the response.

We do this currently in our PDS reference implementation, with some limits around which responses can be mutated/updated, and IIRC how long of a "staleness" window will be handled. I can't remember the exact details, we should probably do a dev blog post about this and update the specs with the HTTP header name and semantics.

[GreenFootballs]

A little while ago I suggested that the createRecord call should return the entire post record, instead of just a DID and CID. I still think that would be a good practice, and it would be consistent with other social media systems -- both Mastodon and Twitter return the full post data on creation.

[snarfed]

Definitely! Makes sense.

The other thing you might try is com.atproto.repo.getRecord, which ideally the PDS can/should handle itself, instead of app.bsky.feed.getPosts, which is the AppView's domain.

[GreenFootballs]

Unfortunately, getRecord doesn't include image URLs.

[DavidBuchanan314]

That's because they're not part of the record, they're part of the view (i.e. generated and returned by the AppView, not the PDS). Image URLs are deterministic though, so you ought to be able to predict them. I'm not sure if the "format" is documented anywhere, but you can inspect existing images to figure it out.

[DavidBuchanan314]

I'm not sure I understand the purpose having the record reflected back upon creation, it ought to be exactly the same as what was submitted?

[GreenFootballs]

I thought the post was created with the image URLs already embedded, so they'd be part of the returned data. But now I see they're actually created in the AppView, so, uh, never mind!

[GreenFootballs]

P.S. For anyone following this discussion, I just discovered that the URL format for images has changed; it's now possible to get the image URLs with just the CID and the DID of the user. The image URL formats for thumb and full size:

https://av-cdn.bsky.app/img/feed_thumbnail/plain/__DID__/__CID__@jpeg
https://av-cdn.bsky.app/img/feed_fullsize/plain/__DID__/__CID__@jpeg

[GreenFootballs]

And on this note, it would be great if you could get the original image (at its original size unscaled) by using something like:

https://av-cdn.bsky.app/img/feed_original/plain/__DID__/__CID__@jpeg

[DavidBuchanan314]

you can get the original image via getBlob (but maybe there could be some performance benefits to getting it via a CDN)

[GreenFootballs]

The problem with getBlob is that you get... a binary blob. Not as easy to deal with as an image URL, but yes, it can work with some more finagling.

[snarfed]

getBlob HTTP responses include Content-Type!...so you can use them in a hrefs etc directly. Example: https://bsky.social/xrpc/com.atproto.sync.getBlob?did=did:plc:vwzwgnygau7ed7b7wt5ux7y2&cid=bafkreih2xfvvjo3xfvbidesyglzhip7szi6f4bbb7ocw5zrturl7wpynx4 , response includes Content-Type: image/svg+xml.

[GreenFootballs]

Good idea.

[GreenFootballs]

Interesting that getBlob is one of the few magic GET endpoints that doesn't require authentication. Is that deliberate?

[bnewbold]

Like getRepo and the firehose, this is necessary for federation and redistribution of content.