Request for Clarity: Threads & Activities essential for moderation and maintaining already establish safe-spaces

Hi all, especially Meta employees, 

I asked this earlier on the on the Fediverse, and also noted it in todays CG call, but I wanted to re-ask here just so that we get a very clear and definitive answer for everyone.

In all the posts I've read from the Threads federation meetings, all held under the chatham house rule, it's never been exactly clear when they'll implement the features required for successful moderation of ActivityPub based platforms, or how they will handle moderation activities from non-Threads users, or how Threads users will interact with non-Threads content for purposes of moderation (in the case of abuse flowing from say Mastodon to a Threads user).

I would love to gain some clarity into how & when Threads intends to implement handling of Flag, Block, and Reject activities, since these are essential to ensuring we can retain the safe spaces that have been created by communities on the Fediverse. Without handling these activities, and ingesting them into the Threads moderator tools, we risk Threads becoming a source of harassment, hate speech and misinformation feeding into the Fediverse, leading it to become much more widely blocked as being "under/un-moderated"; But also for Threads' users to be disinclined to Federate due to perceived moderation issues within the Fediverse (I've seen that cited as a reason for someone not to use Mastodon and to prefer Threads, and not wanting themselves to federate).


For instance, Flag is used when reporting content from one server to another server, and importantly hides the identity of the underlying reporter from the remote server, the report comes through as on behalf of the remote server's "instance actor", and there are some limitations around how Flag activities should be formed in order to ensure maximum compatibility.

There is probably also some guidance needed around as to _what_ is being reported. Some fediverse software, such as Pixelfed, allows for reports on non-Post/Note/Document/Image entities. For instance, reporting a Hashtag or a Link, how should that be handled? (I am trying to convince the Mastodon core team that there's a need to pivot towards a polymorphic report model, such that we can handle Flag activities on non-status content and entities that are not actors).


The Reject Activity is important for the process of saying "no, this user _can't_ follow me", which would be important for giving consent to Threads users over who can follow them. e.g., a Follow activity targeting a non-federating Threads user should automatically send back a Reject(Follow) activity, rather than just silently ignoring that Follow activity, such that the remote instance can keep track of the correct state of the follow and not be left in an indeterminate state.


With Kind Regards,
Emelia Smith
--
Independent Contributor / member of the IFTAS Board of Advisors
https://hachyderm.io/@thisismissem

Received on Friday, 12 January 2024 19:17:08 UTC