julian

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

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.

You might've heard that search sucks on software X... maybe software Y... definitely on software Z. The default one kind of sucks on NodeBB too, admittedly.

But why? It's because search is really frickin' hard to get right, and expensive to get good at.

Remember that Google started as a search company, and they became king because they got really good at it, and it was their only product (at the time, anyway!)

The easiest type of search is "full text" search. It matches words exactly based on what you type in. For example if you search lemmy it would match posts that include the word lemmy but depending on how the content was indexed, might not match lemmy.world, lemmy.ca, lemmyverse, etc.

From there you start adding complexity like supporting AND and OR. You support partial matches (lem returns posts containing lemmy and lemmings).

Add more logic to remove stop words and articles like a, the, etc.

Put in some sorting logic to rank stuff higher (what's your algo? Recency? Votes? etc.)

That's just the tip of the iceberg... this problem domain is so vast that entire companies have been built around just providing searching as a service (e.g. Algolia), and it isn't cheap!

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.

Speed run through the fediverse baby!

There have been some scattered feedback on a change I made for v4.0.0 that caught some people off-guard: Uploaded media is now shown in addition to topic thumbnails.

I'll start with why this change was made, and then solicit feedback.

The why

v4.0.0 introduced ActivityPub integration into NodeBB. This added dimension meant that content was consumed in a manner that was similar, but unfamiliar to NodeBB, and so much of the work involved normalizing that data into a format that made sense. (As an aside, I tell people that that's pretty much 99% of my job — glueing together APIs. I jest, but it's also basically true.)

One of those unfamiliar aspects was uploaded media in the form of attachments. NodeBB had discrete concepts of inline media and topic thumbnails, but attachments were something different entirely. Attachments were not inlined in the text (they tended to be added before or after the main content), and thumbnails were images only, while attachments could be lots of other things.

The second part was that a lot of the content I received relied on media to do the heavy lifting. Oftentimes the text would be minimal and in response to the attachment. After all, a picture's worth a thousand words.

Given those two things, I allowed NodeBB to consume and store attachments separately, and updated the topic thumbnail retrieval logic to pull media from both post attachments and inline media. That retrieval logic is what governs what you see next to the title. I also decided on the all-in approach because while NodeBB has multiple ways of slotting media, majority of ActivityPub software generally only uses attachments. This means both inline media and topic thumbnails were unceremoniously shoved into attachments when federating outward. There is movement toward changing this, and so this rationale may no longer make sense today.

I initially did have concerns that perhaps this would dilute the meaning and specificity of the "topic thumbnail", but I also wagered that the UX improvement of promoting any and all media found would be of greater benefit.

Your turn — feedback!

Maybe I'm wrong!

• Perhaps the media row is best used to showcase topic thumbnails and post attachments only (not inlined media.)
• Perhaps a configurable option would appease all folks (although I'm usually loathe to add options purely for that reason.)

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.

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

We just released version 4.1.0 of NodeBB. Here are the latest features you can now take advantage of!

As an aside, for the first time in a long while, both @baris and I are working on the same codebase again. Up until version 4 was released, I'd been working on the activitypub branch and periodically merging in the latest changes from develop. It's nice to be home! :house_with_garden:

Improved federation of Group actors :left_speech_bubble:

We've improved the activity synchronization for followed group actors. Local updates/likes/etc. are now federated outward by the category in addition to those from remote users. Thanks to @rimu@piefed.social and @freamon who worked with me on debugging this one.

Mentions and Emoji now federating out in source.content :wave:

Emoji and mentions have been sent out to followers since v4, but that wasn't reflected in the raw markdown content that we also send along. That has been remediated now, and this change improves nodebb-to-nodebb federation.

Video object type now parseable :tv:

NodeBB is now able to ingest Peertube Video objects, and render then in a topic just like other pieces of content. Thanks @deadsuperhero@forum.wedistribute.org for prodding me to get this sorted out!