julian

NodeBB will be making an appearance at this year's FOSDEM!

I'll like be present at the Social Web dev room during FOSDEM itself, and will be presenting a talk at the Social Web After Hours event alongside @[email protected], @[email protected], and @[email protected] at Hackerspace Brussels (HSBXL), on Sunday evening.

I'll be talking up the SWICG Forum and Threaded Discussions Task Force, and what we're working on to solve one of fedi's hard problems: combating the notion that "the fediverse is quiet". Come and listen!

Thank you to the great folks at @[email protected], who have kindly funded my way there this year.

There have been some reports (@bh4-tech I believe?) that NodeBB does not successfully federate with Threads. Looking into the issue, I discovered that it is only this domain community.nodebb.org that is unable to get/send activites with Threads.net.

After some help from @[email protected] @[email protected] and @[email protected], I have discovered that our domain has been blocked by Threads for not serving up a public feed.

This is the feed they're specifically looking for. If your application does not serve it, it will be automatically blocked at some point. There is an appeal form you can fill out so your server can be re-instated.

• At this time, Threads seems to see the lack of the public feed as a non-starter for AP federation.
• As an AP software implementor, in order for admins running NodeBB to not have their servers auto-blocked, I will have to implement this API
• Threads relying on the existence of a Mastodon-specific API suggests that they're federating with Mastodon only (perhaps as part of a limited experiment), or that it is an oversight that needs to be fixed on their end with time.

Therefore if you wish for your NodeBB to federate with Threads, my guidance at this time is to whitelist your domain with Threads directly by filling out the form.

@[email protected] Thought you might be interested... I attempted to follow @[email protected] from NodeBB and found a fun little race condition!

NodeBB sends the follow and waits for the request to complete before recording the details of the follow (for backreferencing the eventual accept). WordPress seems to fire back the Accept, and then wraps up the response.

I imagine a lot of implementors do the same, but it just so happens that WordPress' response time (or at least the swf site's) is juuust slow enough to reliably have the Accept come in before the Follow finishes.

So NodeBB hadn't recorded the follow request when it received the Accept, so the follow failed :laughing:

I've adjusted my code now so the backreference is saved before sending the Follow.

As part of security checking for incoming events, we check that the keyId sent in the HTTP signature is actually owned by the actor that the activity came from. This is to guard against activity spoofing from separate users at the same server (e.g. user B@server pretends to send a Create(Note) from user A@server).

Our check is pretty simple, the keyId matched against the public key id as retrieved from the actor.

Except it fails for PeerTube because:

• PeerTube's actors all have the #main-key suffix on their public key IDs (e.g. https://tilvids.com/accounts/thelinuxexperiment#main-key)
• The HTTP Signature's keyId does not include the #main-key suffix (e.g. https://tilvids.com/accounts/thelinuxexperiment)

So the key ownership cross-check fails.

I could adjust the logic to strip out the URL's hash, but I was wondering if that was actually secure. I assume this is what is already done since PeerTube successfully federates with other softwares.

I am once again astounded by how unreasonably effective FEP 1b12 is at federating content completely.

On NodeBB I have a list of "popular" topics, which is mainly populated based on number of posts within a given time period. For most content from Mastodon-based servers, this supplies a decent signal of a given topic's popularity. The more people you follow, the more effective it is, but overall it's pretty shit at getting you the whole conversation.

Enter 1b12, Lemmy's preferred federation method. Follow a community actor and you start receiving everything that happens in that community. Replies, likes, the whole lot.

It also absolutely dominates my popular feed. It's all Lemmy stuff now because the Mastodon stuff literally can't compare.

Albeit the SNR is a tad lower, so give and take...

ActivityPub introduced to NodeBB the concept of sharing/announcing/boosting, and we enthusiastically supported this as a method of content discovery.

While we were processing these activities (and publishing our own), we weren't actively tracking them internally. That has changed in the latest commits (soon to be RC5); shared content from both local and remote users are tracked internally and can be viewed in the user profile.

For example, here is c/comicstrips from lemmy.world. As it is a Lemmy community, it only shares content, and does not produce any of its own.

Here is a quick recap of how sharing is handled in NodeBB:

• When remote users boost/repost content, NodeBB interprets this as a share.
• When local NodeBB admins move topics out of "uncategorized" and into a category, it is interpreted as a share and this activity is federated out to the admin's followers.

