NodeBB Development

@tankerkiller125 I too opt for /recent as I prefer to see all activity rather than categories

@baris 👏 👏 👏 🔥

We recently received some inquiries about how long we will support 1.x and 2.x with security fixes.

We also released https://github.com/NodeBB/NodeBB/releases/tag/v2.8.16 and https://github.com/NodeBB/NodeBB/releases/tag/v1.19.12 containing some of the fixes from the 3.x line. If you are not able to upgrade to 3.x we encourage you to upgrade to these releases.

@phenomlab very true. A lot of talented people have done some surprisingly cool things with just the custom css panel.

@baris All good, after I ran some system updates, then did another build and this time, no error!

@julian said in [RFC] Change to the quick-reply `toPid` value?:

While it is true that you can know at-a-glance whether a post has replies, I'd want to know what specific value it provides to you as an end user, besides the tautological one (i.e. it provides value when showing a post has replies, because it shows it has replies).

For me one of the primary values of that information is found in picking up the thread of a conversation between two or more users. Traditionally forums have only had back-links, and the only way to read a conversation was to start at the very end and follow the reply-links through to the beginning, perhaps opening each post in a new tab so they could then be read sequentially once you find the beginning. The replies dropdown allows me to start at the beginning and follow the conversation as it bobs and weaves randomly through the thread.

The broader point is consistency of expectation. If users aren't reading each post of the thread and they want to do what I just described, they could train themselves to <first check to see if there is a replies dropdown; if not, check to see if the next post is a reply; if both of these conditions fail then I am at the end of the conversation>. But more consistency makes it easier to accomplish this use case, as well as the simpler use case of gaining information about whether a post has received replies.

(Just my $0.02. I am coming from long-form discussion forums where it can be hard to follow a conversation from post to post, where users generally do not read each post in a thread, and where time zone differences tend to place gaps between responses.)

FWIW I think there was a bug in a version of Discourse (or it was intentional I have no idea) but if a post was edited or other non-contributory actions (lie moderation) were done, it would bump the topic, again think it experience of it for too long.

It caused a lot of confusion and sometimes in strained circumstances, people would interpret it in a negative way and lose the head. Rare, but it did happen once or twice. Obviously this was more random than the proposition above.

I've never used a bump feature ever, other than old school "bump" which is sometimes a humorous affair and clearly signals the bump.

I rather create and see created topics that will stand the time and value that need regular updating., constant maintaining because they are hot or timelessly useful. I also would think about more editorial management than allowing social management of information, because the "social" is over done IMHO and now Ai can be just as "social" as the next bot. 😉

We will look into it 😄

@baris Perfect. Thanks

@julian Thanks, now working
I translated a string and was able to pull it right away!

A bug in our socket.io authentication code can result in Cross-Site WebSocket Hijacking (CSWSH)

Affected versions <2.8.13 & <3.1.3

We have resolved this in the latest version of NodeBB(2.8.13 & 3.1.3), and the fix has already been rolled out as a patch on all of our hosted customers.

The fix is included in the latest 2.8.13 & 3.1.3 releases
https://github.com/NodeBB/NodeBB/releases/tag/v2.8.13
https://github.com/NodeBB/NodeBB/releases/tag/v3.1.3

@julian said in Now publishing images to GitHub Container Registry + Registry migration FAQ:

ghcr.io/NodeBB/NodeBB (case insensitive)

thanks, just changed the repository, but i got error from docker compose, it told me it must be all lowercase 🤠 (not case insensitive)

Hi @Redbeanw44602! Thanks for voicing your concerns.

In this particular change, the behaviour is only applied if explicitly enabled by the site admin. The default behaviour is unchanged: guests and regular users without email confirmed are able to browse the forum equally.

In the case where an admin wants to gate content behind email verification, they can also opt to use the verified-users privilege group.

Yesterday, I wrote a teaser about technical debt in NodeBB:

In our specific case, there are other factors that also cause technical debt to incur outside of trying to "move fast and break things". Technologies change, design patterns shift, user expectations are adjusted, or scope is expanded after-the-fact. All of these could cause even a well-designed system to incur some form of technical debt simply due to the fact that you don't know how a given feature will evolve over time.

Our experience with technical debt is similar to others' in many ways, although I feel lucky in that we're able to approach it a lot more differently than others.

Specifically, many definitions speak of technical debt as something incurred in the pursuit of faster results. A trade-off that makes sense at the time due to time constraints.

In our case, technical debt builds most often because we have a single vision for what a feature could be, but do not have the additional context to realize just how that feature could be used in the future.

A good example of technical debt is the user groups system. When initially conceived, a user group was akin to a Facebook group. A way for users to gather together under a common banner. We later expanded this with the formation of the group badge, which is still in NodeBB today.

What we quickly came to realize was that there were tons of benefits that could be realized with a common user grouping system. Gamification could be tied to user groups, tagging groups of users made sense, and most importantly, privileges could be tied to user groups.

Whenever we ended up in a situation where user groupings made sense, we made use of the pre-existing user groups system. It ended up simplifying a lot of things because we had that groups system that we knew would work predictably. It meant that separate, contained systems need not be re-invented every time you needed to segregate users apart.

The debt? User groups as per the initial design no numeric identifiers. A user has a uid, a topic has a tid, a category has a cid, a post has a pid, you get the idea. So when it came time to create groups, I gave it some thought and decided that group IDs were unnecessary, as the primary identifier would be the group name itself. After all, why would a forum want two groups named the same thing? Madness!

In hindsight, of course, a group ID system would make a lot more sense. It'd make even more sense given that the Write API works almost exclusively on those IDs (groups are the one exception).

We're lucky in that while the debt exists, its impact on day-to-day development is fairly minimal. Other examples of debt are more impactful, but I can't easily think of any because we've addressed a lot of them already!

A neat little side-benefit of the fact that NodeBB is open-source is that we can choose our priorities more freely as developers. While NodeBB Inc. itself pursues paid contract work and paid support, we often do have time in between paid work to spend time on the core product itself. While the draw is always there to develop new and exciting features, we have fostered an internal developer culture to address technical debt over time, as we consider any ease of maintenance burden is a win that is compounded over time. Likewise, any impactful technical debt often hinders development, and continuing to hack away around technical debt just makes it harder to resolve altogether.

The other part of it is that our source code is open. If we are lazy and take shortcuts, someone will eventually call us out on it. 😓

I like it very much, and I am willing to use it for secondary development. The large screen and almost full-screen experience on the mobile phone make me feel like using a native app

In 2020-2021 years I tried NodeBB for the first time, it seems then it was the ~1.5 version of the forum and I remember exactly what I fell in love with at first sight - the navigator in the header 🙂

F88C54E1-721F-4EB9-97E5-5D2550CF28D2.jpeg

Looking forward to v3 and harmony. I’ve been running the alpha and beta in Production for quite some time now. Super solid update.

We haven't released a new RC but there are some small fixes in harmony and core since the last rc. If you want to grab those you can update core and run upgrade. On develop branch.

@DownPW said in NodeBB v3.0.0-rc.1 — The release candidate:

./nodebb stop
git fetch && git checkout develop && git reset --hard origin/develop
./nodebb upgrade
./nodebb start

Thanks. My test forum is now on v3.0.0-rc.1.

@julian @baris Thanks for v3 🤓

@DownPW thanks! The less time of mine the spammers waste, the better.