Great. Do you have an approximate date v4 will go live?

The 2024 IFTAS Needs Assessment Report is Here!We are pleased to to announce the release of the 2024 Fediverse Trust & Safety Needs Assessment Report. This annual report is a cornerstone of our mission to support the decentralised social web with evidence-based research and actionable recommendations for moderators, community managers, and administrators.This year’s report reflects the insights of 183 services spanning platforms like Mastodon, Lemmy, and Peertube, collectively hosting over 4.3 million accounts. This year we also heard from volunteer independent moderators on Bluesky. By analysing the experiences and feedback of these moderators and admins across the Fediverse, the report highlights the challenges and opportunities within this rapidly evolving ecosystem.We will follow up with an analysis of what we’ve seen change since last year’s report, as well as key resources we think can help solve some of the needs identified.Key FindingsResource gaps – only 16% of communities have 24-hour moderator coverage, and nearly half of moderator teams lack formal guidance. That said, we see roughly one moderator for every 1,200 active accounts.Top ranked priorities – moderators need tools for CSAM detection, spam prevention, and legal guidance for compliance with regulations like GDPR.Burnout is a persistent issue – one in five moderators report experiencing trauma or burnout this year, underlining the need for wellness and resilience resources.Financial struggles – most communities operate on donations, and overall our survey participants are not generating enough money to cover costs. Very few moderators are receiving any compensation for their labour.IFTAS InitiativesInformed by last year’s findings, IFTAS has developed several solutions and programs, including a Fediverse CSAM scanner, a comprehensive Moderator Handbook (coming soon), and the creation of FediCheck for automated denylist management. Moving forward, we aim to expand resources for moderator wellness, launch our CSAM scanner for broader use (please register your interest), improve tooling for non-consensual image detection, and introduce new community guidelines templates.We encourage everyone in the Fediverse community to read the full report for a deeper understanding of the challenges facing decentralised moderation and the innovative solutions underway.️ Read the Full Report HereGet InvolvedIFTAS thrives on collaboration. Join our community of practice at IFTAS Connect, use our resources, or support our mission with a charitable donation to help make the Fediverse a safer, more inclusive space for all.Let’s work together to empower moderators and create a stronger, safer social web!#TogetherStronger #ActivityPub #BetterSocialMedia #Bluesky #Fediverse #TogetherStronger

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

Reminder that the ForumWG meeting will start in roughly 1 hour and 20 minutes, at 1800 UTC, this is an hour later than scheduled due to DST (which does not occur for UTC), but should be the same local time if your country observes DST.

Hi @FrankM, I have a write-up on content discovery (including needing to follow people) here: https://docs.nodebb.org/activitypub/discovery/

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

@julian @mario @jupiter_rowland @benpate @fentiger @scott>Would you consider relaxing this to allow for situations (e.g. forums) where the conversation thread starter is not necessarily the manager of the container?As far as I know, in Streams OP and owner are identical, but you are right - they might as well be different. I'll mention this in the FEP.>I haven't seen collectionOf in the wild before, what purpose does it serve here?Again, this is what Streams does, I'm guessing this is because some context collections contain posts and not activities, and collectionOf tells you how to parse the collection without resorting to duck typing.I would prefer to use an outbox property for containers.

Sounds like a good idea. I was unaware about this, and are evaluating spending some of my budget on going.

@julian Well, there are object types that Mastodon couldn't even handle if it wanted to. For example, it doesn't have anything to handle an Event-type object with. I don't think Gargron would build an event calendar into Mastodon just for Event-type objects, not unless enough people pester him to do just that.#FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mastodon

@julian @thisismissem which is to say, the following are equivalent within the same scope...@\context: [{toot: http://joinmastodon.org/ns#,Emoji: toot:Emoji},{toot: http://joinmastodon.org/ns#,IdentityProof: toot:IdentityProof}]@\context: [{toot: http://joinmastodon.org/ns#,Emoji: toot:Emoji,IdentityProof: toot:IdentityProof}]

Reminder that the ForumWG meeting is coming up in one hour.

@julian @thisismissem @silverpill which is to say: audience is what decides which objects you are even *aware* of, before you even get around to grouping them logically.in a centralized system you would query for all objects in the database where the context was what you wanted, and where the audience included you.in a decentralized system you work off of what’s in your inbox, and “follow your nose” to the context, which may have its own audience.

@erincandescent @trwnh @evan @jenniferplusplus @mikedev @scott @julian @trwnhThe name of the property could be different, but I think it is useful to have two collections:- "Thread" is easier to implement, and in any case, software needs to keep track of reply trees, one way or another.- "Context" is a bonus. It contains everything related to a conversation, including reactions and edits. Some applications may not need it, and for some it might be difficult to implement, so it should be optional.My estimation is that implementation of "Context" + "Thread" will require roughly the same amount of effort as implementation of "Context" alone, so for those who want "Context" this separation should not be a problem. If software doesn't keep track of activities it can provide empty "Context", but their Add activities should nevertheless have it in target. Perhaps in the following form:"target": { "type": "Context", "id": "<context-collection>", "attributedTo": "<conversation-owner>", "thread": "<thread-collection>" }

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

@[email protected] said in Quoted posts: One big benefit of this proposed quote post methodology is that it would be a version that Mastodon, et. al. would probably be willing to support. They have valid concerns that people will abuse quote posts to harass others. This proposal mitigates that. It also is useful in non-malicious contexts since people can fix typos and errors in their original post. It's also useful if the person being quoted wants to retract what they said, perhaps because they changed their mind on a topic or found new information. Well, and Mastodon et. al. are free to implement it that way. There is of cause the limitation of the technical solution on the Forum side regarding editing or deleting; but Mastodon is free to implement it as links. In the same way as a Forum solution has to implement it as qoutes, because the context is different. That means that if the forumpost actually becomes edited or deleted, Mastodon will delete it, because the link has disappeared, but if the Mastodon qoute disappears, the qoute stays in the forum, but the link back to source disappear so now it is just a statement witout a source.