Proposal 0001 & 0002 - combining labelling with gating

[Bossett]

These are currently being discussed in isolation, but there are a couple of key opportunities in combining the concepts of labelling services with user-driven thread control:

1. Default locks

Where a user is using a moderation service that flags another user, the poster should be able to elect to have that post appear locked to that other user. For example, if I have a labelling service that return 'hate speech' for an author, that author should not be allowed to reply to my posts.

2. Labelling alignment

Where a user is using a labelling service, they should be able to lock posts to only users that label the post using the same tags. That is: if I post something marked 'suggestive', I should be able to lock out users that would mark the same post as 'hate speech'. This would impede circumstances where labelling services are weaponised against other users to flag posts for harassment.

[NetWalker108]

if I have a labelling service that return 'hate speech' for an author, that author should not be allowed to reply to my posts.

But this isn't what Labelling services are being built for. It sounds like what you want is middleware that updates a "block list" when a Labeller tags an account for a given reason, instead.

if I post something marked 'suggestive', I should be able to lock out users that would mark the same post as 'hate speech'.

The onus would be up to your target audience to not subscribe to Labellers that will mark your content negatively and you to suggest what Labellers they should subscribe to, in addition to offering them dedicated feeds. Best alternative is for you to self-add neutral/positive labels to your post and advise your target audience to accept those labels(or make them exceptions in their chosen moderation policies).

[Bossett]

But this isn't what Labelling services are being built for. It sounds like what you want is middleware that updates a "block list" when a Labeller tags an account for a given reason, instead.

Understand this - hence, 'combining'. And yes, this may be done with some middleware that manages a locked post on the user's behalf. We have a situation where tooling will exist such that all the information required exists to make this happen, and this is opportunity to bring these together.

onus would be up to your target audience to not subscribe to Labellers

This is not about target audience, this is about wildly varying views of content. If I use labeller A and you use labeller B, and they fundamentally disagree with a label (i.e. 'hate speech' v 'suggestive'), we are incredibly unlikely to have a productive interaction. This is about limiting the ability for people weaponise labellers, not to police their own content.

[NetWalker108]

If I use labeller A and you use labeller B, and they fundamentally disagree with a label (i.e. 'hate speech' v 'suggestive'), we are incredibly unlikely to have a productive interaction.

I wouldn't know what Labeller you're using(or what labels you're assigning to posts) and in most cases I wouldn't need to, and vice versa. Furthermore, there'd be likely no interaction at all given the content will likely either be hidden or deprioritised in my feed.

Alternatively, users interact with posts and other users that they've either filtered or muted everyday, and I doubt that affects the innate productivity of those interactions.

[Bossett]

Consider the adversarial case - user A is a controversial figure, like a BLM activist. Their whole account is 'hate speech' to user B.

User A posts something that isn't flagged. I am proposing that steps are taken to lock out, either in the protocol or in the AppView, etc., user B from posting under User A.

There are a bunch of ways to do this - we have 'likes' on non-post items (like feeds), so we could just say 'if B likes service X, lock'. This is one example, there are others - and if there's any interest in this, I'm sure a bunch of people will come out of the woodwork.

Does this totally cut out bad actors? No. But requiring them to go to specialised harassment tools (like sheets/other channels/other apps) will significantly reduce their impact.

[NetWalker108]

User A posts something that isn't flagged. I am proposing that steps are taken to lock out, either in the protocol or in the AppView, etc., user B from posting under User A.

This is essentially what a Block action does today, at the protocol level++. Where User A can block User B, and vice versa.

Also, if the post by User A isn't flagged for User B (assuming it should have), it would be because User B didn't take steps (mute, set up filters, subscribe to Labeller) or those steps failed to function effectively.