Proposal: community.lexicon.preference.feed — Per-author post-type filters

Discussion
1

Summary

Propose a new lexicon community.lexicon.preference.feed that lets users declare which post types from specific accounts they want hidden from their feeds. This is distinct from ATProto mutes (which hide all content from an account) and more granular than per-feed preferences.

Motivation

Users sometimes want to filter out noise while still seeing an account’s original content. Common use cases:

  • Filter reposts from accounts that over-share content
  • Filter quote posts from accounts that frequently quote-block
  • Keep someone’s original posts visible but hide their amplification behavior

Proposed Schema

A single record type stored at rkey self with an array of authorFilter entries:

{
  "$type": "community.lexicon.preference.feed",
  "filters": [
    {
      "subject": "did:plc:alice",
      "types": ["community.lexicon.preference.feed#repost"],
      "createdAt": "2026-04-01T12:00:00Z",
      "updatedAt": "2026-04-01T12:00:00Z"
    }
  ],
  "updatedAt": "2026-04-01T12:00:00Z"
}
Each authorFilter specifies:
- subject: The DID of the author to filter
- types: Array of record $type tokens to hide (e.g., reposts, quote posts)
- createdAt/updatedAt: Timestamps for last-write-wins resolution

Token Types

Primary tokens:

  • #repost — app.bsky.feed.repost records
  • #quote — app.bsky.embed.record or app.bsky.embed.recordWithMedia records

Open to extension: Consumers may support any valid record $type token beyond the known set.

Consumer Behavior

When consuming feeds, clients should:

  1. Fetch the user’s filter record at at://community.lexicon.preference.feed/self
  2. For each post in the feed, check if its author’s DID matches any filter’s subject
  3. If matched, check if the post’s record $type is in that filter’s types array
  4. Remove the post from the feed if the type matches; applying to all feed descriptors: Home, Following, Custom Feeds, List Feeds, Profile feeds (maybe not Search results).

Implementation Status

I have a working implementation on a fork of https://blacksky.community at this branch that:

  • Stores filters as a PDS record
  • Syncs across devices
  • Applies filters globally across all feeds
  • Provides UI for adding/removing filters from post menu, profile menu, and settings

Questions for Community

  1. Namespace placement: Should this live under community.lexicon.preference.feed (alongside ai), or is there a better namespace?
  2. Token openness: Should we encourage supporting any record $type, or restrict to a curated set?
  3. Relationship to mutes: Should we document this as complementary to mutes, or is there overlap to clarify?
  4. Validation approach: Current schema uses knownValues for interop guidance but doesn’t enforce restrictions. Is this the right balance?

Looking for feedback before drafting a formal PR to lexicon-community/lexicon.

4 Likes
2

This was inspired in shape by The community.lexicon.preference.ai lexicon - #11 by pmcewen.bsky.social FWIW

3

Since this is intended to control only client behaviour and permissioned spaces don’t seem too far off at this point, it may be a good idea to aim for these records to be stored privately from the get-go. (There could definitely be some fallout from this otherwise, if someone looks up back-references to their DID or e.g. Clearsky starts surfacing these.)

Since the client still receives the data, I’d love to be able to specify a filter "action" like "hide" or "collapse", where the latter could be used to shrink a filtered post into an expandable “:counterclockwise_arrows_button: ___ reposted ___” or “:left_speech_bubble: ___ replied to ___” line in supporting clients. (On web this can now be implemented beautifully with just a <details> wrapper, display: contents, keyword-size transitions and deferred media, for example.)
I’d prefer this in most cases because it would let me turn down the noise level without becoming entirely oblivious to it.

1 Like
4

it may be a good idea to aim for these records to be stored privately from the get-go.

I debated this but my reasoning against it was mainly to make it more generic (because I might want to see your posts on Bluesky but not care for your reading habits on Bookhive, for example). I do see your point about it becoming socially adversarial.

I don’t think I can see how this would work within the permissioned data space unless you mean like clients authenticating to see these records in one’s space of preferences.

Since the client still receives the data

This is up to the client to determine re: presentation! It could be a complete omission or something akin to mutes currently on Bluesky (which aren’t public).

5

Thinking on it more, I understand what you’re saying more re: this living in permissioned data, @tamme.schichler.de. I don’t necessarily think it always has to be in there but I can see the perks. Another example of this could be a cross-app way to mute or hide content that’s reused across apps (for example, I think Pop.social also uses likes from Bluesky from its lexicon for stuff so this could help hide them in one fell swoop for consenting apps)

1 Like
6

Maybe not “the” preferences space for all apps, since I’m not sure there will be one, but a private “Common Preferences” space (per user) that any app could use to exchange standardised settings like this would be great.

IInm, apps will be able to create their own app-specific spaces and manage instances of these records also in there, but I think that’s independent of this lexicon definition.

You’re right, it’s likely better to configure this per app, if at all, due to UI differences. I hadn’t really considered that.

In theory some algorithmic feeds could use this to exclude certain weights if public :thinking:
To me at least that would brush against being unexpected behaviour. It likely wouldn’t be feasible for feeds that mainly track aggregates for efficiency, either.