Proposal: Modlists need allowlists

[temujin9]

Is your feature request related to a problem? Please describe.

Modlists as implemented have a gap in usefulness: either they're too small to matter much, or they contain what potential subscribers consider false positives.

Describe the solution you'd like

A way of subscribing to a list that is the mirror of a modlist: preventing muting or blocking by modlists for the subscriber. It should not affect personal mutes or blocks. This is separate from following, or subscribing to a list's feed.

Describe alternatives you've considered

We might instead (or additionally) allow individuals to break through modlists with a follow. That presumes they want that person's content on their following feed, instead of only when they encounter it on feeds. It also doesn't provide symmetry in shareability, which is necessary for fairness and to reduce required work by targeted groups (as with modlists).

I'm glad to contribute code to this, if you agree it's worthwhile to work on, and likely to be accepted once written.

[bnewbold]

I agree with the motivation here: having to take a modlist all-or-nothing can be difficult. Being able to compose multiple lists (additive/subtractive) could expand the number of folks interested in a list, and make this form of moderation more collaborative and customizable.

The biggest downside I can see is complexity and cognitive load: it becomes harder to figure out whether and why content is showing up in various contexts. It feels like some stacking of prioritization would be necessary. Most of the implementation of modlists is in the backend (appview), and we already have had some concerns about performance and scaling (especially with many large modlists subscribed to by many accounts).

I'm personally hopeful that 3rd party labeling services and other product/protocol interventions could fill the gap here. The behaviors, UX, and capabilities with those will be different, but could work better than large modlists.

What are some ways we could achieve the underlying goal here without a complex mechanism for composing lists natively? Lists could be "forks" (duplicated) and edited. An external tool could make it easier to maintain a list which is derivative of one or more other list (eg, a bot that maintains list C as A-minus-B). Maintainers of large lists could split their lists up in to multiple smaller more granular lists (it is relatively easy for folks to follow multiple lists).

[pfrazee]

I do think that having the user's follows override a modlist would make sense?

[temujin9]

Unfortunately, it's the part I like the least because it runs over a use-case I have: muting someone I follow temporarily, until they've gotten the topic I dislike out of their system. I could move that to basic mutes, though, so it's not a deal-breaker.

[temujin9]

To Bryan's points:

Splitting the lists doesn't really address the core problem: partial mismatch between the list-maker's judgement and list-user's.

External tools might do it, but having to go external would be added friction for both users and maintainers. I suppose I could find personal value in an external tool that lets me say "my list X is user A's list B plus user C's list D, minus the people I've written exceptions for", but I fear the average user couldn't locate it to make use of it. I do see the argument that it's as likely to confuse them and be unused in the app as outside it.

I feel like the stacking order should be a set and immutable thing. I can see someone if I don't have them individually blocked, if they're not on any subscribed blocklists, or if they are on a blocklist but also on an allowlist, and vice versa. Similar (but only outbound) for mutes.

[temujin9]

Let me consider what it would take to make the hypothetical "outside the app" tool. I think I can see a path with the Python SDK, and it might at least help highlight why this is better in-app, or (more hopefully) prove you right.

[omniraptorr]

this seems like an example of the goal of 'composable moderation' (letting the user layer different moderation policies/lists on top of each other in different ways). Isn't the goal that the end user should be doing a nontrivial amount of the 'composing' in question? it seems the only way to provide both a transparent and customizable experience.

[temujin9]

First big problem with the "outside tool" implementation that I can see: it violates the privacy of usage that modlists give, forcing people who want to customize to disclose the lists they subscribe to, in making modified duplicates of them. I have a few lists, and I can attest that the potential blowback for negative list-making is pretty strong. I am comfortable with it, but I'm not typical in that regard.

[bnewbold]

This is a great point!

[temujin9]

There's a privacy-preserving possibility, but it would be messy. All of the lists could be held in the service's bsky account, instead of the user's. That may have performance implications.

The second problem I see is that the outside tool is very use-specific. Inside-the-app allowlist might also extend to moderation tags, e.g. bumping the moderation level up one for someone on the list (from Hide to Warn, or Warn to Show). This would have the same benefit as with modlists, of making the base idea more useful and palatable.

[temujin9]

I've given it some time to percolate, and I don't see a great outside path for this. Are you interested in my contributing code to provide either a) full allowlist as suggested, or b) using Following as an allowlist?

[monicaellerose]

did you ever get the green light to contribute to this feature?

[temujin9]

No, I never did. Given the similar issues around labels, I think it's still a worthwhile idea to explore.

[temujin9]

https://bsky.app/profile/msh.bsky.social/post/3l3q63lkfpk2m contains more discussion about why third party tools are a poor patch to this need.

[temujin9]

@bnewbold @pfrazee resurfacing this request, to see if perhaps you now have more interest in it than you did last year.

[temujin9]

It also looks like labelers could use similar functionality: https://bsky.app/profile/laurenshof.online/post/3l3smagpj2z2q

[Hoid]

I think one way to do this that would reduce friction for users would be to have it such that you can override modlist effects within your app by simply either 1) going onto the modlist and clicking an "exclude" button beside their handle (or whatever it shows), or 2) going onto their profile and setting their state the way you want it (unblocked/unmuted/etc.) and behind the scenes this would update an "allowlist" that applies only to that user, and overrides the modlist behavior. so if I have 200 people blocked by a modlist and want to unblock Dave I can either find his name in the mod list and click "exclude" or go to his profile manually and click "unblock" and that will update the allowlist in the background.
the allowlist would almost be more like a master userModOverrideList which would override all mod lists and be stored alongside the user's preferences. the list of who a specific user blocks is stored in the AppView, right, not the PDS? I hear that the user's preferences are stored in the PDS but I assume the AppView calculates who an individual user has blocked/muted/etc. and caches that on the AppView so it doesn't have to reach out to the PDS that often.

[temujin9]

It wasn't what I initially considered, but I like this UX possibility.

[lamrongol]

I think moderation list has many problems and it should be replaced with Ozone labeler service.
Because you can set labeler to see only "Warning", not mute/block like following image.

issues which says moderation list has a problem:

• More granularity with Blocklists/Mutelists/Labels social-app#5536
• Let me unmute single users for my own feed which are muted via a moderation list social-app#3186
• Feature request: display the last time a list was updated social-app#5199
• To prevent moderation list from being abused, notify when updated social-app#2843