Additional pages have been added to the NodeBB documentation regarding the following items: Post visibility — how NodeBB handles incoming activities with public and non-public visibility, and how they are represented in NodeBB. Conversational Contexts — how NodeBB builds out a conversational context when parsing incoming content.

@Stefan Bohacek @jdp23 @julian "Shadow mentioning" is a thing. (streams) and Forte do it to avoid clutter. Mentions don't have to be visible in a post/comment to work.

Interesting. I received a repeat notification from @ActivityPub on my last comment. I suppose that is how you are acknowledging that my post was sent to people following that category. I like it.

julian:This whole thing could actually be sidestepped if we sent timestamps with our activities, but that's not in the spec, so I guess nobody does it heh.This sounds like a wonderful FEP!

Ok, found the problem. It only works with the privilege guests / View Users enabled. I had fediverse / View Users enabled anyway but that wasn't enough. I'm not sure if that's intended? I guess it makes sense in principle…

@Julian I filtered out the null names and the upgrade went through: "use strict"; const db = require("../../database"); const meta = require("../../meta"); const categories = require("../../categories"); const slugify = require("../../slugify"); module.exports = { name: "Setting up default configs/privileges re: ActivityPub", timestamp: Date.UTC(2024, 1, 22), method: async () => { // Disable ActivityPub (upgraded installs have to opt-in to AP) meta.configs.set("activitypubEnabled", 0); // Set default privileges for world category const install = require("../../install"); await install.giveWorldPrivileges(); // Run through all categories and ensure their slugs are unique (incl. users/groups too) const cids = await db.getSortedSetMembers("categories:cid"); const names = await db.getObjectsFields( cids.map((cid) => `category:${cid}`), cids.map(() => "name"), ); const nullIndexes = names .map((element, index) => (element["name"] === null ? index : -1)) // mark null elements .filter((index) => index !== -1); let filteredNames = names.filter(element => element["name"] !== null); let filteredCids = cids.filter((_, index) => !nullIndexes.includes(index)); const handles = await Promise.all( filteredCids.map(async (cid, idx) => { const { name } = filteredNames[idx]; const handle = await categories.generateHandle(slugify(name)); return handle; }), ); await Promise.all([ db.setObjectBulk( filteredCids.map((cid, idx) => [`category:${cid}`, { handle: handles[idx] }]), ), db.sortedSetAdd("categoryhandle:cid", filteredCids, handles), ]); }, };

Hi,I think It would be helpful to include examples of common use cases for ActivityPub integration in NodeBB detailed setup instructions with screenshots and troubleshooting tips for potential issues users might encounter. Additionally a FAQ section addressing common questions could be valuable.Thanks

For awhile I've been wondering what the slow-down was when I loaded /world, the curated timeline for a NodeBB user. Seemingly every time I figured out what it was, it would slow down again after some time. Today it was taking 3+ seconds to load just the data, whereas our other pages (category listing, topics, etc.) all finish in under 250ms, including html generation, user data, etc... Certainly something was amiss! As it turns out, asking your database to do an intersection of two data sets, one containing 23774 items, and the other containing 23606 items, is a little much. I guess this is what they mean when they talk about #webscale hah! (#fediscale?) Specifically, I was intersecting the set containing all fediverse topics, with the set containing everything in the user's inbox, in their entirety. While this gave me a very precise answer, there was a huge cost to that precision. After talking with @baris about this, we decided that sacrificing some level of precision would almost certainly go unnoticed. Instead of having the database intersect those two data sets, we would pull the most recent 500 entries from both and intersect them manually. So, /world is now limited to 500 topics. Don't worry, you won't notice. That simple fix brought the execution time down from ~1500ms to ~40ms, which is more in line with our expectations!

@[email protected] thanks for the kind words, appreciate it! I feel like we're almost in an exploratory phase of ActivityPub development, where we're still figuring out some best practices for some things. It'll only get better!

@julian @Fitik Still faster than a multi-billion dollar conglomerate. Congrats!

@julian that's a good point. I feel it'd mostly be better for integration with Lemmy/Kbin type systems that mimic forums.

Technical stuff ahead ... This is merely exposing the frontend UI to the already established backend logic. We have two methods internally that are used for this: Notes.assert, which when given a object url or id, parses it and attempts to resolve the parent chain all the way to the top-level post. It then creates a topic to house all of those posts. Actors.assert, which when given an object url, id, or handle, creates a local representation of the user. How come "query"/etc. didn't show up? For both user and post searching, if the passed-in url does not resolve or does not resolve to a processable object, then we do not proceed. It's important to realize that while in an ideal world, we'd all be passing immutable identifiers everywhere, the real world is just a bit messier. Search queries could be a post or user URL, or a webfinger handle, so additional logic was required to handle those use cases. Most ActivityPub-enabled software I've encountered handle these vanity URLs when queried via ActivityPub — it returns the appropriate representation for processing. Some do not, and so in those cases, those items will not show up in the search results.

@[email protected] Yes, I think that's what @oplik0 and I ended up agreeing on. If we normalize all incoming requests so that any requests containing a full object on a different domain is just reduced down to its id, then you'd safeguard yourself from most edge cases. Applying FEP-8b32 would be handy to save yourself a few network calls but is optional. The cost is you might have to make a couple extra calls, but it's probably worth it in order to keep the logic simple, predictable, and easily auditable.

A small quality-of-life update I just pushed to NodeBB will now allow you to view the content posted by non-local users. When discovering new users and determining whether to follow them, their post history is rather important! You can view post history for a remote user just as with a regular user: Profile > Posts [image: 1712159160258-359b6584-606f-4afa-9964-b6f314814522-image-resized.png]

Thanks @crazycells . I I'm pretty sure it will become important to do that sooner or later. probably sooner

@[email protected] but on the upside, your edit to your toot to add spaces to the mentions and urls propagated successfully back to NodeBB! So, success! Onwards!

@eeeee the ActivityPub integration is under heavy development and won't be ready for awhile. When it is, we'll release v4.0.0 /world contains topics from users that you explicitly follow. You probably don't see any topics there because you don't follow any users, or the ones you do haven't posted anything yet

Quick update: you are now able to mention individual users in your posts, and if you are mentioned in return, you will now be notified. There was also a bug where remote user avatars were not showing up in your notification inbox. That has now been rectified. [image: 1709668985075-eef805e8-3ccf-47d6-b7b9-c7d96e5df9e6-image.png]

@crazycells you're passing the naked url which is not correct. You have to run it through encodeURIComponent() before using it as an url fragment Note the % ended symbols in my post above Ah, if you mean via the menu, I suppose that needs to be fixed.