Pseudo-labels for post types (generic labels like "image")

[aendra-rininsland]

I don't know a better way to phrase this, but this conversation I was tagged into is kind of interesting, a user is wanting the ability to put all image content behind an Image label. This is imagined as a sort of a "super safe for work" mode, felt was worth opening a discussion about it given it might be helpful as an accessibility feature:

https://bsky.app/profile/temujin9.t9productions.com/post/3kubrqaui5c2h

I'm admittedly really hesitant to use XBlock to that end (it's not really in its remit and would create a lot of overhead), especially because it feels like an appview-level feature request -- it feels redundant to add a generic "Image" label to all image content when the appview already knows a post has an image by virtue of it having the app.bsky.embed.images type, and could make showing or hiding it less of a moderation-level thing and more of an app feature.

For an example of prior art with this, the Mastodon server software has this option:

Another way of approaching this might be to give a settings menu that allows granular control over which post types are visible in the interface, which might be something that could be combined with e.g. the animated gif settings.

[surfdude29]

Another way of approaching this might be to give a settings menu that allows granular control over which post types are visible in the interface, which might be something that could be combined with e.g. the animated gif settings.

Related to this, there is a PR for the app from earlier this year which would add a data-saving mode that hides all images:

bluesky-social/social-app#2539

[bnewbold]

Yeah, I think it would probably be best to not use labels (and label services) for things that can easily and reliably computed about content, such as whether a post has an image at all. I'm not sure how to describe the boundary line though. For example, I'd kind of prefer that we include account creation date (or "activation" or "seenAt", or whatever similar signal) as part of profile views, which could reduce the need for "new-account" labels specifically. But it is a bit subtle because there are multiple ways to define "new". And it is cool how folks can immediately use labels as a standard interface/API for client config, without waiting for client code to be written to support things like "just don't show posts with images": they can self-serve by writing a labeler and configuring it in app! Can bypass the dev bottleneck, which is great and very inline with atproto/bsky goals.

The concept of "virtual labels" is pretty interesting as a way around this. To make it extensible, maybe would be a little S-EXPR or WASM snippet (or SQL, or jq?) in a record somewhere, and clients compute it locally?

[MasterJ93]

Isn't this sort of easy to do though (without the need for labels)? Isn't it as simple as looking at the record and checking if it has app.bsky.embed.image? Or am I misunderstanding something and it's much more complicated than I imagine?

[bnewbold]

It is easy for app developers to look at record and check this sort of thing!

I think one of the cool advantages of the labeling system is that folks can experiment and control their experience without waiting for app developers to add features or configuration. They might not add the features because of time and resource constraints; desire for simplicity; or ideological disagreement.