NodeBB-ActivityPub Bridge Test Instance

@projectmoon@forum.agnos.is said in Updates to the world page:
>
>
> Also, are there plans to merge the federation synchronization and new remote category following stuff together into one cohesive set of functionality?

Yes... the remote category functionality supercedes the category sync functionality in some ways, but there is still a use case for it.

Most likely I will need to develop proper support for cross-posting (at least locally), and that would work well with the remote category functionality, so that topics are cross-posted to the synchronized category, instead of moved.

That's correct, that category wasn't federating, but it is now

Were there other categories breaking?

@projectmoon@forum.agnos.is thanks, can you try again? For whatever reason the handle-to-cid association was lost, and I'm not sure why. I've manually restored it now.

@projectmoon@forum.agnos.is no, that didn't matter. There is no concept of nested categories in ActivityPub yet.

But the issue seems legitimate, I can't access the ActivityPub category from a test Mastodon server either.

@pfefferle@mastodon.social just wanted to poke you about this issue again.

The latest updates to NodeBB now do a webfinger backcheck to ensure that the actor has a valid webfinger entry for their purported handle. If it does not, then the user is not properly created. Mastodon also does this. This check is probably for security as well as for preventing handle collisions.

The multilingual plugin in conjunction with the ActivityPub plugin creates users that share the same handle, and that causes issues with federated content.

For example, this article by @jonvt@vivaldi.com will load up just fine in Mastodon, but this japanese article by @akira@vivaldi.com will not, because that second article's attributedTo is https://vivaldi.com/ja/?author=176, which fails that check (the author's ID is actually https://vivaldi.com?author=176 as per the handle backcheck)

cc @AltCode

Bit of a thought experiment here as to how to handle these duplicate accounts.

(tl;dr two federated accounts with different IDs report the same webfinger handle, what do?)

Let's say @ruario@social.vivaldi.net posts an English article under his account (and then is federated), and posts a translated Japanese one that is also federated, but under the Japanese ID.

What should NodeBB do when encountering the latter? Currently, it will try to assert the actor, fail the webfinger backreference check, and probably drop the post. Not so good.

One could adjust the actor to the former (canonical ID), but that's not technically right either.

That also opens up potential account impersonation possibilities, so that is something that would need addressing as well.

@projectmoon@forum.agnos.is hmm... could be a bug in the user migration code path.

Can you run your forum in dev mode (./nodebb dev) and try to load some of the categories here in your forum, and let me know if you see any errors in the console?

Right now you're able to add remote categories to your world page. It's possible that we could allow admins to add remote categories to the forum index, although that'd be something we add later on.

I just realized that while we now have the ability to browse and follow remote communities, we don't have a page listing communities ordered by popularity or recency... time to add to my ever expanding list

@jsonculverhouse@flipboard.social yes, that's right.

If a Flipboard post is organized within magazines, then including the magazine in the cc will allow recipient software to correctly slot the post with the magazine.

So not only would it fix the issue for NodeBB, it'd also fix it for Lemmy, PieFed, Mbin, etc.

@AltCode right, I think the issue here is that the posts themselves do not contain a backreference to the magazine they were posted to.

So for example, their latest post has addressed the following:

...
  "to": [
    "https://www.w3.org/ns/activitystreams#Public"
  ],
  "cc": [
    "https://flipboard.com/users/theverge/followers"
  ],
...

... note that the magazine itself is not included, and so when NodeBB receives the object, it does not know to slot the topic into the appropriate category.

cc @jsonculverhouse@flipboard.social again about this one

@AltCode This should be fixed in the upcoming v4.3.0.

Actor assertion should not proceed if passed-in ID does not pass a webfinger query · Issue #13352 · NodeBB/NodeBB

I think NodeBB checks that the ID exists, and then proceeds with a full actor assert/update if it doesn't find it. Which leads to weird stuff as discovered by @altcode@community.nodebb.org where: One user with id: https://vivaldi.com/?au...

GitHub (github.com)

It won't proactively remove the duplicates, but they'll be pruned out within ~7 days.

@AltCode that user and the category are (I think) separate actors. I'm not sure what the user does, shares its own posts, possibly... but like you said, nobody follows that user so I suppose that's why there's not much shown as shared either.

@AltCode I think it's just Flipboard, right?

It might be because of the issue mentioned upthread where items shared by those groups don't have a back reference to the itself so it isn't slotted in it.

They might all just be uncategorized instead. Can you find those items when you search their url or id in the NodeBB search bar?

Angus, while I haven't made the appropriate changes to NodeBB's implementation yet, I did draft an FEP including the changes we discussed.

File not found · julianlam/feps

Contribute to julianlam/feps development by creating an account on GitHub.

GitHub (github.com)

It is not PR'd upstream yet, but I will do so in the coming days unless there are some concerns.

Agreed. That makes sense since receiving a Delete should trigger a cache invalidation, so there's no reason it need be a different activity. I will make the appropriate changes soon.

I can look into putting together an FEP for this. It would solidify the concepts and open it up for wider discussion if necessary.

No, there have been no major concerns arising out of this.

A couple observations:

1. There is a mismatch between what other instances expect for deletions and what actually happens. A Mastodon user deleting post expects it to be gone for good, but on our end it will simply be soft deleted. This isn't a major issue, it just means admins get to see all the deleted stuff (useful when people say hurtful things, delete them, and pretend they never happened.) Even then it's only a small percentage, most of the deleted stuff I see are for fixing typos.
2. I am reasonably sure that nobody else besides NodeBB (and now Discourse) knows what to do with an Update(Tombstone), so nothing happens. It means soft deleted posts on our end are essentially ignored and still visible.

The latter may actually be a concern and warrant an admin-side option to explicitly federate out a Delete.