Does the order of nodes returned by getRepo (etc) matter?

[snarfed]

Hi all! Looking at the current staging.bsky.app PDS, I can't tell if it returns nodes in its getRepo response in any specific order. It doesn't seem to be by repo commit linked list, age, CID lexicographic, or anything else obvious.

Does order matter in the responses to getRepo, getBlocks, and similar methods (if any)? Or can clients get the current repo head with getHead, follow its data to get the current MST's root node, and then get to anything they need from there, so order in these responses doesn't matter?

[bnewbold]

Hey @snarfed!

When a generic CARv1 file is returned, it has a header which can indicate zero or more "root" CIDs. In the context of atproto, if there are one or more commit objects being returned, the "primary" commit (eg, the most recent or current commit for a repo), then the CID of that commit block should be the first element of the set of "root" CIDs. This gives receiving code a pointer to the "top" of the IPLD DAG.

As to the overall order of blocks, there are a couple interesting schemes for more or less efficiency in both generating and processing the repo DAG. But in general, clients/receivers probably need to be agnostic and handle any possible order of blocks.

We have a specs doc for repos and the CAR export coming soon which will mention the above.

[snarfed]

Very useful, thanks!