Out-of-order user profile timeline when other AP software is importing old statuses

[renatolond]

Steps to reproduce the problem

1. Bluesky user connects bridgyfed to their account
2. Bluesky user imports old Twitter archive using blueark.app
3. Older statuses start being imported into Bluesky and consequently into bridgy, then mastodon displays them out-of-order, not by date, but by the order they are imported

Expected behaviour

User statuses should be ordered by date

Actual behaviour

User statuses ordered by "discovery date"

Detailed description

This is not exclusive to bridgy-fed or bluesky users, but this is how the issue is manifesting on my server. (This is related to snarfed/bridgy-fed#1724.)

The bug in question for me is this: Any ActivityPub that allows posts in the past (be it by importing from another service, or just by allowing users to post in the past) will have the posts displayed in the order they are discovered by Mastodon. As far as I can see, that is because when importing AP activities, a new status is created without an id and so the id is created using the timestamp_id function, which takes the current time as part of the generation of the id.

However, the id for imported activities could be pre-calculated using Mastodon::Snowflake.id_at or a similar function.

That's not only a matter of display, either. If multiple users start using the service, then any user that are followed from my instance will start having potentially a lot of statuses and I can't even remove old statuses using bin/tootctl statuses remove, because the id is used as a cut-off.

This might be tangentially related to the discussion in #22794, since this does allow for some "past manipulation".

Mastodon instance

masto.donte.com.br

Mastodon version

v4.3.3+donte

Technical details

If this is happening on your own Mastodon server, please fill out those:

• Ruby version: ruby 3.3.7 (2025-01-15 revision be31f993d7) [x86_64-linux]
• Node.js version: v20.18.0

[ClearlyClaire]

The reason this happens is that brigy is actually broadcasting those posts in new Create activities. Bridgy is essentially saying “I am now Createing an old post”. This goes through our live ingestion codepath (ActivityPub::ProcessingWorker), which explicitly overrides timestamps (override_timestamps: true in ActivityPub::ProcessCollectionService).

The idea behind override_timestamps was that you would not miss posts that get directly delivered to you. The behavior was first introduced in #5260 with the assumption that Create received in the inbox would only be for real-time data.

I still think this assumption is reasonable, but maybe it should be revisited.

[renatolond]

I think it makes sense that such old posts should not be broadcasted as new ones on Bridgy side after understanding the code path.

OTOH, I don't know if the override_timestamps makes sense for such old posts. The use-case @Gargron explained for it was when delayed posts are sent some hours later because a server was down, and if there was a AP server being used like https://solar.lowtechmagazine.com/, I could imagine it being down for a few days, but not for years. It does complicate the logic, though. But as an server admin the side effect of it seems annoying.