AT: Bridgy ignores auto-applied sensitive content labels

[asonix]

Similar to #1099

I noticed that a post that is marked as "graphic content" on bsky came through to AP without a content warning and the media was not marked as sensitive. I think if the media is sensitive on one side, it should also be sensitive on the other side.

I don't know enough about ATProto to offer any suggestions on how this could be implemented, sorry :(

[Tamschi]

It should be possible, as ATProto sends label updates on the firehose too.

It would require Bridgy Fed to keep track of label state itself or query labels from Bluesky, or quite possibly both really. It's a bit tricky because Bridgy Fed effectively bridges posts from Bluesky retroactively if they are referenced and may have missed the label on the firehose due to that, but label will also become visible in AppView queries only some time after it arrives on the firehose (which should trigger an Update on the AP side).
Maybe looping the task until the label becomes visible there could work though 🤔

It's also likely not going to be 100% reliable, but it's feasible to notify the servers where the post author has followers at least.
(I think this is how most fediverse software handles distribution of Updates, but please correct me if I'm wrong.)

(All that said, this hopefully is going to be a bit less of an issue soon since Bluesky should enable "Graphic content" self-labels in their client in the next update. Still labeling it "safety" though so that it stays on the radar.)

[asonix]

That's really a shame that labels come through after the post as separate objects. I'm not sure how mastodon handles retroactively applying as:sensitive but I guess we can find out if the bridge starts doing that

I do think attempting to handle this is important since many folks on bluesky will rely on the auto-tagging feature even after self-tagging becomes available

[Tamschi]

Mastodon can apply the sensitive flag due to updates, here: https://github.com/mastodon/mastodon/blob/37bcbeab4aead09c4884827b8a7625c5070ab192/app/services/activitypub/process_status_update_service.rb#L156

[snarfed]

Yes! Bluesky already translates self-labels in Bluesky posts, but not labels emitted by labelers aka mod services, including the Bluesky team's. Sounds like this may be a duplicate of #971? I think that tracks this idea.

Re updates, BF does currently handle and translate the fediverse sensitive flag to a Bluesky self-label in both Creates and Updates, but sadly Bluesky itself doesn't surface edits to records in bsky.app, #947, so Bluesky users probably won't see self-labels applied via updates yet.

Also, minor technical point, labels from labelers aren't in the relay's firehose. You have to find and subscribe to each labeler separately, via com.atproto.sync.subscribeRepos, to see its labels. That's what makes #971 a somewhat more substantial project.

[Tamschi]

Yes! Bluesky already translates self-labels in Bluesky posts, but not labels emitted by labelers aka mod services, including the Bluesky team's. Sounds like this may be a duplicate of #971? I think that tracks this idea.

Ah, yes sorry, I forgot. Is it okay if I close this as duplicate and label the other issue?

Also, minor technical point, labels from labelers aren't in the relay's firehose. You have to find and subscribe to each labeler separately, via com.atproto.sync.subscribeRepos, to see its labels. That's what makes #971 a somewhat more substantial project.

Oh, well that's annoying. Is there a specific reason for that?
I'm assuming there's an endpoint to get the list of known labellers from the AppView, at least…

[snarfed]

Ah, yes sorry, I forgot. Is it okay if I close this as duplicate and label the other issue?

Yes! Thank you!

Oh, well that's annoying. Is there a specific reason for that?

Labels and labelers are a bit separate architecturally from ATProto repos, relays, appviews, etc. Notably, labels don't live in repos; labelers stored and serve them separately. I think that came from some safety desires for moderators and mod services, eg not making labels easily enumerable or downloadable in bulk, at least by default: https://atproto.com/specs/label#label-distribution-endpoints

I'm assuming there's an endpoint to get the list of known labellers from the AppView, at least…

Indirectly yes, you can ingest the whole network and look for users who have a chat declaration record, https://docs.bsky.app/docs/advanced-guides/moderation#labeler-declarations . I don't think they have a queryable centralized directory yet though, just like there's no easily queryable centralized directory of PDSes. 🤷

[Tamschi]

Closed as duplicate of #971.