> not yet fixed, still being exploited
It is actually fixed. Tweets have been showing up with their "Indexed On" date instead of the actual authoring date. The thing that isn't implemented is showing both dates for tweets with separate dates.
It is actually fixed. Tweets have been showing up with their "Indexed On" date instead of the actual authoring date. The thing that isn't implemented is showing both dates for tweets with separate dates.
What happens when a new index is created on another server?
The proper fix, imho, is to have the UI display the "createdAt" timestamp but warn (perhaps with some kind of alert icon) when there's a significant mismatch between createdAt and indexedAt.
(An even more proper fix might involve a quorum of "witness" servers but that might be an exercise in scope creep)
Here's the full deal. Every record self-declares a createdAt which can't be fully trusted. Every appview records indexedAt which is == to "first seen at." We can always expect indexedAt to lag behind a "correct" createdAt, and in ideal conditions that lag is quite small.
The server was previously blending the internal indexedAt with the declared createdAt by returning the min(createdAt, indexedAt). Blending a trusted-but-lagging timestamp with the declared timestamp is a technique that works for sorting under specific conditions; if you're doing reverse-chron ordering you take the min of both, and if you're doing chron ordering you take the max.
We will continue to use the blended min() for ordering within reverse chron feeds, but the problem is that we've historically been sending that down to the client for rendering. We recently changed it to give the actual `indexedAt`, which is part of the full solution. Unfortunately in the weeks preceding that change, a bunch of tweet importers had gotten popular without us realizing it, and our change caused the imports to all show the import time instead of the create time. So, we reverted that for now.
The plan is what retroid describes -- we turn back on that change to the server behavior, and then if `createdAt < indexedAt - 24hr` or so, we indicate in the UI that it's likely an import from an archive. That's the full longterm solution. A quorum witness model is definitely overdoing it for now, but we have discussed creating exports of our index times so that new appviews can take advantage of them when doing backfill.
Point being that they were just clarifying the situation as they are probably one of the most informed people on the situation (with the other reply in this subthread being a first party bluesky dev and therefore one of the other SMEs on the topic).
If the goal is to build something that normal people will understand, this is a failure.
Eg this shows if a post has differing create/index dates