Hello, tried following a Lemmy community (e.g. test@feddit.it) both on my own instance (citiverse.it, v4.14.2) and here on community.nodebb.org, from the category page (/category/test@feddit.it). In both cases the follow seems to go through, but new posts never show up afterwards.

Is this a known issue, or should I dig further and post more details?

tl;dr — cross-posting is coming to NodeBB in v4.9.0. It will be internal-only for now, as we work through social issues with federated cross-posting. Existing category sync and auto-categorization logic in NodeBB now utilises cross-posts instead of moving or ignoring categorized topics, respectively.

Some history

For the past couple months, I've been mulling over the idea of cross-posting, and how this would work in a federated forum context. Specifically, I had begun to think more critically about how NodeBB presented itself in the threadiverse (threaded fediverse), and whether what we were doing currently was the right approach.

Somewhere in the v4.1.x releases, NodeBB began supporting a new feature called "category synchronization". It allowed categories to follow other categories, and would move topics from those other categories into a local category. If done in reverse, the both categories could be considered "synchronized", meaning that users on both instances could see, like, and comment on the same topics.

As of v4.3.x, NodeBB gained the ability to actually "see" remote categories. You'd be able to browse to a local representation of something like @fediverse@piefed.social or @comicstrips@lemmy.world and see the posts in those categories as though you were on that site itself. It was a huge jump in how NodeBB treated threadiverse content.

After that point, it became a little weird that category sychronization would move topics from one category to another, because the topic really didn't lose its existing categorization, we simply stole it! When I introduced auto-categorization rules in v4.5.0, I was cognizant of this discrepancy, and avoided complication by ignoring already-categorized topics.

What is cross-posting?

In a nutshell, cross-posting is the ability for a single topic/reply-tree to exist in multiple places simultaneously. Comment trees are shared and accessible from both of those places, and this avoids unnecessary duplication of content across multiple communities.

We see manual cross-posting happening often on the fediverse already, and collapsing these identical items into a single entity would be a boost to discussion as it eliminates the artificial fracturing of comments across multiple disparate posts.

Importantly, v4.9.0 will introduce cross-posting locally only. It means that topics from outside the forum can be cross-posted to an local category, but local topics cannot be cross-posted to remote categories. This is the eventual plan, but we are not there yet! See below ("Why don't cross-posts federate?") for more details.

Cross-posting essentials

Topics will have a new button in the sidebar (or top bar, in the Persona theme) that allows you to cross-post topics to another category. In this dialog, you will be able to choose one or more categories to cross-post the topic to.

Admittedly, there's not a whole lot of utility in cross-posting local topics to another local category, but it really shines when you crosspost remote topics to a local category.

When a cross-post appears in a local category, a link back to the original category is shown.

Anyone can cross-post a topic to a local category, but only mods and administrators can remove others' cross-posts.

What of category synchronization and auto-categorization?

The existing features will be updated as follows:

• Category synchronization logic will no longer move topics from one category to another, they will now be cross-posted and visible in both categories.
• Auto-categorization rules now apply to categorized content. When a new topic is discovered matching an existing rule, it will be cross-posted to the target category.

Why don't cross-posts federate?

I want to roll out a first-pass at cross-posting as there are immediate benefits for forums and their local categories. Being able to pull in content from other remote categories while respecting their categorization will allow for more increased cross-community engagement and expose remote communities to people who would have otherwise not discovered them.

At the same time, we want to move slowly because there are wide-ranging effects that federated cross-posting could bring about. Namely, if anybody is able to cross-post anything anywhere, then it would enable brigading because different communities with (sometimes very) different values would suddenly co-exist in the same space, leading to some very negative interactions.

Additional questions exist, such as:

• Who gets to moderate the discussion?
• How are reports handled in cross-posted topics?
• Does a cross-post need to be approved?
• How do we express these using ActivityStreams vocabulary?

I certainly don't have all the answers as to how to best approach it, but it is something we at the @forum-wg would love to tackle at some point.

What's next?

Other threadiverse software (Lemmy, Piefed, mbin) don't handle cross-posting, and there are no immediate plans to support it. Piefed does have something similar (called "Topics", akin to Reddit multi-reddits) which can contain posts from multiple communities. Both Lemmy and Piefed attempt to automatically collapse comment trees when identical links are discovered. Moving forward we may want to coalesce toward a single desired behaviour, but whether cross-posting is it, is to be determined.

