Hi,
I'm developing a browser extension that aggregates notifications from multiple NodeBB forums. Currently, when a user marks a notification as read, I use PUT /api/v3/topics/{tid}/read — but this marks the entire topic as read, not just the specific notification.
What I need:
A REST endpoint to mark a single notification as read by its nid, something like:
PUT /api/v3/notifications/{nid}/read
Why this matters:
The internal mechanism already exists — NodeBB tracks last_read_post_index per user, and the WebSocket event notifications.markRead does exactly this. I'm simply asking for this to be exposed as a REST endpoint, consistent with the existing Write API design.
Use case:
Any third-party client, extension, or integration that wants to respect the user's reading position rather than bulk-marking entire topics.
This would make the NodeBB REST API more complete and consistent with what the WebSocket API already supports.
Thanks!
Essentially, I cannot make a chat public by selecting "verified users" - it will not save.
Video of Bug on imgur: https://imgur.com/a/6GbYPSM
I tried a different browser, to see if it was Librewolf blocking it - but standard "Firefox ESR" had the same issue.
Hi,
I'm developing an integration that relies on NodeBB, and I noticed that while there is an endpoint to fetch notifications, there is currently no way to retrieve the total count of unread notifications directly.
In my use case, I do need to fetch notifications, but without knowing the total unread count in advance, I have to keep paginating through multiple pages just to determine how many unread items exist.
If an unread count were available (for example: GET /api/notifications/unread/count), I could stop fetching as soon as I reach that number, significantly reducing the number of requests and improving efficiency.
Would it be possible to add such an endpoint?
Thanks!
Maybe this is already possible, and I am missing something, but I would like to be able to do the following:
Have whitelisted tags for each category (already possible & implemented )
While also being able to allow users to add their own custom tags that can be used site wide.
This can allow me to require someone to tag something under a certain status, while also allowing users to create their own tags that can be referenced and used throughout the forum.
Currently, it seems to me that I need to choose one or the other, and cannot allow both. It would be nice if I could check a box on a category to allow both simultaneously.
Additionally, it would be useful to have a "site-wide" whitelist that would auto appends to each whitelist for every category, rather than updating every category individually.
It doesn't matter which skin I'm using, topic's images have the grayish background with a bit rounded corners, but images embedded in the same way appear without any additional background, it's just the forum's topic's body element background. Why normal topic embeds' images do have the background? How do I disable it?
I am implementing tribe/clan pages for a video game. It should be something like categories but It would have another tab on the sidebar, own route and own read only display fields (much alike my previous question but for the tribe page). And of course I should be able to fetch all the tribe data through some hook. How do you do that?
I migrated my Nodebb successfully to a new Windows 2025 server from a testing Windows 11 machine. All works so far expect when I try to select a Skin, it is unable to find them. The directory I moved to is different on the new server, it there something telling it to look in the old directory path?
I was asking Claude Desktop some questions about the NodeBB API and it was blocked from https://docs.nodebb.org/
I think it would also be helpful for Claude Code to be able to access those docs as well. In CF just block the "surge bots" from China and Singapore and that should help. Plus, isn't docs a static site?
NodeBB version: 4.10.0
Description
When the chat modal (#chat-modal-{roomId}) is open and the user focuses the textarea inside it, the browser logs the following warning:
Blocked aria-hidden on an element because its descendant retained focus. The focus must not be hidden from assistive technology users.
The modal div keeps aria-hidden="true" while one of its descendants — the .chat-input textarea — holds focus. This is a direct violation of the WAI-ARIA specification, which states that aria-hidden must not be applied to a focused element or any of its ancestors.
Steps to reproduce
Open a chat window (any room).
Click inside the message textarea.
Open the browser DevTools console.
Observe the warning:
Blocked aria-hidden on an element because its descendant retained focus.
Element with focus: <textarea.chat-input …>
Ancestor with aria-hidden: <div.chat-modal … aria-hidden="true" …>
Expected behaviour
aria-hidden="true" should be removed from the chat modal (or never set) when any focusable element inside it receives focus. Screen reader users should be able to interact with the chat textarea without it being hidden from assistive technologies.
Actual behaviour
The modal retains aria-hidden="true" even when its child textarea is focused, causing the focus to silently disappear for screen reader users and breaking keyboard accessibility.
Suggested fix
Two approaches:
1. Remove aria-hidden on focus — listen for focusin events on .chat-input and strip aria-hidden from the closest ancestor that carries it:
document.addEventListener('focusin', (e) => {
if (e.target.classList.contains('chat-input')) {
const modal = e.target.closest('[aria-hidden="true"]');
if (modal) modal.removeAttribute('aria-hidden');
}
});
2. Replace aria-hidden with inert — the inert attribute (now baseline across all major browsers) prevents both focus and AT exposure simultaneously, making this conflict impossible by design:
// Instead of: modal.setAttribute('aria-hidden', 'true');
// Use: modal.setAttribute('inert', '');
Environment
NodeBB: 4.10.0
Browser: reproducible in Chrome, Firefox, Edge
Impact: accessibility regression for keyboard and screen reader users
[image: 1774356228471-1234633f-78a8-464c-82fe-57d352ccad19-image.jpeg]
I am getting same digest email 3 times simulteneouly daily?
what is the reason ? i am not able to find it. It should receive only one time if Digest is enabled.
Hi everyone,
I'm having some trouble managing my NodeBB instance. I’ve noticed that I cannot successfully run updates or perform backups directly through the terminal. It seems I am forced to log in to the server/SSH directly to get these tasks done.
Could someone explain why these actions aren't working via the terminal interface and why server-level access is required for these specific processes?
Thanks for the help!
Hello. I'm implementing a plugin that integrates forum to a system. I need the plugin to show some extra user fields that are pulled from the database, much like the Preferred code editor in this forum, but read only. Is there a plugin for that out there?
Hello everyone,
I'm the administrator of a NodeBB instance (4.9.1) and I also display other remote categories within that instance (the communities of a Lemmy instance I manage).
I would like to point out that I have not opened an issue on Github because I am not sure whether the problem in question is a bug or just the consequence of a deliberate choice by the developers.
I've noticed that sometimes, when a Fediverse user posts a mention of a Lemmy community, while the Lemmy server correctly categorizes that conversation, the NodeBB server displaying the remote category may not "understand" that the post belongs to the community in question.
In the past, when I noticed these anomalies, I could resolve the issue by "moving the thread" using my administrator privileges. When I moved the thread, I was only shown the local category tree, but I could search for remote categories using the search function.
Not anymore.
Has something changed, or am I misremembering?
I hope I explained myself correctly, but since I use an automatic translator, I may have explained the problem incorrectly.
Hi everybody i'm a new member here
I have a few questions- First, is there a age limit for this site? I just wanna make sure I'm not breaking rules by being here
Also does this site support dms? I saw a few posts saying they disappeared I mostly came here because I wanted a few contacts to just yap iykwim :')
Also uhm. Hi i'm Jaye!! My pronouns are He/It and i'm transmasc nice to meet all of you guys!!
Hello friends
A user on our forum reported that when a banned user tries to log in to the forum, the reason for the ban is returned even if the correct password is not entered, allowing anyone to check why another user was banned without having permission to do so.
This bug is a serious privacy security breach, and I would appreciate it if you could fix it.
I used machine translation because I don't speak English, so please forgive me if there are any linguistic errors
Thank you very much
Hi all,
So I'm on Nodebb v3.10.3 and previously I have successfully restored the database to local instances for testing. However, I've been trying to migrate the forum to a different server (My MongoDB is setup and a db dump has been restored).
However, whenever I try to run ./nodebb build, it stops after installing dependencies.
There are no other logs.
When I was trying again by performing ./nodebb setup (instead of build), I did see the following after providing my newly restored DBs URI:
2026-03-20T09:03:03.067Z [9971] - error: admin:username
2026-03-20T09:03:03.067Z [9971] - error: admin:password
2026-03-20T09:03:03.067Z [9971] - error: admin:password:confirm
2026-03-20T09:03:03.068Z [9971] - error: admin:email
I was wondering how to provide these info/overwrite in the DB/config file?
Thank you
Hi everybody,
With spring around the corner (it is currently a balmy 5°C here right now), it's time to get crackin' on a new release of NodeBB!
We focused on a lot of user experience updates this time around, along with tweaking the new /world page that was introduced in v4.9.0. In the backend, lots of optimizations were implemented, which make federation processing (and day-to-day maintenance) faster.
Here's what you can expect from v4.10.0...
Updates to the /world page
The /world page got a makeover in v4.9.0, showcasing a more timeline-based feel. It more accurately represents the breadth of content available on the open social web, such as microblogging, in addition to long-form text (blogs), media-focused items, and everything in between.
We focused on UX updates to this page:
New sorts are available: You can now view just local content, as well as all known content.
The default sort continues to be "your followers", but also includes local content now as well, because you are also tracking those categories!
Guests were barred from /world in v4.9.0, but this is now opened up again. Their view of the /world page shows only local posts.
The /world page can now be set as a default home page.
Duplicate items were showing up when scrolling down /world (especially on very active timelines)
Uploaded images were showing up in the thumbnail/card headers, even if they were embedded in the post itself. The header is now restricted to topic thumbnails (and post attachments, which only occur with remote posts)
Posts are now height-restricted, so long posts don't take up an inordinate amount of space. A "show more" button is available to expand posts in-timeline.
The "quick create" editor at the top of this page now also lets you choose a category to post to. Administrators can update the default value as desired. It defaults to World/Uncategorized.
Alt Text now federating outward
Alt text was always supported in NodeBB, but this was not federated outward to remote instances. This is now supported for uploaded images and externally-linked images. Topic thumbnails do not support alt text at this time.
Soft redirects of remote content
Users unfamiliar with NodeBB were often surprised to see their content cached by NodeBB, despite this being how federation works. In order to reduce surprise, any guest navigating directly to a remote post or remote user will be soft-redirected out to the original source. This goes hand-in-hand with the topic-restriction feature in v4.9.0.
ActivityPub Outboxes published
For ActivityPub developers, we now publish outboxes as of this version.
More profile pics!
@baris improved the avatar handling code so that NodeBB now remembers your last three used avatars, allowing you to toggle between them. You will no longer need to upload new pictures if you want to switch between previously-used avatars!
Follow counts better synchronized
@[email protected] reported awhile back that follow counts in user pages were off. The logic was updated and should be back in sync with the real values once you follow/unfollow a user.
https://github.com/NodeBB/nodebb-theme-harmony/blob/main/scss/common.scss#L95
That css applies to images in post and chat messages. You can override it in your custom css.
