Arrays in real atproto records almost universally lack index-bound significance. That is: a selector for a record's array element at index=0 is almost never useful.
there are a couple of records in tangled that make use of array ordering!
- the
pullrecord makes use of ordering of "rounds", to denote sequential revisions of a patch. the ordering is important to track patch evolution. - (to be implemented) the profile record will soon use the ordering of pinned repos in the lexicon to dictate the ordering of pinned repos in the UI
Right! This might be me being too backlink-brained. The text as written is failing (badly) to say what I mean there, which is not that array ordering is always meaningless in an absolute sense. even bsky post facet order kind of matters when resolving overlaps...
...in places where you'd use
RecordPath, like say configuring TurboStream to hydrate pulls, would you ever want to configure it explicitly to hydrate one specific round and not all rounds?I mean, maybe you would.
I did drop the requirement that selector libraries return vector matches in record-order, which would kind of keep the door open for doing index-significant match behaviour in your app code (except when more than one array is in the path)
thanks for opening this. def more to consider and clarify!