Additionally, NodeBB doesn't have the concept of "boosting" (also known as resharing, reblogging, etc.) It does do something similar when topics are moved between categories, and so it would make sense that a cross-post would be the forum equivalent of a reshare.

Cross-posting is currently being tested on activitypub.space, and should be generally available as of NodeBB v4.9.0.

I wanted to say thank you again for everything you guys have done and continue to do for the nodebb world.

You (@julian, @baris, and everyone that has contributed), have been on my short list of real heroes over the past decade and have made a profound impact in the lives of the regulars on https://kubuckets.com/

We recently bumped up from v1.13.1 to the latest and greatest nodebb. I ended up "archiving" the old board by linking to it in categories and giving it a different domain name. I manually copied over some of the mongo data to preserve the user data and force reset everyones password. It was a bumpy road that led to a beautiful place :)

After reading Enshittification per my brothers recommendation in November, I started digging into the fediverse, and suddenly @julian popped up everywhere. It's serendipitous and a small world after all. I intend to fully explore what I can do with ActivityPub on https://kubuckets.com/ and https://unshittified.club/ in the coming year. I have had a couple failed attempts to link between the two, but I need to get more familiar with how to configure it. I'm hoping that with the fediverse I can grow our user bases a little bit, maybe we can be the first people who discuss sports on the fediverse. Haha. I tried to recruit on reddit a little bit but reddit didn't like that very much and quickly canceled me :)

Thank you guys! Merry Christmas! @approxinfinity@kubuckets.com

I found this article from earlier this year: https://blog.discourse.org/2025/04/discourse-and-the-fediverse/

However, I haven't come across that much content from Discourse platforms over here on Lemmy/Piefed. Is there more work to do with the plugins, or should we work with organizations running Discourse to help them connect with us?

For example, the threadiverse communities for OpenStreetMaps is relatively small, and being able to see / contribute to community.openstreetmap.org would be amazing.

testformyforum2

testformyforum

I'm going to register a protocol handler, so links to anywhere on the fedi will be opened in the user's home instance.

https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler

Has anyone already done this and if so what was the prefix you used? We might as well all use the same thing. I'm thinking web+fedi.

Several people told me they couldn't figure out how to reply to a NodeBB conversation if they just had a link to the post, and yeah it is kind of non-obvious. So I decided to write something up on that as well as a few other quirks. Here's what I've got so far ... feedback welcome!

https://discussions.thenexus.today/topic/48/how-to-follow-and-participate-in-discussions-here-from-your-fediverse-and-atmosphere-accounts

Just an idle thought... A common UX is users copying the URL in the address bar and pasting it into their fediverse app to load it in their app.

Right now if you copy a NodeBB topic (/topic/12345) and paste it into something like Mastodon, you'll get nothing because it is an ordered collection and it doesn't know how to handle it.

But... what if I passed in a preview property a la evan@cosocial.ca's b2b8 and it contained a Note? Maybe a note with a different id? Maybe with a name?

Waiting for trwnh@mastodon.social to tell me this is a terrible idea.

As I write this, I'm sitting on an airplane flying over the Canadian prairies on my way home from Vancouver, BC.

What an amazing group of individuals, who took the time out of their extraordinarily busy lives to see, hear, and learn about the fediverse! The connections made and ideas discussed were so important, and you could feel the energy in the air.

You'd think after a solid six hours a day in a lecture hall would be enough, but at every opportunity in between, there were lively discussions about ActivityPub and the fediverse. It turns out when you get all of us in a group together we can talk and continue to talk about the open social web for ages.

I now have a to-do list about a kilometer long, they all need to get done ASAP!

Thank you to reiver@mastodon.social for organizing this conference, all of those who helped out and participated, and all those who attended.

From now on, whenever someone points a camera to me, I'll picture jaz@toot.wales saying "say FEEEEEEDIVERSE".

Let's get this party started!

Day 1 of FediCon

I've been toying with the idea of using OAuth2/OpenID and the C2S API to have a service act on behalf of another instance (e.g. act on Lemmy, post as Mastodon account)

But now I'm wondering whether that kind of complexity is needed... one could theoretically register a public key to the instance it is acting on behalf of, and simply sign activities using the ID of the other server... Second server would need only update the actor with the new public key for verification purposes...

