@bh4-tech yes, sorry for late response, I was just quite busy the last few weeks I'm planning to make the plugin work, but sadly it'll need a bit more work than just making it compatible with current NodeBB version as it's using a deprecated firebase API that's going to stop working this June...

And it's doing that because the new API requires a bit more setup to work... So this will need to be implemented.

I'll probably start working on it mid-June, once this semester ends for me, since as I mentioned I'm a bit too busy right now.

@eeeee said in Do you have limited or full access to your host?:

I did have this conversation previously with @phenomlab, and I recall we were looking at around $40 a month upwards for a dedicated host

If you're fine with Oracle and willing to ensure there is some constant load on your server (from my experience just running Mongo+Redis with some cache for NodeBB will do fine for their usage detection), Oracle Cloud Infrastructure is still waving a huge free tier carrot in the form of 4 ARM64 cores w/24GB of RAM w/200GB total disk space (you can distribute these across up to 4VMs)

Otherwise - Hetzner has a great offer. NodeBB deployments are mostly RAM-bound, so I'd personally go for ARM here too - since NodeBB doesn't really have any x86-specific dependencies (also, if you want to save a buck, or rather €0.60, you can put an IPv6-only server behind Cloudflare and get IPv4 connectivity for free ).

You really don't need dedicated unless you really have a lot of users - it may be worth it if you want to host many services (since you can run your own VMs there) or if you actually need a full CPU-worth of performance, but again - the heaviest part of NodeBB is typically the database (and maybe caches), you're almost certainly not using that much processing power to serve a forum

(As for the experience topic, I'm not sure if I can really comment when I'm still in my early 20s, below the lowest concrete number thrown here )

@[email protected] it was actually because of @ in actor IDs - the codepath for choosing a webfinger lookup over just accepting the URL as the ID only checked for its presence, and the code for webfinger lookups was only meant to run for the acct: protocol.

So yeah, not WP fault at all, just a combination of a bug and missing feature Now both should be fixed.

@[email protected] Should be fixed now in https://github.com/NodeBB/NodeBB/commit/700016649d25ee5bc6c3fa17e03003677d7f5b5d (not yet deployed here).

The issue was that apparently for the blog actor WP sent actor URI and not username@host - which AFAIK is perfectly valid, NodeBB just assumed the latter was always the case

@julian said in April Update on ActivityPub Development:

Oh, one last (huge!) thing to add is that @oplik0 added basic support for the Flag activity.

Accepting this means that reports from other servers can be appropriately responded to from NodeBB.

While it's not yet on the version running here, upstream the Flag activity now works two-way and even sends/handles Undo for rescinding/deleting a flag (did you know that NodeBB supported rescinding a report? Probably not since it wasn't actually exposed via any UI, just in the API... Well, I'm finally fixing that too ). I think we might be the first/only AP service that can undo flags (but maybe someone will correct me, I only checked Mastodon, Mbin and Lemmy).

So very soon you'll be able to report something here and the moderators on the original instance will see it too.

Some small quirks currently:

• Mastodon uses the instance agent for reports, I think most other software reports as the user instead and the former messes a bit with NodeBB report deduplication - so sadly for now you can only get one report per Mastodon instance, others will be rejected as duplicate.
• The initial reason choice in Mastodon doesn't seem to be federated, just the user-added note...
  • for NodeBB default reasons are just shortcuts to basic user notes in a report...
• For now reports are only forwarded to source instance. Mastodon offers forwarding to all mentioned instances, which makes some sense - since instances that are mentioned inside are very likely to contain that post anyway, so if it's something that should be removed it might be good for them to know too.
• As I mentioned I don't think anything else supports rescinding reports yet

@haizhi "unescaping" HTML entities is fairly simple even without a full JS environment - it's essentially just find-and-replace with a dictionary.

More specifically, you should only need to replace:

• & with &
• ' with '
• < with <
• > with >
• / with /
• \ with \
• ` with `

I'm not sure what WeChat mini programs are written in (quick google search in English yielded just marketing for how good they are... not how they're made), but I assume you should be able to do some kind of string.replace.

And it's quite likely the standard library of your language or some other library you're using will have a functions to do that already. E.g. python has html module, C# has HttpUtility.HtmlDecode, for Java a lot of libraries (e.g. Apache Commons or Spring) provide something, etc.

@o-o said in Why does nodebb check dependencies programmatically?:

