ekk

The only problematic account I have encountered so far is [email protected] 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).

I wasn't sure if this option would still be available to us, but the new season will continue to be shown on TV.

I thought it would be good to note this in case anyone wants to avoid a Paramount+ subscription for, you know, reasons.

Hello, recently I've came across a problem with the image saving in my nodebb. When the server restarts all the image data is lost. I would like to ask
1.how images are exactly saved?
2. can i save them in the database?
3. or is there any better way to save images on nodebb? Maybe some plugins?

Thanks in advance for any discussion/comments on this topic

Apologies again for cancelling the WG meeting again, as I have a conflict with another meeting held at the same time.

We'll reconvene in August!

This question was asked by [email protected] on Dot Social's latest episode about the blogosphere on Fedi.

[email protected]: "we wanted to connect Ghost blogs to each other, but then we discovered ActivityPub"

[email protected]: "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.

ska there should be a user setting page for push notifications, and they are activated on a per-device level.

Does the toggle activate for you?

hello,
I can't quite figure out how push notifications work since I can't see/activate them even here at community.nodebb.org.

I am using NodeBB 4.4.4.

I see that in the settings there is and active "Push Notifications (via Push API) but nowhere and nowhere do I ever get a suggestion to enable browser notifications.

Is there something I don't understand that needs to be enabled that I don't see or do they work differently than I imagine?

Thanks!

I recently enabled federation support in NodeBB 4.4.4, hoping to be able to follow accounts here on my own site. Unfortunately it doesn't seem to be functioning. I can look up users and profiles, but they all have zero posts listed and the follow requests that I send never actually get through (I tried sending one to myself here). I'm a beginner to all this, so there is probably something that I'm missing Does anyone have any suggestions?

Example, Lemmy.ml and Lemmy.world have duplicate communities aren't connected at all. So we are artificially isolating groups more and making it confusing for would be converts.

Short and too the point

I seem to be unable to follow the handle @[email protected] from nodebb, pixelfed, misskey as well as mastodon, although I can follow som other threads handles. Who knows when @[email protected] will solve the federation problem.

I’m writing a NodeBB plugin and need to let User A inherit all of User B’s permissions, including:

• Creating topics and replies on their behalf

• Changing their password

• Chatting as them

• Editing or deleting their existing posts

In other words, I want two linked accounts so that logging in as User A gives full control over User B’s account. What’s the best way to implement this in my plugin?

I tried going through all the permission hooks but didn’t find anything suitable.

Appreciate any help—thanks!

Opening a topic on our forum in Brave results in a redirect loop: instead of returning a 200 status, it returns a 302 status with a Location header pointing to the same URL (at which point it repeats the same request and gets the same response).

• The issue only happens in Brave; the site works correctly in Chrome and Safari.
• The issue does not happen when running the site locally.
• I cannot replicate the issue on community.nodebb.org.
• There are no errors in the logs.
• If left running for long enough, occasionally it will break out of the loop and show the correct page.
• We recently installed a fork of github.com/julianlam/nodebb-plugin-session-sharing (modified to get user data from Keycloak's userinfo endpoint rather than directly from the access token); the issue seems to be related to this plugin, since it went away when I deactivated the plugin and started happening again after I reactivated it.

This applies to any of the microblogging software. Akkoma, IceShrimp, etc. I go to any Lemmy instance, big or small, and the up/downvote data and replies are basically all the same. The same goes for Peertube, and most services that aren't Mastodon and the gang. Why is this? Is it because of older design? Unexpected issues cropping up with scale? It seems to be such a big struggle over there, but for everyone else, it's whatevs.

I would love to permanently reside on a smaller Mastodon instance or host my own, but I often find that many posts are unavailable and a lot of replies I want to reply to don't exist. It is an incredibly frustrating experience.

Good news in privacy for ActivityPub. The first early draft of the MLS over ActivityPub specification went out this week. It’s been part of my work on our E2EE for ActivityPub project at the Social Web Foundation.

Messaging Layer Security (MLS) is an IETF standard for end-to-end encrypted (E2EE) messaging. It lets people on laptops and phones communicate with each other in a secure way that no one in between can see.

MLS is designed to use pluggable lower-level protocols. This specification defines an envelope format for distributing MLS messages through the network, and an Activity Streams 2.0 profile for the packets of application data stored inside the messages.

This specification is ready for review from both ActivityPub developers and security analysts. It’s time to start making proof-of-concept implementations and testing interoperability.

The best place to make comments or report problems is on the ActivityPub E2EE GitHub repo issues list. I’m looking forward to these next steps!

Hello guys, I'd like to know, what should I do to login the user from my own SSO with admin rights? Do I need to give the role: admin at /userinfo endpoint or how it is done?

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, [email protected] 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 [email protected] in FEP f228 (as an extension of FEPs 7888 by [email protected] and 171b by [email protected]), 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?

The team behind Bridgy Fed is working on a new tool that helps people migrate their accounts between Mastodon and Bluesky. It could end up being a core piece of infrastructure for helping people on other platforms with moving to the Fediverse as well.

Due to a conflict with FediForum (running 5th to 7th June), the ForumWG will not be meeting. Additionally I am away for most of June so cannot reschedule the meeting for later this month.

I will be at FediForum to re-introduce the ForumWG and highlight what we've accomplished this past year, as well as to hopefully draw in some new interested parties.

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.

For some reason my nodebb deployment (Docker) has no space between the widgets

This is happening on both sidebar widgets and bottom of page widgets.

i am on nodebb v4.4.1 latest docker image
(A fresh install of docker does not have this problem, although it's been only a couple of weeks since this install)
(An earlier version of the docker backup of the same site does not have this issue)