Back

@thisismissem Probably! What sort were you thinking of?

@mauve like flooding peoples timelines with the backfilling of posts

@thisismissem I assumed timelines would sort by published time no? I'm gonna run some tests before deploying this to production ofc

@mauve I think there's a bug to the contrary

@thisismissem In mastodon? i'd love to see the source code for it if you know what part of it it'd be in.

@mauve I don't have it off top of my head but follow from /app/lib/activitypub/activity/create.rb

@thisismissem It seems to be taking the created_at part out at least. https://github.com/mastodon/mastodon/blob/main/app/lib/activitypub/activity/create.rb#L122C7-L122C17

I'll look more after testing. Gonna let my personal instance take the bulk o9f the damage :P

@mauve yeah, I've heard of like, birdsite bridge that did similar backfilling clogging up people's timelines, but that might be specific to that implementation.

@thisismissem @mauve so... imo the ActivityPub way of doing this is to publish your last X posts at an "outbox" endpoint specified in your profile. Then a remote server following you can parse the outbox and get some content to fill things with. I did this with some software I was building and Mastodon just... didn't grab any of the outbox posts and I was confused as to why not

@darius @thisismissem @mauve yeah the outbox is there to support "web browser" use cases, fetch the latest activities and page through to see history

the thing with mastodon and timeline sorting is that the timeline sorting algorithm isn't using creation date, it's using arrival date. this is so someone can't create a post set in the far future to have it pinned at the top of your timeline.

@darius @thisismissem @mauve so delivering an activity ~now would insert the post at the top of the TL even if it was backdated in the `published` property.

@trwnh @thisismissem @mauve Oh interesting. But also: why not use arrival date for future dated posts and creation date for back dated posts? (Genuine question btw. I'm sure I'm missing some weird edge case race condition)

@darius @trwnh @thisismissem @mauve Because of Announce, as the obvious case. But more generally, when an object was created doesn't have any real connection to when it should be presented to people. Mastodon is doing more or less the right thing, here.

I wish mastodon would be more prompt in backfilling from the outbox, so that this wouldn't even seem necessary. But even that is basically the right behavior.

@jenniferplusplus @trwnh @thisismissem @mauve I see what you mean by time created vs when it should be presented. That said, if we consider the context of pulling from an outbox to backfill, then the context seems pretty clearly (to me, I could be wrong) "do not show this in the home timeline, this is just for filling in our database for views more generally"

DOES Mastodon pull from the outbox? I didn't observe it doing it at all

@darius @jenniferplusplus @thisismissem @mauve nope, mastodon p much ignores the outbox

and yeah it makes sense to *not* do timeline insertion when backfilling, backfilling seems like the kind of thing that is only/primarily useful for viewing a profile and not keeping up with current activities

@darius @jenniferplusplus @thisismissem @mauve another way to look at it is that there are really two dates, one is the date the object claims to be published, and the other is the date that the activity arrived in your inbox. most fedi dev is used to thinking in terms of objects, but it would be more technically correct and spec-accurate to think in terms of activities

@trwnh @darius @thisismissem @mauve objects have dereferenceable URIs. Why wouldn't I make that a first class entity in my data model?

@jenniferplusplus @darius @thisismissem @mauve activities do too, as well! or they should. activities are also objects.

the advantage of thinking in terms of activities is that it's a better representation of reality, with AP serving as a specialization of LDN (Linked Data Notifications), you're basically notifying your followers/audience/recipients that "something happened". it's the reason we POST Create activities and not just raw non-activity objects.

@trwnh @darius @thisismissem @mauve
Unless the activity is intentionally transient. The spec says this twice in two paragraphs. I don't know what it means for an activity to *not* be transient. Activities are actions, not ongoing persistent state. The objects the refer to are the persistent state.

@jenniferplusplus @trwnh @thisismissem @mauve I see the transient language in the spec but it's about ids and guids and referencing things globally. I don't read it as saying anything about activities being temporary things that can be thrown away (though they allow for the possibility). Every time I've worked with an Event/Object model (at least in years as an MMORPG dev) we consider both Events & Objects to be first-class entities. All of these things should be first-class and treated as such

@erincandescent @darius @thisismissem @mauve @trwnh I would argue that about non-transient activities.

@erincandescent @darius @thisismissem @mauve @trwnh undo is also a problem.

@jenniferplusplus @darius @thisismissem @mauve @trwnh I can’t say I’m a big fan of the Undo acitvity in practice, but the problem applies to an Unfollow activity all the same.

Having ids makes certain forms of state resolution easier. What would really make them easier is monotonically increasing but otherwise opaque ordering token included in every activity, but I have a hell of a lot more distributed systems experience in 2024 than I did in 2014.

@erincandescent @darius @thisismissem @mauve @trwnh
I don't think it even makes sense to view the AP network as a distributed system. It's a heterogenous network of independent systems. There is no correct state for the system because there's no singular system or even singular state.

The mechanisms you're talking about are useful for preventing desynchronization, but that's not actually a goal. At least not a goal that makes sense to me. Some desync will happen intentionally, by design.