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
contextproperty.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 AIn this scenario, because my instance
Ais 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:
- You already have the entire context, so it's unnecessarily duplication of work
- 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.
-
I see two reasons this could happen:
- C's server or client software doesn't know how to include the
context - 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.
- C's server or client software doesn't know how to include the
-
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
inReplyTois not known to you, that unknown object should be fetched, regardless ofcontext.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.
-
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
inReplyTois not known to you, that unknown object should be fetched, regardless ofcontext.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.
C's reply didn't get dropped, it simply didn't includeA, the original server. The last reply did, but because the context wasA, it never contained it, so it never pulled it.inReplyToisn't checked when utilising context-backfill because it is supposed to replace having to do that.Except not in this edge case
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login