ATProto Browser

Record data

{
  "uri": "at://did:plc:7mnpet2pvof2llhpcwattscf/beauty.piss.blog.entry/3lmnntm2p3j2t",
  "cid": "bafyreid7wfzanh75bwp4hd6vcfkomfw24jv6ifrqovyvc6hnopoh7h6qua",
  "value": {
    "tags": [
      "dev"
    ],
    "$type": "beauty.piss.blog.entry",
    "title": "Imposed Ordering",
    "content": "# Imposed Ordering\n\nRecently, Dan Abramov had a thread on why [he thinks Bluesky feeds don't work](https://bsky.app/profile/did:plc:fpruhuo22xkm5o7ttr2ktxdo/post/3lmmuyulsoc2n), and it lead me to think about the meaning of ordering in structured data. the core of his argument is this:\n\n```\ni think fundamentally feeds are a wrong abstraction. they conflate two very different competencies: curation and ranking\n``` \ndan (<a href=\"https://bsky.app/profile/did:plc:fpruhuo22xkm5o7ttr2ktxdo?ref_src=embed\">@danabra.mov</a>) <a href=\"https://bsky.app/profile/did:plc:fpruhuo22xkm5o7ttr2ktxdo/post/3lmmuyum4gs2n?ref_src=embed\">April 12, 2025 at 10:47 AM</a>\n\n\nI found this intriguing, because personally I think Bluesky feeds work pretty well, and i was curious about the framing of \"ranking\", as this doesn't quite fit my mental model of a feed.\n\n```\nwhat about a feed implies ranking? I've never gone to a feed expecting a ranked order of posts\n``` \nstellz (<a href=\"https://bsky.app/profile/did:plc:7mnpet2pvof2llhpcwattscf?ref_src=embed\">@piss.beauty</a>) <a href=\"https://bsky.app/profile/did:plc:7mnpet2pvof2llhpcwattscf/post/3lmmvvoawx22v?ref_src=embed\">April 12, 2025 at 11:03 AM</a>\n\n## ordering vs. ranking\n\nposts in a Bluesky feed, much like all other feeds, are displayed in a linear scroll. this linear consumption of posts necessitates an _ordering_ of the posts, but **does ordering imply ranking**?\n\nit certainly seems that for some people, there is often implied semantic meaning to the ordering of items in a list UI. in many cases, this is unambigously correct: if you're looking at a page of search results, you expect the most relevant items to be higher in the list - you expect them to be *ranked*. the ordering then expresses the ranking, without showing the relevance score for each item. in this case, ordering is semantically meaningful.\n\nin the case of a bluesky feed, it's more ambigous whether ordering reflects ranking. anecdotally, most feeds are not exactly ranked - they curate sources and delegate ordering to reverse chronological. but some are ranked, and thus sometimes the scroll in a bluesky feed has meaning beyond \"go back in time\".\n\nduring the thread about feeds, i used a spatial metaphor for how i think about scrolling them - [panning a camera across a landscape](https://bsky.app/profile/did:plc:7mnpet2pvof2llhpcwattscf/post/3lmmwso5ow22v), as opposed to reading through a ranking of posts. let's extend that a bit.\n\n## ordering is needed for navigation\n\nIf a bluesky feed's only job was _curation_ of posts, and not their ordering, we would need another component for anyone to actually read a feed - something that orders the curated posts. why?\n\nthere's no way to render an unordered set in a linear medium without imposing an ordering on it. \n\nwe impose ordering in many places in the built digital environment simply as a means of sensemaking: to have a navigable environment, there must be axes & paths to travel on, and ordering helps create them, even when the ordering is somewhat arbitrary. a feed's scroll is a local axis of travel.\n\nthis linear navigation problem gets even worse once the set is too large for a human context window. \n\n### the curse of pagination\nimagine you have an API route that you know will never return more than 50 items total. it's totally fine to not have a total ordering of the items returned by this route - the consumer is going to get all the items in one go.\n\nnow imagine a similar API route, that can potentially have thousands of items that match its query. consumers probably don't want to download all of an unbounded size dataset at once - they'd prefer pages of data with a fixed max size. it makes sense - a person can't really look at 1000+ items at once anyway.\n\nhow difficult could pagination be anyway. it's literally like turning pages in a book right?\n\n### forced full ordering\n\nin order to page through a dataset without duplicates or errors, you must be able to fully order the set. \nfor some datasets this is no issue, as they naturally contain a full ordering, like time series data.\n\nfor others, they might not have a natural full ordering, and suddenly you are in the position of having to _impose ordering_ on the data.\n\n#### example time\n\nat work, we have an API route that takes in 2 lists:\n* `owner_addresses` (Ethereum VM addresses)\n* `chain_ids` (numbers that unqiuely identify a given blockchain)\n\nand returns a bunch of information about all the various tokens these addresses have on those chains.\n\nthe information returned by this API has some natural ordering (timestamp, descending), but it's incomplete: due to the discrete time steps of a blockchain, it's possible for two items in the response to have the exact same timestamp.  how can we disambiguate this ordering? arbitrarily! \n\nto achieve total ordering and thus pagination, we do this ordering on the query that powers the response:\n\n```sql\nORDER BY block_time DESC, owner_addr DESC, token_addr DESC\n```\n\nthis then makes it very easy to paginate - this one line implements the cursor in the query. \n\n`$3`, `$4`, `$5` are the block_time, owner_addr, and token_addr of the last item in the previous page, which is all the data we serialize to the cursor for each response.\n```sql\nAND (block_time, owner_addr, token_addr) < ($3, $4, $5)\n```\n\nit would work just as well to switch the order of the last 2 sort criteria, since they're arbitrary:\n```sql\nORDER BY block_time DESC, token_addr DESC, owner_addr DESC\n```\n\nas long as our ordering is total and the query performs well, it doesn't quite matter what the exact order is. it mostly matters that the consumer can linearly navigate through the results.\n\n## what does this have to do with feeds, again?\n\nthe mental model i have of feeds' ordering of posts not being too meaningful arises from a sort of background acceptance that we are all mechanically _forced into ordering_ out of necessity, in order to be able to get around. this leads to many orderings that carry little semantic meaning aside from navigability.\n\nis a road's exact path \"meaningful\"? maybe, maybe not, but if you haven't set some sort of conrete path for it, you aren't driving anywhere.\n\nI guess i just got used to thinking of ordering as only loosely meaningful in many places online, and found this a fascinating difference in mental models.  that's all!\n",
    "createdAt": "2025-04-13T01:18:47.386Z"
  }
}