Add user-defined post categories and allow follows to turn on and off individual categories

[imax9000]

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

See https://bsky.app/profile/did:plc:ivqrehafyybffh7yxmwhf5n5/post/3kqlujlppgs2a for discussion.

Basically, posting about two or more substantially disconnected topics on a single account doesn't work well. E.g., posting a lot about programming and cooking will annoy with programming content those who follow you for cooking and vice versa.

Describe the solution you'd like

Think about blog tags. Author can set them on a post and subscribers can either filter them in their RSS reader, or directly subscribe to per-tag feeds instead of the main one.

The UX I have in mind is roughly like this:

1. an account can define a few categories for itself, with a description for followers to know what they mean. Categories are account-scoped, so different accounts don't interfere with each other.
2. in a new tab on the profile page followers can toggle on and off each category, and there's another toggle for posts without any category. Then only selected types of posts actually get added to the "Following" feed
3. when posting, the author can check the boxes for each category the post should appear in. By default the categories are inherited from their nearest post up the reply chain.
4. when rendering posts, categories aren't shown in most cases (otherwise they'd can be distracting and lead to many hilarious situations). But it makes sense to display them on your own posts (to easily spot misapplications), and on the profile page (for the followers to roughly see examples of posts in each category)

Describe alternatives you've considered

• I'm currently using separate accounts for this, and it's quite inconvenient.
• Personal custom feeds for each category are cumbersome to maintain. And from the following side - subscribing to a lot of such feeds doesn't lead to satisfactory experience, even with the option to mix them into "Following" is turned on.
• Separate custom feed as a replacement for "Following" to implement the logic is not really viable without the additional metadata on posts and corresponding UIs.

[bnewbold]

Do hashtags work for this, for now? It is possible to hide all posts with specific tags, and easy to create feeds which auto-include posts with a given tag. They also work well with search.

Inline hashtags currently consume post text character count, but the post schema actually does allow out-of-text hashtags as well. Third-party apps can use that part of the schema, and things like search already pick them up.

One thing client apps could do is let accounts indicate specific hashtags as "Categories" that they post about, and then have account-specific hashtag views. Technically the search index supports this today, so it's just an additional view in the app, doesn't need any new infrastructure.

We are also thinking about updates to the feeds system to support "category" style use-cases as well, but that will be a bit of a ways off, while hashtags are usable today.

[imax9000]

Not really, hashtags are global, not account-scoped, and don't propagate down the reply chain.

[bnewbold]

Every post in a thread has a reference to the "root" of the thread; this makes it pretty efficient to fetch/"hydrate" metadata about that top post to all the child posts. This doesn't work if the context/metadata changes mid-thread (eg, between the top and "leaf" posts), but it seems like having the original post set the category is reasonable.

It seems like the tuple (account-did, hashtag) gets you an account-local namespace?

Eg, here are all the posts from a single account on a single topic:
https://bsky.app/search?q=from%3A%40mackuba.eu+%23ruby

That is also a global hashtag, but the definition/context are local in this usecase.

[imax9000]

It seems like the tuple (account-did, hashtag) gets you an account-local namespace?

Concern is what gets included in the "Following" feed, not what's searchable.

Every post in a thread has a reference to the "root" of the thread; this makes it pretty efficient to fetch/"hydrate" metadata about that top post to all the child posts. This doesn't work if the context/metadata changes mid-thread (eg, between the top and "leaf" posts), but it seems like having the original post set the category is reasonable.

That only works when you're starting a new thread. Much more often I'd reply to someone else, who, for example, who mainly posts about cooking and doesn't need to specify any hashtags - then there won't be any relevant tags at the top. Or they might be spelled differently from the ones I'm using.

Another aspect is that hiding a hashtag is global too. For example, I might wanna read programming content from someone who mainly writes in C, but not interested in programming content from someone who mostly works with .NET.

All of these numerous words above are simply elaborating one point: while hashtags are somewhat related to the discussion, their semantic doesn't quite fit the bill, and UX is not there at all.