The only problematic account I have encountered so far is welcome@friends.deko.cloud but I have not tested many. On attempting to follow, it just hangs on “request pending”. I have been able to reliably follow the account from mastodon (for example).

This question was asked by mike@flipboard.social on Dot Social's latest episode about the blogosphere on Fedi.

johnonolan@mastodon.xyz: "we wanted to connect Ghost blogs to each other, but then we discovered ActivityPub"

pfefferle@mastodon.social: "we wanted to connect WordPress blogs to each other, and ActivityPub has been the most successful attempt"

[paraphrased for brevity]

Did you catch the subtext? Both those answers, and my own answer with NodeBB contain the same seed idea... that we originally wanted to connect our software with itself only. We went through years of building a company and vying for profitability that it never occurred to us to work towards cross compatibility with anyone besides out own software.

Then ActivityPub came along and quite literally expanded the potential for the entire endeavour a hundred-fold, because not only are you connecting your own software to each other, but every other ActivityPub enabled software in existence. Blogs, microblogs, forums, image boards, etc. all with a built-in user base ready from the get-go.

It's no wonder that after discovering AP, it becomes the protocol to utilise.

In February 2025, I presented a topic at FOSDEM in Brussels entitled The Fediverse is Quiet — Let's Fix That! 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 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 in FEP f228 (as an extension of FEPs 7888 by trwnh@mastodon.social and 171b by mikedev@fediversity.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?

It all started with a report about federation breaking between Lemmy and NodeBB. 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 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.

v4.4.2 of NodeBB contains the updated logic for smoother Lemmy federation.

I'm assuming Unicode in handles is not allowed? At least by Mastodon.

This user is not able to have their content federated because the username is all Hebrew (I think?) characters!

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 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).

Does anybody know what exactly Pleroma needs for a valid Webfinger check? I'm attempting to figure out why @jmtd@pleroma.debian.social won't resolve in NodeBB, and it's because the webfinger call returns 400 Bad Request.

NodeBB is calling https://pleroma.debian.social/.well-known/webfinger?resource=acct%3Ajmtd%40pleroma.debian.social with User-Agent and Content-Type headers (curiously, it's not sending Accept, but it also fails if that header is set, so that's irrelevant.)

Navigating to that webfinger url in the browser returns XML, which is :grimacing: but I'm not even getting that when NodeBB makes the call.

In my ever-continuing use of NodeBB as a single-user Fediverse instance, here are some things I've noticed. Both things I've already talked about before, and some new things. These are some suggestions for functionality or perhaps plugins.

1. Confusion between following remote categories as a user and the synchronization options in category settings as an admin. I think the category synchronization should be repurposed somewhat. The suggestion from @julian@community.nodebb.org was to perhaps rework it as a cross-posting feature.

   • Right now, the feature relies on the other ActivityPub endpoint to be able to follow the NodeBB category, which (notably Lemmy) does not always work.
   • Making a "proxy user" is a pretty common solution to this, used by Misskey etc. One single system proxy user can follow all remote categories, and then NodeBB itself can handle the synchronization.

2. Lack of posts. This is a general problem for single-user instances, and it's why things like relays and Fedifetcher exist. Support for relays would help a lot, but a Fedifetcher-like plugin/function would be even better.

   • Fedifetcher works by loading posts from the source server, and finding all the replies there. It then executes a search against your own server, which fofrces your server to load the reply. This should work just fine for NodeBB, because searching post links causes the posts to load.
   • But Fedifetcher relies on platform-specific APIs (Mastodon, Misskey, etc). So I think this would be a good candidate for a NodeBB plugin.

3. Slotting posts and topics into local categories. To me, this feels like the holy grail of integrating the traditional forum experience into the Fediverse. It's something I've brought up before, and someone was working on a plugin, but I'm not sure it ever got finished.

   • It would be amazing to add a function in the admin settings under category settings to make a list of remote ActivityPub actors that get posts slotted into the category automatically.
   • Any incoming note from that actor will be automatically put into the specified category.
   • This shouldn't need to rely on altering or updating any synchronization stuff, because it can work with any incoming post. The framework for receiving remote posts is already there.

These are all just ideas, and maybe some discussion can be had on them before I start embarking on a path of attempting to make some NodeBB plugins :smile:.

