Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AT: Bridgy ignores auto-applied sensitive content labels #1418

Closed
asonix opened this issue Oct 24, 2024 · 7 comments
Closed

AT: Bridgy ignores auto-applied sensitive content labels #1418

asonix opened this issue Oct 24, 2024 · 7 comments
Labels
see other The issue was a duplicate or was fully merged into another issue.

Comments

@asonix
Copy link

asonix commented Oct 24, 2024

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 :(

@asonix asonix changed the title AT: Bridgy ignores auto-applied sensitive content-labels AT: Bridgy ignores auto-applied sensitive content labels Oct 24, 2024
@Tamschi Tamschi added compat Protocol differences that need special handling. safety Related to user safety. labels Oct 24, 2024
@Tamschi
Copy link
Collaborator

Tamschi commented Oct 24, 2024

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
Copy link
Author

asonix commented Oct 24, 2024

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
Copy link
Collaborator

Tamschi commented Oct 24, 2024

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
Copy link
Owner

snarfed commented Oct 24, 2024

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
Copy link
Collaborator

Tamschi commented Oct 24, 2024

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
Copy link
Owner

snarfed commented Oct 24, 2024

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 Tamschi added see other The issue was a duplicate or was fully merged into another issue. and removed safety Related to user safety. compat Protocol differences that need special handling. labels Oct 24, 2024
@Tamschi
Copy link
Collaborator

Tamschi commented Oct 24, 2024

Closed as duplicate of #971.

@Tamschi Tamschi closed this as not planned Won't fix, can't repro, duplicate, stale Oct 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
see other The issue was a duplicate or was fully merged into another issue.
Projects
None yet
Development

No branches or pull requests

3 participants