At this time unprivileged users cannot share content.

@[email protected] I noticed in the latest release notes for Fedify that it now sends a user agent for AP requests.

Was there a specific reason that this was implemented? I noticed that GoToSocial sometimes rejects my requests/activities, and I am assuming this has to do with the User-Agent header (or lack thereof) that I am sending. GtS seems to think I'm a bot, so I thought perhaps you ran into something similar?

cc @[email protected] (not sure which one's your main handle)

As reported initially by @[email protected], there are some posts from Lemmy that didn't make it over to NodeBB. This turned out to be an issue with how content was parsed by NodeBB if source.content was also present.

The code has been updated so that if a content source of type text/markdown is provided, then that source is used instead of the generated HTML.

Outside of Lemmy, this also applies to any implementor (snac2 maybe?) that also implements the source.content property.

Agenda preparation for the December ForumWG meeting can be found at this public link (anyone can make comments for review.)

Monthly meetings are held on the first Thursday of each month, at 1700 to 1800 UTC. You can find them listed in the SocialCG Calendar. The next meeting will be held on 5 December 2024.

We will be continuing onwards with:

• FEP convergence (re: conversational contexts) and a proposal re: baseline usage of as:context as a grouping mechanism
• updates by WG members re: non-as:Note support in Mastodon

As always — time permitting — if you'd like to speak or inquire about a certain topic, comment in the agenda or reply here, the floor is open!

I'm happy to announce RC1 (that's Release Candidate 1!!) of NodeBB v4. Since the last v4 pre-release (beta 4), we've made additional bug fixes and stability improvements.

Here is the list of new features and fixes since the first beta:

• Emoji! :star2: :trumpet: :snake:
• Ability to search for a user by their handle directly from the search bar
• When encountering links to websites that advertise an ActivityPub alternate, NodeBB will try to load that site in NodeBB first
• Categories now have their own avatars instead of serving the generic site brand icon
• NodeBB will attempt to backfill an entire topic when encountering a new object, reducing the need to visit the original site to get the entire conversation. (This is contingent on the other server supporting resolvable context collections)
• Chats are now federating out as limited-visibility posts on the fediverse
• Improvements to the title generator
• Custom Fields now two-way federating (custom fields are a feature new to the 3.x branch as well!)
• Better compatibility with nodebb-plugin-feed

Timeline-wise this brings us close to the end of our funding from @[email protected] for the 2024 calendar year. We've exceeded our own expectations of what we could do this year, and we've already applied for funding from NLNet again to really let NodeBB push the boundaries of what the ActivityPub protocol can do!

The RC signifies that the software has reached a (self-proclaimed) stable state, and broader usage is encouraged. If you have any questions, concerns, or trouble upgrading your existing NodeBB to v4, please call that out here for support.

There is now a soft feature freeze in place while we sort out the last remaining (hopefully none :hand_with_index_and_middle_fingers_crossed:) bugs, and we'll aim to launch v4 after that.

:rotating_light: We have emoji! :arrow_left:

I like emoji, I like them quite a bit. I grew up using emoticons (gosh, remember those?), and definitely love to sprinkle them in my forum responses.

If you've been following me since I've been contributing to the fediverse, you might've thought I eschewed emoji, but let's put that misconception to rest :laughing:

Thanks to the hard work by @PitaJ, NodeBB now federates emoji used in posts outward to remote instances. This works across all emoji packs (android, apple, cubicopp, etc.) available to the emoji plugin, and also includes custom added emoji :arrow_right: :voodoo:

This is a two-way integration, so custom emoji served by other instances are also picked up by NodeBB and displayed properly in posts.

You might notice that the emoji I use are all blobs. :smile: It's the default emoji set for all NodeBB instances, because blobs are amazing and it's a travesty Google decided to move away from them.

Long live the blobmoji :flushed:

A little-known feature was added in the 3.x develop branch of NodeBB, custom fields. It was an often-asked-for feature that had a couple of plugins built to accommodate, but @baris decided to make this part of NodeBB core.

I will let him do a more detailed write-up on the NodeBB side, but suffice to say, those custom fields will now federate out with your profile:

Likewise, custom fields as defined by remote users will be saved and displayed in NodeBB in metadata boxes just like those defined in NodeBB.

In NodeBB, administrators are able to globally specify a set of fields that individual users can change/set.