NodeBB-ActivityPub Bridge Test Instance

Is there a requirement that an activity ID be unique?

Reason why I ask is it seems prudent to save a list of encountered activities, and drop those that have been seen before.

However that caused me to run head-first into a NodeBB regression because we ourselves don't actually send unique activity IDs.

For example, a Follow-Undo(Follow)-Follow chain would have the two Follows with the same ID, since we just construct them ad-hoc based on request data.

Easy fix is to throw in a timestamp there, but it got me wondering about whether there were uniqueness expectations at all, or whether I was being overzealous in checking for it.

tl;dr — you can now find remote categories and see your tracked/watched categories in /world.

A new alpha version of NodeBB was tagged today: v4.3.0-alpha.3. The biggest change is to the /world route, which up until now showed a list of topics from outside of the local NodeBB instance.

New to this alpha release:

1. A quick search widget was added, allowing you to directly search for remote categories. There is no need to navigate to to the search page to discover new categories.
2. Your list of tracked and watched categories will show at the top of the page.
   • "Tracking" and "Watching" categories—both local and remote—is how content discovery happens in NodeBB. Tracked categories will have new content show up in the "unread" page, while watched categories take that a step further and notify you when new content is posted.
   • Tracking and watching a category will tell NodeBB to subscribe to that remote community for updates

At this time we're continuing to look for stability issues with the remote category integration. We'll be working on QoL fixes as we move into the beta phase this/next week.

Based on the replies received, it does sound like at present that if cross-posting is a consideration, it is something done locally, and not something that is explicitly declared when federating outward or retrieved via AP.

There are also multiple definitions of cross-posting:

1. Multiple, disparate topics sharing the same attachment url (PieFed)
2. Author targeting multiple audiences
3. Non-author sharing object to additional audiences

One of those is really not like the other, which does complicate things somewhat. Thankfully, it does seem like that the way PieFed handles it, is local to the instance.

A good first step might be to narrow down the definition of cross-posting—at least from a protocol level—to a combination of the latter two:

> "A user (which may or may not be the object author) sharing an object to additional audiences"

Of course, this also happens to be what I'm looking for: the association of an as:announce activity with an as:target pointing to an as:Group actor.

Would this be of interest to anybody here? The fallback mechanism is to just treat the announce as usual.

tl;dr — how do PieFed/Lemmy/Mbin handle cross-posting?

Currently, when a NodeBB admin moves a topic from the uncategorized pseudo-category into a local category, we federate out an as:Announce, people typically think of that as a "boost" or "share".

That worked fine when the entirety of the category list was your local categories plus the "uncategorized" pseudo-category. However, now that NodeBB is moving towards supporting remote categories (via group actors), this UX makes less sense. We wouldn't want to "move" a topic out of the category it is supposed to be in, just for visibility to other local users. Additionally, topic moving was limited to administrators, and from the get-go we knew it would eventually cause issues because people other than admins would want to share topics to other local users.

This is where the "cross-post" functionality comes in, which is entirely new to NodeBB. I don't think this is new to other AP-enabled threaded discussion software. The idea would be that if a new topic comes in, whether it's uncategorized or not, any user could "cross-post" that topic to a local category, where it would be visible to other users on that instance. On the ActivityPub side, we would then federate out an as:Announce as we already do.

Is this what PieFed/Lemmy/Mbin already do, if they support cross-posting? What other alternative solutions would there be to this problem?

cc @rimu@mastodon.nzoss.nz @andrew_s@piefed.social @nutomic@lemmy.ml @bentigorlich@wehavecookies.social