It runs even if it's preceded by an npm install, so I'm not sure what problem it's finding.

It doesn't if it finds the correct dependencies. You can see in the code above this what the check does - verify that package.json of NodeBB dependencies matches the semver ranges specified for a given NodeBB version. Importantly, it does so only for a few deps - I'm not actually sure what criteria they were chosen on, but as long as you install the right versions of nconf (required for NodeBB config), async, chalk (probably because it's in CLI code?), commander, lodash and lru-cache NodeBB should not try to install anything.

The other issue is that if you use a faster package manager like pnpm, it's still piping everything through npm.

NodeBB can actually use npm, cnpm, pnpm or yarn depending on corepack's packageManager key in package.json, package_manager setting in config.json (https://docs.nodebb.org/configuring/config/) or lock files, in that order (so corepack setting takes precedence over the rest).

But you need to somehow tell NodeBB you're using something else than npm - since due to being shipped with node it's the obvious default.

Not built-in and there sadly isn't a universal sign in standard in the fediverse.

Instead Mastodon API allows for dynamic OAuth implementation where the app (here NodeBB) can register itself on the user's server and then allow the user to sign in via that server. This should cover most of fediverse in practice (since even software that isn't Mastodon tries to implement its API nowadays).
So in practice it'd be possible to implement this via a plugin mostly similar to existing OAuth plugins.

As for restrictions, you can probably just make such plugin add some "fediverse" role and just configure persmissions using this.

@DownPW said in NodeBB 3.6.0 minimum NodeJS version.:

@baris

Node JS v18.17.1 is good or not ?

Yes, you just need a currently supported LTS version (and 18.17.1 is just a few months old) - generally NodeBB will move support along with node, and there shouldn't be any breaking changes within a major version, so all or most v18 versions should be supported at least until April 2025.

How I can update to the latest stable versions of 18.x ? I do not remember.

Depends on your OS and the way you originally installed NodeJS. Assuming you're on Ubuntu and followed NodeBB docs for NodeJS installation (that is, used nodesource):

• for updating to a newer version from v18 branch, sudo apt update and sudo apt upgrade should suffice
• for updating to v20, running the setup_current (instead of setup_lts) script should work:

curl -sL https://deb.nodesource.com/setup_current.x | sudo -E bash -
sudo apt upgrade

@blackd-t said in NodeBB 3.6.0 minimum NodeJS version.:

What's the benefit off this though !

The old request library is unmaintained and has a lot of issues. It is actually marked as deprecated on NPM. It's dead and it was clear for quite some time that it needed replacement. It even needed a separate package to add proper promise support, that's how old it was. It's less "it's better now" and more of just cleaning up technical debt.

The issue from my understanding is that there has been an obvious replacement for a long time - fetch API, which has been natively available in browsers for a while. So the question was "replace now with some other library then with fetch, or wait for fetch" (or keep using that library, risking same issue request experienced).
It seems NodeBB decided to wait, especially since with the faster EoL of Node 16 (faster due to to OpenSSL 1.1 EoL) it seemed right around the corner for some time.

Also, in general NodeBB follows NodeJS lifecycle, so officially only Node versions that are still supported are tested in NodeBB. Older versions can work, but there is no guarantee and generally I don't think NodeBB has any policy in place to wait with adopting newer features as long as they're in all supported Node versions.

Nice to see they changed this to non-critical

Anyway, this is the actual issue from the structured data update - the changes just weren't released yet (harmony 1.1.102 was the first release with them, but it needs slight changes to NodeBB itself that are still only on develop branch)

@Cannybird Your MongoDB instance is bound to the loopback interface. You should access it under 127.0.0.1 instead of your server external IP address. When running setup (or now in your config.json) you should change your MongoDB ip to 127.0.0.1

Similarly if you run mongosh mongodb://35.233.236.85:27017 it probably won't work.

If you want MongoDB to respond on any IP, you can bind it to 0.0.0.0 instead, but unless you're planning on accessing it directly from a remote location, you probably don't want to do that (or at least should lock the port down using some firewall).

@dave1904 said in Impossible to install NodeBB!:

According to the docs, first install mongodb then nodejs. But not sure if it makes any difference.

It doesn't, fortunately (or at least, really shouldn't - if you MongoDB installation affects your NodeJS install, something went really wrong)

