Hacker News Reader

> 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.

How does this fix the above issue on a decentralized network?

What happens when a new index is created on another server?

'fixed' or being worked on..... Still not cool and just an example of the 'building in public' approach that rubs me the wrong way.

Example post in question, shows nothing regarding the date. It basically shouldn't exist https://bsky.app/profile/retr0.id/post/3k5l4vko6jp2p

To me it sounds like it's fixed?

It's more of a temporary workaround iiuc, the real fix needs to happen in the UI. Posts have two timestamps, the "createdAt" timestamp which can be anything the author says it is, and the "indexedAt" timestamp, which is not an intrinsic property of the post but whenever the AppView server first saw it (which is relatively more trustworthy, but could be different across multiple AppView instances).

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)

Everybody's kind of got it. We didn't publish a lot the past couple days because we didn't want to highlight the situation during the election. Our fault for not solving it sooner.

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.

> 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.

If the goal is to build something that normal people will understand, this is a failure.

I'm not proposing the literal words "createdAt" or "indexedAt" be used in the UI.

No, I mean, having two separate times for a post appearing at all.

Isn't that what labellers do?

Eg this shows if a post has differing create/index dates

https://bsky.app/profile/backdate.mozzius.dev

Yes it's a temporary workaround which fixes the problem. It deserves further works but thanks to the workaround, the problem isn't there anymore. Your point?

FWIW Retr0id is one of the big community bluesky/AT protocol developers and importantly the person who more or less figured this out (or at the very least brought it to the community's attention).

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).

Thanks for that context, I just assumed he was another "ChrisArchitect" like commenter who want to equate "there is still more work to do" with "the problem hasn't been mitigated and the solution is stuck in development hell".

> and also open to weird loopholes like some ppl realized you could use an archive of tweets with some scripts from a dev on github and backdate posts into Bluesky. Meaning you could write wacky tweets like from Sept 11 2001 etc and they're all sitting there on the network like they 'happened' weirdly with comments from 2024

This sounds like a critical issue that should've been fixed as soon as possible.

This is how the whole rest of the web works, though. I can backdate my self-hosted blog articles to whenever I want. Heck, I can even backdate my git commits to whenever I want.

There is a safety issue here in practice and I don't want to downplay it (it violates user expectations), but I don't think it's "obviously" bad.

I think the violation of user expectations is much more severe on a micro-blogging platform like Twitter or BlueSky than it would be on git commits and even website blog post because of how that information is consumed.

Yeah I think so too. The application should be giving best-effort witness times.

of course. while I do appreciate the advantages it might offer for quick migration/onboarding...(how great to migrate your entire twitter history into place) to get a bunch of ppl onto the network, but it being abused to change history is a no-no. I'm all for open web/indie web/ability to move your data around but let's not pretend ppl were on Blue Sky for a decade. Sigh.

I don't want see how it's different than wordpress. I can change my own history. I guess it's about user expectations and media literacy, knowing who published the timestamp. With social media it's the platform time-stamping it, with self published media you have to decide if the source is trustworthy.

I agree that it's a bit early to go all-in, but my counterargument to the "enshittification" meme at the heart of this is that maybe we shouldn't get too hung up on having permanent solutions. Sure, sometimes services get worse over time. But if it's not bad now and doesn't look like it's getting worse, speculating that it might go bad is like being unwilling to go to a new restaurant because sometimes restaurants don't maintain their quality or suddenly go out of business. True, but so what?

Good things sometimes come to an end, but they're still worth doing while they're still good. Twitter had a good run before it went bad. The BlueSky party is just getting started. Sure, many things aren't done yet, but we don't know how it's going to turn out.

I think this is an excellent summation of the state of thinking on the Twitter alternatives out there. Nevertheless, they make me profoundly disappointed.

Being inconvenienced by having to build up the contact list and therefore staying locked in with X seems to meet to fundamentally misunderstand, well, everything. All of the motivations for moving which are centered on seizing the benefits of federation for social media and preventing companies from locking in, to me those are at a different order of magnitude in terms of their importance.

It's like not accepting the cure to your cancer because it comes in a green pill and green isn't your favorite color.

All of that said I do accept and embrace the criticisms especially of blue sky because it does seem to have weird loopholes, seems to have a preference for centralization built into the protocol which kind of misses the point, and generally is contributing to the squandering of what could have been a grand fediverse moment, all due to some idiosyncratic squabbles over things like how to handle usernames.

It's more than just that inconvenience (which is not a small one) it's that Mastodon is just a bunch of silos by interest in the end. You lose so much of the network effect for discoverability, both inwards and outwards. We've gotten used to having access to a whole world of networks via one centralized thing. I like the algorithm (with finessing). I want the 'suggested' posts of interest. With a good selection of follows, some amazing content gets surfaced/sent your way. I totally get the need/desire to break free of the company lock in, but Mastodon repeatedly shows how it is not it. The silos. The defederation risks. The missing community/participation unless you're really into only certain niches etc (still 'waiting' for more of the community to migrate over from twitter, waiting for engagement to pick up etc...). Might as well be on forums for interests again, which I have that already (HN for example). Anyways, lots of gripes. The fragmentation of the social network space has killed huge chunks of its value and the boat sailed on the 'grand fediverse moment' because it isn't grand in the end. Twitter has been a slow death losing a bunch of its value (but not really all of it, still huge amount of major posting, news, current happenings on there), which in many spaces has caused a growth in other centralized things like Instagram and Tik Tok. But we're talking 'microblogging' and putting the effort in to a platform like Mastodon, or even Bluesky when it's still figuring things out that are well established elsewhere, it's a tough sell.