@[email protected] that's a good point. Both Lemmy and NodeBB implemented FEP 1b12, which is why those category/community actors share content. So yes, NodeBB's category actors also only share content, and don't produce any of their own.

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.

@[email protected] You can start a new thread by mentioning the category directly in a new topic. NodeBB sends Create(Note) from the author, and then five seconds later sends Announce(Create(Note)), Announce(Note), and Add(Note). Hubzilla may be misinterpreting the last three.

Please make them visible for topic listing. [image: 1732745247674-emoji.png]

@julian @silverpill also your Link.href is being escaped incorrectly

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…

What about Design v4, is the same like 3.11.0? Is there Grid categories Options with images? Invision Community tests v5 Beta 6. Here some Forums https://www.fanclubs.org/ https://jimiwikman.se/ https://www.internazionale.fr/ https://krscanski.chat/

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!

@[email protected] The other part of it is... unlike Mastodon, we're not looking for NodeBB to become the app to use to interact with the fediverse. It's certainly something I want out of my use of NodeBB, but what forums are great for are cultivating niche communities based on shared interest. If I'm able to preserve that aspect all while allowing remote content to also interact with the forum, then it's win-win.

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