@NodeHam This is actually a small separate issue with json+ld metadata generated by question-and-answer plugin. I just submitted a fix here: https://github.com/NodeBB/nodebb-plugin-question-and-answer/pull/102
edit: it's merged now, version 1.2.5 of the plugin should resolve this issue

There are two OpenAPI specifications, you can find them exposed via redoc under/debug/spec/read and /debug/spec/write (note: these paths are only there when NodeBB is started in development mode, that is when NODE_ENV=development).
The specification files themselves can be found under /assets/openapi/read.yaml//assets/openapi/write.yaml even on production instances.

If you only need to see the latest version (since I don't think there are historic ones hosted, it's just updated) the API docs are also available online: https://docs.nodebb.org/api/read/ and https://docs.nodebb.org/api/write/

@julian said in Pushing forums in the AI SEO domination era:

Edit: We currently use microdata to present our metadata, so that may need adjusting. Might be when we moved to Harmony that wasn't ported over.

AFAICT it's Google who isn't following the spec here and the original structured data was valid (e.g. schema.org validator doesn't report any errors with it), but I guess Google has some more strict preferences, and in the end what matters is what Google believes is correct (gotta love monopolies).

Hah, didn't I call it when I said that the ride of LLMs and ChatGPT, et al. would mean that actual user-generated content would become all the more valuable? It seems Google is coming to that conclusion too.

Paid API access support when?

It seems that Google is pushing for more structured data, with focus on content actually made by humans. They just announced support for DiscussionForumPosting structured data, and along with a "perspectives" filter and Discussions and Forums "category" in results that are trying to highlight social media/forum discussions, it seems their response to AI generated content breaking SEO (see this viral thread from founder of a company actively making the web worse) is promoting user-generated content and push the problem back to social media and forum moderation (see also their updates to quality rater guidelines adding an "experience" metric).

But why does structured data help here? Why only now? Well, I imagine it's also their response to LLMs. They didn't need that much structured data when one could be reasonably sure the free-flowing text was done by humans. So Google focused on analyzing the text themselves and didn't really need the websites to tell them what that is, since what mattered was the content more than who made the content. Now creating new text that looks human to their algorithms is becoming cheap, and trying to automatically moderate the entire internet isn't feasible. So it seems Google realized that they can't trust content providers to provide decent content, and while obviously bots are rampant in user-generated content too, it's not them who have to deal with moderation. Wikipedia and even Reddit seem to be more trustworthy than news articles or blogs for many issues (e.g. product reviews), so they need to adjust to not lose users (even if they are very much part of the issue themselves).

Anyway, NodeBB already implements this - so what's changing is that Google should now be able to pick up this metadata.
I'm saying should because it seems to be slightly broken currently - it's throwing errors because of invalid name data type for NodeBB (which from my understanding is done correctly here and should be serialized into text from the href value), and it seems to not even pick up on this on Discourse even though it implements it too. But I'm assuming these are implementation issues and will either be fixed by Google or worked around on forum software soon.

EDIT: it was fixed on NodeBB side: https://search.google.com/test/rich-results/result?id=wCSb0uOG9XPulXXSxHFZnA

The point is, we're probably going to see resurgence of forums in search results. Probably along with more forum spam, but I hope the increased visibility will be worth the moderation burden. And maybe people won't need to add site:reddit.com to google searches soon

Side note: does this mean web 3.0 might actually somewhat succeed due to SEO benefits? I mean the "semantic web" web 3.0, not the cryptocurrency-based "web3" one.

I mean, it's important to note that I'm talking about AI as moderation help, not sole moderation. Auto-flagging, or putting in moderation queue instead of making the post public.

And almost regardless of ideology, I hope most people see the need for moderation - at least on the basic spam level. And for most people this quickly escalates to illegal content, and some general content policies (things like obvious harassment, often nudity, etc.). And as the issue of the content that needs moderation gets worse (gotta love AI companies selling the cure for the disease they are themselves creating ) there is a need for new tools in that area.

Ultimately, everyone wants to make a "free speech platform" but the way internet works is utterly incompatible with fully embracing this idea. And sadly, making it work differently may be much worse (and more dystopian) than just moderating.

@omega said in OpenAl Plugin:

None of this ChatGPT/AI stuff is at it seems, and it can not be judged or assessed in totality as some technical challenge - The vampire can only come into your house invited.

I kind of agree - I hate that so many people seem to be treating "hallucinations" as some bug that can just be fixed and not part of the fundamental way these models work, and just cherry-pick the good outputs ignoring all the work that goes into getting them (seriously - how the hell do people program using ChatGPT? Like, Copilot is useful for boilerplate and just as a good autocomplete, but for actually writing anything more complex than algorithmic class assignments it takes me more work to get a decent code from a chatbot than just writing it myself).

But a good autocomplete is still worth something, and even the current "AI" can do a lot more. I consider them incredibly useful, but even more overrated, tools. This is why I'm suggesting using it not as a response generator (which will produce a lot of garbage, even if some results will be good and it's an easy way to say you followed a trend).

