Happy Tuesday!
Today we’ve updated the NodeBB community forum onto the remote-categories testing branch, which means that users on the open social web that identify themselves as “Groups” will be rendered in NodeBB as categories. Prior to this, they looked like users.
Here are some examples of remote categories:
- Comic Strips (on lemmy.ml)
- Star Trek Social Club (on startrek.website)
- Social Web Foundation (a WordPress blog)
ActivityPub “groups” and forum categories have quite a few things in common — they don’t usually post topic themselves, they “contain” topics, and they are usually administered by a separate group of users (moderators!) In many ways, these groups lend themselves to categories much more easily than they do as users.
Notes:
- We will likely be releasing this as v4.3.0-alpha this Wednesday. Probably this means you don’t want this on a live forum just yet.
- A lot of the backend logic is complete, but a lot of the frontend UX will be worked on.
- You can “search” for categories (via “in categories” in the search page), paste the full handle in order to instruct NodeBB to pull a new category in.
- You can now no longer mention a remote category. Instead, create your topic right in that category itself. As it should be :smirk_cat: .
- Remote content coming in that is slotted into a remote category will still show up in your “world” feed. That is still intended to be where discovery of content outside the local NodeBB instance will take place.
- Report any bugs or confusing behaviours (and there will be some) here.
Screenshots
Some of the remote categories appear to be broken now.
These are the Flipboard magazines NodeBB is currently aware of when searching “flipboard” in the search page:
However, that very first one (tech news by The Verge) does not work; going to it gives a 404 page instead.
Something else appears to have happened to the Vivaldi Blog remote category (a WordPress blog). A week ago it was working fine, but now, searching for it lists it twice in the search page. Each listing indicates a completely different number of posts and topics for the remote category.
Even weirder though most of the topics that are correctly slotted into it, they are not actually in the category page, e.g. https://community.nodebb.org/topic/a85b0eff-5219-46ba-9ad4-a5d417a7bec5/minor-update-2-for-vivaldi-desktop-browser-7.3
Screenshots
@AltCode all three flipboard remote categories seem to be working now :joy:
Actually, I think I know what’s going on with the Vivaldi blog group actor - it’s not necessarily NodeBB’s fault.
Inspecting the AP objects coming from vivaldi.com/blog, all the English-written blog posts have their
as:audiencefield set tohttps://vivaldi.com/?author=0.Meanwhile, every other blog post that is written in a different language instead have it set to
https://vivaldi.com//?author=0, so for Japanese blog posts, for example, it ishttps://vivaldi.com/ja/?author=0.And all these URLs link to different group actors, but all of them have the same value on the
preferredUsernameandwebfingerproperties:blog, andblog@vivaldi.com.EDIT: Actually this also appears to be all actor objects coming from vivaldi.com/blog. E.g. if you start typing
[@ruari@vivaldi.com](https://community.nodebb.org/user/ruari%40vivaldi.com)or search for it, you can see it be suggested twice too.So my guess is that there are two person actors that NodeBB knows of that are claiming to be
ruari@vivaldi.com:https://vivaldi.com/?author=46andhttps://vivaldi.com/ja/?author=46.This is probably a bug with the WPML+ActivityPub plugin combination they have going on.
Screenshots
@AltCode I forked this out to a new topic. I think it’s time to loop @pfefferle@mastodon.social into the conversation (at the very least so this could be potentially escalated).
Mattias, it seems that when the WPML and ActivityPub plugins are enabled together, notes federated out by the blog user in another language have different
ids but the samepreferredUsername.e.g.
ruari@vivaldi.com: https://vivaldi.com/?author=46andhttps://vivaldi.com/ja/?author=46NodeBB interprets this as two different users. Curiously, Mastodon does not, the second ID explicitly does not resolve.
So there can be two solutions here:
The remaining questions here are:
preferredUsernameis meant to be unique to the instance (in which case having multipleids point to an identicalpreferredUsernamewould be a violation), and@AltCode okay! Thanks for reporting, it sounds like there are two issues going on:
preferredUsername.