In another thread, @[email protected] talks about challenges regarding proliferation of spam (or other unwanted content) on the fediverse: ... I was talking about reddit's "posts require approval" mode. Something that might be of use for new accounts registering on pixelfed instances to prevent things like gorespam from occurring. NodeBB has the post queue (our name for it), and it works really well to stop drive-by spammers. Most cheap spam is easily identified as such, and it's only a couple clicks to send them to /dev/null. More recently, and especially since we've been federating posts outward, we've started encountering possibly LLM generated content entering our post queue. It could be that these accounts are legitimate users creating an account to respond to remote content, but it's equally likely that they're attempting to create plausible content in order to pass validation, before proceeding to post spam. At least here on community.nodebb.org it's trivial to discover, because this forum is for NodeBB support/discussion, and a post out of the blue responding to a post about Trump or Israel/Palestine is very obviously not meant to be on this forum, although it's definitely one of those "hard problems" for more general instances.

@[email protected] yeah it was the fact that it was all nested, so I'd start reading them from the outside in, and realize quickly I was reading them backwards. That kind of stuff only really happens in email, which is why I was caught off guard.

Well done everyone!

@[email protected] said in NodeBB v4.0.0 — Federate good times, come on!: @[email protected] careful with that though, not all tags are the same, some have a higher signal-to-noise ratio, but others would just be filled with garbage I think the best way, then, would be to have rules that map various group actor URLs to categories, and possibly also tags. Nothing automatic. Only configured. Of course, once Lemmy fixes the ability of Group actors to follow other Group actors, this will be a non-issue. One other possible solution, which is employed by Misskey et al., is a proxy actor. It's a special user that follows other users, and relays info within its own instance. It's used for doing things like adding a remote user to a list without directly following them. The proxy account follows the user, and then your local instance adds the remote user to your list. But all ActivityPub interactions go through the proxy user.

@[email protected] it's something I've been thinking about addressing as well. Theoretically one could display a quote above the post, but I wouldn't want it to be confused with a quote post, which is a different beast (and one not present in forums) altogether.

@[email protected] feel free to email me at [email protected] or DM me on the fediverse

@julian @evanprodromou yes, that is because the plugin processes the follow synchronously 🥸thanks a lot for tweaking nodebb to be compatible and I will see how we can improve that!!!

@[email protected] do you mind cancelling the meeting for today?

devnull:the fact that Discourse (as SocialHub) handled that and reported that another post came from itself suggests that perhaps it went down a logic path that is normally reserved for local posts.My theory: conflict between Create and Announce(Create)https://socialhub.activitypub.rocks/t/federated-socialhub-categories/4648/21

Thats great, and your reply shows on Feddit!

@eeeee there are a few fixes in the pipeline and there's always work on polish (especially for onboarding new admins), but that can really wait for v4.1 Was hoping for before 2025 but there's no rush, I will likely wait until the new year and cut the release sometime in January prior to FOSDEM.

https://www.jammersreviews.com/st-ld/s5/new-next-generation.php @[email protected]

NodeBB's topic list layout is great for written and media-light content, although it is less ideal for categories which predominately feature pictures. I recently ran into this issue with the Pics and Trips category on the OpenBeta Community. While we've made some much-needed TLC and improvements so that topic thumbnails are better handled and displayed, I did not feel they were adequately prioritised for this particular category. So I wrote the Category Masonry plugin for NodeBB! [image: 1734625210426-screenshot-2024-12-19-at-11-01-07-pics-and-trips-openbeta-forums.png] In brief: Configurable; either by category or by percentage of topics with a topic thumbnail/image Overrides the partials/topic_list.tpl template to display cards Works with custom themes (will correctly override the theme's category.tpl, or the base theme's category.tpl if your theme does not have its own)

@julian Hi, yes for sure. "Source" or "Location" are pretty common data points that add more granularity in organization/sorting/searching. An example of a non text field would be something like "beginning date" and "end date" that would need to be date or number. I'm admittedly new to nodebb, but I it would seem copy/pasting whatever was done to the users codebase and replacing the variables names would be perfect for both categories and topics.