Also, another thing that both Discourse and NodeBB now have (see chatGPTmoderator plugin) is AI-based moderation, which is actually great - a lot of moderation is already somewhat automated, and this is just automation that works far better with text semantics and not just literal words or obvious usage patterns. It's not perfect by any stretch of imagination, but it can allow for more efficient moderation and that may be all that's needed.

@Henryk said in NodeBB + ReactJS:

React, for example, has eaten the world and birthed many alternatives with similar ergonomics, smaller footprints and faster renders. Meanwhile nodebb is using... jQuery and BenchpressJS? Oof.

I mean, NodeBB is slowly moving away from jQuery, but the issue is the plugin ecosystem - removing jQuery would be a very breaking change, much, much bigger than the move from less to scss (since most plugins would still at least work even with their css broken, and most of the time the transition didn't actually require rewriting anything unless one was using more advanced features). I suspect it'll end up moving to something like cash at some point.

And I suspect you're confusing Benchpress with some other templating engine, since (which has both positive and negative aspects) it's basically used only by NodeBB and tailored towards it. It's a tiny and from what I've seen fairly well optimized templating engine - I suspect it'd be faster than react for templates just because it's significantly less complex.

I honestly imagine that if NodeBB was written, or fully rewritten, now it'd be using some framework, likely React/Preact. But the issue is that when you have a long-lived codebase with existing ecosystem the benefits need to be much larger than for the initial choice. Because even with diminishing returns on smaller improvements, the required amount of work makes it hard for a rewrite to beat them, much more so if the changes will require more changes by third party developers too. And you still have to ask yourself if working on DX and performance is worth the opportunity cost, or maybe it's "good enough" and you should focus your efforts elsewhere.

It's annoying, and if I had the time and will to develop forum software from scratch my tech stack would look different than NodeBB, but as with many things it's only easy on the surface and I still prefer the way NodeBB is built to php of Flarum (also - they're an example of an early framework bet that didn't work out ecosystem-wise, since mithril ended with a far smaller community than React and has gone through a few periods when it had years between new releases) or the weirdly dockerized Ruby on Rails w/ ember.js that Discourse uses.
I may not be a big fan of jQuery, but at least even when writing for core I have the choice of just not using it and going with modern JS instead.

@crazycells said in Future of Post Sharing Options?:

hi @oplik0 , do you mean something like this "share" button? Actually, this would solve all the problems... Because it opens up all the options including text sharing and it is better than what I proposed...

Yup, it's a pretty nice API, though as I mentioned it still has issues with support on desktops despite being in the works for 7 years now (which is largely because Windows doesn't have good story around sharing, and even after a few minutes of googling and even trying to get bing chat to spit something out I have no idea how the hell you integrate with it when writing a native app. EDIT: after writing this I remembered that it was added when MS was pushing UWP, and searching specifically for UWP share integration actually yielded results. So you can guess why no one is using it [tbf you can now make win32 apps use this API, but only because MS allowed adding UWP components to standard apps, and it takes that to interact with the new API])

@baris said in OpenAl Plugin:

Same post-queue rules would apply so not sure how it's different than some user creating an account and posting spam generated by chat-gpt

It stops being their API usage

But yeah, with the UX mentioned here it wouldn't really be abusable, but I feel it'd end up being a novelty rather than something useful.
My main issue is the question of when it'd be more useful to tag the chatbot than use its own interface.

One idea is Q&A forums, where providing an "attempted answer" (especially if it's using data from the forum) and still having the opportunity to see the community clarify or correct that may be useful - but I'd say automatically feeding question topics for a response may be better.

Probably the most useful, but also more abusable, would be to integrate a chatbot with the composer, so that it's useful for making posts, rather than after one makes a post (in part also because my experience with even newer models is that they still need to be very highly guided to do anything even slightly complex, so the feedback loop needs to be faster than posts).