Following up on this question I asked back in late March, I wanted to continue thinking about how one would handle cross-posting between categories/communities, given that there isn't current consensus on it, and especially given that NodeBB—as of v4.3.0—can now see and browse remote categories.

From that original topic, we can distil the following:

1. Both PieFed and Mbin do not natively handle cross-posts, a new entity is made with the crucial bits (link, text, possibly title) copied over and changed if needed, sometimes a "cross-posted from..." helper text is prepended.
2. There are legitimate concerns that a cross-post might not succeed depending on privilege settings on the receiving end, so a pre-flight check (or explicit rejection) of some kind might be required.
3. Cross-posting can be done by the original author, or another user.

So were an FEP to be written, we'd center it around the following assumptions:

• "A user (which may or may not be the object author) is sharing an object to additional audiences"
• We would use the existing Announce(Object) model
• We would not use Announce(Activity) because it is not the original object creation that is being announced, but the object itself, to a new audience.
• Some form of Reject handling would be required for cases where the cross-post is not allowed
• How the receiver handles the activity is out-of-scope of the FEP. It could be that the original object is contained within multiple categories/communities, or a duplicate object could be created — implementor's choice.

This is very similar to an existing announce/boost/reshare, except that instead of addressing the activity to followers list you are addressing it to a group actor's inbox.

Some additional questions:

1. Is there desire from PieFed/Lemmy/Mbin for supporting incoming (and possibly outgoing) federation of cross-posting?
2. What exactly happens currently if a Group actor receives an Announce(Object)? My guess is nothing, currently, but let me know otherwise :smile:
3. Would this allow you to accept cross-posts from other AP applications without needing to refactor any existing code?
4. Duplicating the object would mean the discussion is split between objects. The ideal implementation would be the same object present in multiple categories/communities. Is there desire for this in the threadiverse?

@rimu@piefed.social @andrew_s@piefed.social @melroy@kbin.melroy.org @bentigorlich@gehirneimer.de @nutomic@lemmy.ml @angusmcleod@mastodon.social

tl;dr — you can now find remote categories and see your tracked/watched categories in /world.

A new alpha version of NodeBB was tagged today: v4.3.0-alpha.3. The biggest change is to the /world route, which up until now showed a list of topics from outside of the local NodeBB instance.

New to this alpha release:

1. A quick search widget was added, allowing you to directly search for remote categories. There is no need to navigate to to the search page to discover new categories.
2. Your list of tracked and watched categories will show at the top of the page.
   • "Tracking" and "Watching" categories—both local and remote—is how content discovery happens in NodeBB. Tracked categories will have new content show up in the "unread" page, while watched categories take that a step further and notify you when new content is posted.
   • Tracking and watching a category will tell NodeBB to subscribe to that remote community for updates

At this time we're continuing to look for stability issues with the remote category integration. We'll be working on QoL fixes as we move into the beta phase this/next week.

tl;dr — how do PieFed/Lemmy/Mbin handle cross-posting?

Currently, when a NodeBB admin moves a topic from the uncategorized pseudo-category into a local category, we federate out an as:Announce, people typically think of that as a "boost" or "share".

That worked fine when the entirety of the category list was your local categories plus the "uncategorized" pseudo-category. However, now that NodeBB is moving towards supporting remote categories (via group actors), this UX makes less sense. We wouldn't want to "move" a topic out of the category it is supposed to be in, just for visibility to other local users. Additionally, topic moving was limited to administrators, and from the get-go we knew it would eventually cause issues because people other than admins would want to share topics to other local users.

This is where the "cross-post" functionality comes in, which is entirely new to NodeBB. I don't think this is new to other AP-enabled threaded discussion software. The idea would be that if a new topic comes in, whether it's uncategorized or not, any user could "cross-post" that topic to a local category, where it would be visible to other users on that instance. On the ActivityPub side, we would then federate out an as:Announce as we already do.

Is this what PieFed/Lemmy/Mbin already do, if they support cross-posting? What other alternative solutions would there be to this problem?

cc @rimu@mastodon.nzoss.nz @andrew_s@piefed.social @nutomic@lemmy.ml @bentigorlich@wehavecookies.social

As far as ActivityPub posts are concerned, how are Hashtags handled?

Is it just like normal and we add them in the posts?