Chebucto Regional Softball Club

I suppose you're right in a way. The context owner is not supposed to be set by someone other than the context owner. It's a fallback mechanism intended for better compatibility with Mastodon. When a group is addressed and it is one of the local NodeBB categories, it will assume control If it is another group that it knows about but isn't same origin to the author, then no category is assumed.

[silverpill@mitra.social](https://community.nodebb.org/user/silverpill%40mitra.social) yes, it should. Mentioning the category means it will be addressed and NodeBB will slot the received content in the first group object it finds.

[projectmoon@forum.agnos.is](https://community.nodebb.org/user/projectmoon%40forum.agnos.is) it'll work better once cross-posting is built into NodeBB I think

[silverpill@mitra.social](https://community.nodebb.org/user/silverpill%40mitra.social) do you still need to if you're not using a shared inbox?

Hi [robz@toot.robzazueta.com](https://community.nodebb.org/user/robz%40toot.robzazueta.com)! This could be related to some better support for non-`Note` types introduced by Mastodon in later versions. Your instance is running v4.1.18 which is 11 months behind the latest version. That isn't necessarily cause for concern, but I think that might be why you're seeing the HTML tags?

[trwnh@mastodon.social](https://community.nodebb.org/user/trwnh%40mastodon.social) thanks, I've updated them to add the protocol. I guess you can't rely on support for protocol-relative URLs everywhere

In February 2025, I presented a topic at FOSDEM in Brussels entitled [The Fediverse is Quiet — Let's Fix That!](https://spectra.video/w/xwCSYfZh1mJY64zJ9GngbE) In it, I outlined several "hard problems" endemic to the fediverse, focusing on one particular complaint that is often voiced by newcomers and oldtimers alike; that the fediverse is quiet because you don't ever see the full conversation due to some design considerations made at the protocol level. Since then there have been a number of approaches toward solving this problem, and it is worth spending the time to review the two main approaches and their pros and cons. _N.B. I have a conflict of interest in this subject as I am a proponent of one of the approaches (FEP 7888/f228) outlined below. **This article should be considered an opinion piece.**_ ---- ## Crawling of the reply tree First discussed 15 April 2024 and merged into Mastodon core on 12 Mar 2025, [jonny@neuromatch.social](https://community.nodebb.org/user/jonny%40neuromatch.social) pioneered this approach to "fetch all replies" by crawling the entirety of the reply tree. When presented with an object, the Mastodon service would make a call to the `context` endpoint, and if supported(?) would start to crawl the reply tree via the `replies` collection, generating a list of statuses to ingest. This approach is advantageous for a number of reasons, most notably that `inReplyTo` and `replies` are **properties that are ubiquitous** among nearly all implementations and their usage tends not to differ markedly from one another. _N.B. I am not certain whether the service would crawl *up* the `inReplyTo` chain first, before expanding downwards, or whether `context` is set in intermediate and leaf nodes that point to the root-level object._ One disadvantage is this approach's **susceptibility to network fragility**. If a single node in the reply tree is temporarily or permanently inaccessible, then every branch of the reply tree emanating from that node is inaccessible as well. Another disadvantage is the reliance on intermediate nodes for indexing the reply tree. The amount of work (CPU time, network requests, etc.) scales linearly with the size of the reply tree, and more importantly **discoverability of new branches of the reply tree necessitate a re-crawl of the entire reply tree**. For fast-growing trees, this may not net you a complete tree depending on when you begin crawling. Lastly, in the ideal case, a full tree crawl would net you a complete tree with all branches and leaves. Great! Mastodon is the sole implementor of this approach, although it is not proprietary or special to Mastodon by any means. ## FEP 7888/f228, or FEP 171b/f228 Summarized by [silverpill@mitra.social](https://community.nodebb.org/user/silverpill%40mitra.social) in [FEP f228](https://community.nodebb.org//w3id.org/fep/f228) (as an extension of FEPs [7888](https://community.nodebb.org//w3id.org/fep/7888) by [trwnh@mastodon.social](https://community.nodebb.org/user/trwnh%40mastodon.social) and [171b](https://community.nodebb.org//w3id.org/fep/171b) by [mikedev@fediversity.site](https://community.nodebb.org/user/mikedev%40fediversity.site)), this conversational backfill approach defines the concept of a "context owner" as referenced by compatible nodes in the tree. This context owner returns an `OrderedCollection` containing all members of the context. A major advantage of this approach centers around the pseudo-centralization provided by the context owner. This "single source of truth" maintains the index of objects (or activities) and supplies their IDs (or signed full activities) on request. Individual implementations then retrieve the objects (or activities). It is important to note that **should the context owner become inaccessible, then backfill is no longer possible to achieve**. On the other hand, a dead or unresponsive intermediate node will not affect the ability of the downstream nodes to be processed. The context owner is only able to respond with a list of objects/activities that it knows about. This does mean that downstream branches that do not propagate upwards back to the root will not be known to the context owner. Additionally, consumers are also able to query the context owner for an index without needing to crawl the entire reply tree. The ability to de-duplicate objects at this level reduces the overall number of network requests (and CPU time from parsing retrieved objects) required, **making this approach relatively more efficient**. Additional synchronization methods (via id hashsums) could be leveraged to reduce the number of network calls further. A number of implementors follow this approach to backfill, including NodeBB, Discourse, WordPress, Frequency, Mitra, and Streams. Additional implementors like Lemmy and Piefed have expressed interest. One technical hurdle with this approach is technical buy-in from implementors themselves. Unlike crawling a reply tree, this approach only works when the context owner supports it, and thus should be combined with various other backfill strategies as part of an overall conversational backfill solution. ## Conclusion 2025 is shaping up to be an exciting year for resolving some of the harder technical and social problems endemic to the open social web/fediverse. It is this author's opinion that we may be able to make good headway towards resolving the "quiet fedi" problem with these two approaches. It is important to note that **neither approach conflicts with the other**. Implementations are free to utilise multiple approaches to backfill a conversation. Both methods presented here have pros and cons, and a combination of both (or more) could be key. Feel free to use this as a starting point for discussions regarding either approach. Does one speak to you more than the other? Are the cons of either approach significant enough for you to disregard it? What other approaches or changes could you recommend?

[goten@piefed.social](https://community.nodebb.org/user/goten%40piefed.social) hi, from NodeBB !

[nutomic@lemmy.ml](https://community.nodebb.org/user/nutomic%40lemmy.ml) let me know if I got any of the details wrong. Much thanks to your team for the assist in debugging!

[kichae@wanderingadventure.party](https://community.nodebb.org/user/kichae%40wanderingadventure.party) I'm still at the point where seeing two-way federation working for real between instances is so exciting that it overrides the pain of federation

It all started [with a report about federation breaking between Lemmy and NodeBB](https://community.nodebb.org/topic/18824/did-4.4.1-break-federation-with-lemmy-groups). I was subconsciously aware that something was going on, but had chalked it up to network issues. Observed behaviour showed that some remote categories would be receiving content in spurts, with long gaps in between. I spent the next 3-4 days looking into it, but came up empty. Whatever was happening wasn't throwing any obvious errors, and along the way, I found what I _thought_ was related (it was), but I wasn't sure why: against some Lemmy servers, the "follow"/"unfollow" mechanic would simply stop working, and this would often coincide with gaps in content. In some egregious cases, the flow of content stopped completely! Unable to make headway, I had to [reach out to the folks at Lemmy](https://github.com/LemmyNet/lemmy/issues/5722) to figure out what the issue was. NodeBB occasionally sends non-200 level responses depending on the activity. Specifically, the following scenarios: * A remote user upvoting more than 20 posts in a single day (a spam prevention tactic) causing NodeBB to throw an error, which was caught and returned an `HTTP 500 Internal Server Error`. * A `Dislike` activity, which is not currently handled by NodeBB. In these cases, NodeBB would send an `HTTP 501 Not Implemented` When encountering either of these responses, Lemmy would return the activity back to the queue for later delivery and **mark a delivery failure**. If enough of these (~40) happened within 24 hours, Lemmy would give the instance a time-out and _pause delivery completely_. That was it — a quick pair of code updates later, and we started working through Lemmy's backlog of 4.1M activities. As of 4am this morning, `community.nodebb.org` is no longer behind `lemmy.world`.  Fun week. Let's not do that again LOL.

[scott@loves.tech](https://community.nodebb.org/user/scott%40loves.tech) Mastodon does not use summary as content warning for Articles.

[scott@loves.tech](https://community.nodebb.org/user/scott%40loves.tech) that's probably it, if it started in the past few weeks.

That's odd, we don't produce bbcode, where did it come from?

[eeeee](/user/eeeee%40community.nodebb.org) [this blog post](https://community.nodebb.org/topic/18821/topic-thumbnails-uploads-and-media-display) should shed some light on my decision-making, but I'm open to changes!

[silverpill@mitra.social](https://community.nodebb.org/user/silverpill%40mitra.social) I thought about checking against the outbox, but there's a potential race condition that could occur if I receive the `Create(Note)` at roughly the same time as the community, but the community hasn't processed the activity yet. In that scenario, the activity would not be in the outbox for checking. The same thing would happen if there was some out-of-band check for object membership in a collection (not that there is one right now).

I'm wondering how content on threadiverse is automatically assigned its community when received by the software (e.g. PieFed, Lemmy, Mbin). The answer I am expecting is "if the community is addressed (`to`, `cc`, `audience`), then it is slotted into that community". **However** that causes issues for compatibility with microblogs... for example, [silverpill@mitra.social](https://community.nodebb.org/user/silverpill%40mitra.social) recently authored a post that mentioned `[swf@socialwebfoundation.org](https://community.nodebb.org/category/swf@socialwebfoundation.org)` and it got slotted into that community on NodeBB, which isn't correct since that group is private. Better practice would be to only trust the addressed community if it is `Announce`'d by the community directly, but would fall short if my instance does not receive the `Announce` (say, if nobody follows the community), in which case we'd fall back to "uncategorized", which is where all microblog posts currently go. Then it's neither correct nor incorrect, I suppose. I think this might be an issue where NodeBB tries to be too many things at once (microblog and threadiverse compatible).

[@kirk@social.coop](https://community.nodebb.org/user/kirk%40social.coop) just wanted to drop a note that your two issues have not been forgotten

Hi [@neil@mastodon.neilzone.co.uk](https://community.nodebb.org/user/neil%40mastodon.neilzone.co.uk), thanks [@andyprice@mastodon.social](https://community.nodebb.org/user/andyprice%40mastodon.social) for the shout out. I recommend NodeBB as it's one of a few forums that are still maintained and evolving. The latest version brings support for federation, allowing communication between it and any other software that supports ActivityPub (such as Mastodon, Lemmy, etc.) We focus on the lightweight and fast aspects of forum software. Communication should be seamless, and the software should be lightweight.

[@silverpill@mitra.social](https://community.nodebb.org/user/silverpill%40mitra.social) when discussed with Nutomic about this, I made the case that 1b12 is excellent for synchronization. 7888 (and 171b, etc.) are good for backfill, in cases where there is no 1b12 implementation available.