Crumb
c/technical-discussion · by julian@activitypub.space · 24d

Edge case when backfilling topics

When it comes to backfilling topics, NodeBB utilises what is called "context collection backfill" instead of reply-chain traversal. In a nutshell, instead of crawling up and down the reply tree one-by-one — kind of like what Mastodon does currently — it checks for a canonical source-of-truth in the context property.

NodeBB supports both strategies, since not all objects contain context.

I found a fun little edge case where if I start a topic, a reply is received, and that reply points to my instance, it won't catch any replies made in between.

In other words:

localA starts topic → remoteB replies → remoteC replies to B only → remoteB replies to C and A

In this scenario, because my instance A is left out of the third activity, I don't know about it. When the fourth activity appears, the context is checked, C's reply isn't in it, and I proceed without knowing about it. Oops!

In this case, when incoming replies reference a context that is same-origin to your own instance, you should not use context collection backfill, because:

  1. You already have the entire context, so it's unnecessarily duplication of work
  2. You won't catch any replies made out-of-band unless you do reply-tree traversal

Tagging @silverpill@mitra.social because this is related to FEP f228.

2 points · 4 comments · view on lemmy.world

4 Comments

evan@activitypub.space · 1 pts · 24d (1 reply)

I see two reasons this could happen:

  1. C's server or client software doesn't know how to include the context
  2. C intentionally wanted to remove their reply to B from the context. It's a semi-private aside.

I think you'd want to backfill in case 1 but not in case 2. But I don't think there's an easy way to tell which is which.

julian@activitypub.space · 1 pts · 24d

I'm not sure which case it was, but #1 definitely applies in many cases where older Mastodon servers don't report a context. I am also not sure whether Mastodon implements context inheritance as described in FEP 11dd

#2 does apply if the mention were explicitly removed (in the case of Mastodon). Most other software doesn't tend to pre-fill a bunch of mentions since other addressing techniques are used.

silverpill@mitra.social · 1 pts · 24d (1 reply)

When the fourth activity appears, the context is checked, C's reply isn't in it, and I proceed without knowing about it. Oops!

I don't understand this part. Is C's reply being dropped?

I think if you encounter an object where inReplyTo is not known to you, that unknown object should be fetched, regardless of context.

this is related to FEP f228.

FEP-f228 specifies a backfill algorithm that works from top-level post down the thread. But it would be nice to provide an algorithm that works for any post in a thread. I'll think about it.

julian@activitypub.space · 1 pts · 24d

C's reply didn't get dropped, it simply didn't include A, the original server. The last reply did, but because the context was A, it never contained it, so it never pulled it. inReplyTo isn't checked when utilising context-backfill because it is supposed to replace having to do that.

Except not in this edge case :)