@[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.

The full minutes from the Forum and Threaded Discussions Task Force monthly meeting (held on 5 December) can be found at this Google Docs link The minutes are also inline below. Apologies in advance if I misrepresented anybody or missed any crucial bits of information. December 2024 Minutes Forum and Threaded Discussions Task Force --- Housekeeping Julian noted that the event description in the SWICG calendar calls for a monthly meeting from 1700 to 1800 UTC, although the scheduled time is pegged to 1300 to 1400 Eastern Time (observing DST). Dmitri (absent from meeting) to update event description as:Article and Mastodon treatment of non-notes Darius provided an update – been under the weather and busy with some other work-related items, but: Mastodon team cautiously optimistic about upstream PR, some concerns were voiced over things like inline images Hopefully by next month will have something more concrete to show to them; re: demo package Evan (@[email protected]) planning to get some people together in-person, to work together at FOSDEM in Brussels (Feb 2025); specifically to address long-form text issue Discussions about this in the task force would be considered the crucial pre-work Darius will update the group if something happens before January (re: code or PR package) A test instance up and running, Darius plans to make it more accessible for others to check out Silverpill’s FEP 171b is now an official draft, open for comments on SocialHub No specifics, just a news item. Context collections FEP Convergence Rationale for recommendation outlined in meeting agenda. Evan (@[email protected]) and a (@[email protected]) met up just prior to the WG meeting to discuss and work out differences between their FEPs; main notes: Using context to represent a reply tree is good Restricting usage of context is not the goal of 7888 or the ForumWG Co-exists well with 76ea’s thr:thread property to denote a reply tree, etc. Recommending use of as:context is one good way forward Evan recommends that the “should” in the proposal be changed to a “may” PROPOSAL: Publishers SHOULD use `context` for grouping related objects in a thread (but this is not the only way to use context). RESOLVED with 8 ayes, no nays, and no abstentions Brainstorming focus items for 2025 Emelia (@[email protected]) – multiple contexts? a (@[email protected]) : we need to also handle the fact that some contexts may not resolve Emelia: as:context can be an array of values in JSON-LD a: inReplyTo can have multiple values too; but in general, on the producing side we generate a single value – generally expect context/thread to remain the same (singular values) Sebi: "we thought a lot about multiple contexts" - led us to the conclusion of using profiles/describes property; per spec can only have one value Julian: Handling when implementors (e.g. lemmy/piefed) don't have the concept of topics a: there are multiple different models of how items are grouped together; reply tree model works for large part of the fediverse; mastodon has concept of reply tree represented internally as a conversation (vs context); this could be expanded into a conversation having an owner, etc.; mastodon has the conceptual ground to build upon Evan: reply trees work well on microblogs, blog comment trees, threaded posting systems, forums; other applications expect a more serial model... messenger/chat systems, where ordering of objects is not in a tree, no explicit relation between them; hashtags, locations, few other ways to use context Emelia: clarify overlap between replies collection and context collection? a: in general will include both ancestors and descendants; could add filters, look at tags, etc. to get subsets. If you are querying by context, you are looking for all objects related by said context Evan: full tree Julian: Mastodon reply-tree service proposed (https://github.com/NeuromatchAcademy/mastodon/pull/44) Julian: worried about scalability and performance of a backend service iterating through an entire reply tree; advocates that retrieving as:context is more performant especially if we build in some tooling for synchronization and member checking Emelia: historical reports of harassment due to `inReplyTo`; when looking at context including descendents, then how do we generate the tree? Evan: fep 76ea goes into detail about how reply trees can be managed a: answer is "who has the authority?"; who decides what goes into the collection? the `attributedTo` actor. For the replies collection, this exists IN PARALLEL TO `context`; in some ways a subset of the thread; could be a point of contention for systems that expect all objects to exist in general vs. conversation oriented Julian: upends expectation that objects are independent Darius: does this relate to announce leaking? recommendations that you not forward the entire object, just the ids Emelia: related but different; announce leaking -- should only ever do objects by ref (by the id) a: the paradigm shift is more social rather than technical -- that you cannot just rely on inReplyTo to prove that an object is approved some duplication as context includes replies, but they are distinct collections. They are decided by different authorities. `replies` is decided by whoever wrote the post Ted (@[email protected]): This sounds a lot like reinventing netnews, without taking the lessons that were learned from it; blurring the ideas of message store/relay/display; for all of this to work, the system has to pick up all replies, and let the client filter. Julian/a: anything specific to share? lessons, etc. – definitely of interest in not repeating the same mistakes

@[email protected] confirmed, the missing user agent was the issue

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.