FR: Personal "exceptions" from subscribed mute/block lists

[imax9000]

Use case

Sometimes when you're subscribed to a long-running mute list there are situations where you'd want to make an exception for a few accounts. Reasons for that can be different, e.g.:

• You disagree with the reason they got added to the list (but the overall list is still useful to you)
• You're friends with them and want to see their posts regardless

At the moment the only remedy is completely unsubscribing from the list, which is a bit heavy-handed.

Proposal

Add "negative" list subscription that subtracts the listed accounts (in set theory terms) from all "positive" list subscriptions you have (mute or block).

I don't particularly insist on implementing it this way, it's just what seems natural to me.

[bnewbold]

I'm generally in favor of this sort of thing. There have been related discussions around "overrides" or "priority" of labelers, or arbitrary boolean logic combinations of lists ("A mins B, plus C"; "intersection of X and Y"). I think the principle of user agency is probably the main thing here; if somebody wants to mute/block everybody on one list except a handful of accounts that is fine and makes sense.

The open question is how to get this implemented on both the back end (server) and front end (client, configuring these rules) in a reasonable way. The system is already fairly complex and very load-bearing. It also isn't clear to me what the full requirements are here: it is a little hard to experiment or take things one step at a time with these systems, it would be good to confidence that whatever iteration or set of changes we make would be accessible and make a difference to folks.

For example: could we just have following relationship override whatever block and mute configuration? Or maybe have follows override blocks, but not mutes? Would it be acceptable to have a single per-account "override" list, or is it critical to be able to share overrides composition-ally? Can overrides be public?

A bit of a bummer here that this requires server-side tweaks and we can't just experiment in the client to start.

It isn't a very good experience, but just to list it out, another remedy possible today is to copy or "fork" the list and remove the accounts wanted. Independent tooling could be used to maintain such a list, with updates to the original list periodically/automatically copied over. Not very ergonomic, but maybe better than unsubscribing or waiting indefinitely for AppView support.

[imax9000]

arbitrary boolean logic combinations of lists ("A mins B, plus C"; "intersection of X and Y").

This would be a bad idea. A lot of complexity, and it would make many optimizations in AppView impossible

It isn't a very good experience, but just to list it out, another remedy possible today is to copy or "fork" the list and remove the accounts wanted. Independent tooling could be used to maintain such a list, with updates to the original list periodically/automatically copied over. Not very ergonomic, but maybe better than unsubscribing or waiting indefinitely for AppView support.

Yeah, I already have such tooling (it actually supports arbitrary set operations, using https://github.com/uabluerail/bsky-tools/blob/main/didset/operations.go). But it's not feasible for an average user. Even if it's wrapped into some friendly UI - that won't remove the issue that having a 5k+ of listitems on your account makes some things take a ridiculous amount of time.

[imax9000]

This would be a bad idea. A lot of complexity, and it would make many optimizations in AppView impossible

Actually, it might be not that bad, if you take visibility set calculation out of the serving path (for list changes, update latency even on the order of minutes is not a big deal from user perspective). But I still think additional complexity is not worth the minor benefit, and it would also add to user confusion.

A simple hardcoded "(A1 + A2 ...) minus B" should cover 95% of use cases, and the other 5% will be covered by writing a materialized set into PDS as a list.

[heikadog]

For example: could we just have following relationship override whatever block and mute configuration? Or maybe have follows override blocks, but not mutes?

I spoke about this, but in the case of a more community-defense-centered moderation list, having following relationship override blocks and mutes could be dangerous for community self-defense. Me and my team are not infallible, of course, but it could lead to potential bad actors not being ousted as easily (people could just not check, especially if something like this is automatically set). I'd rather have a per-account, manual allowlist people could add to in case they disagree with a decision a list curator makes for whatever reason, like @bnewbold brought up after this.