Skip to content

feat: expose possibly_sensitive and media warning labels - #87

Open
ayanamists wants to merge 1 commit into
public-clis:mainfrom
ayanamists:feat/sensitive-media-fields
Open

feat: expose possibly_sensitive and media warning labels#87
ayanamists wants to merge 1 commit into
public-clis:mainfrom
ayanamists:feat/sensitive-media-fields

Conversation

@ayanamists

Copy link
Copy Markdown

Why

GraphQL already sends legacy.possibly_sensitive and media labels (ext_sensitive_media_warning / sensitive_media_warning). The parser dropped them, so --json / --yaml clients that inline photos cannot tell adult or graphic media from anything else.

This showed up while rendering timelines in Emacs: unmarked photos get inlined, including tweets Twitter already flagged.

What

  • Tweet.possibly_sensitive from legacy.possibly_sensitive
  • TweetMedia.adult_content / graphic_violence / other_warning from the media entity (including nested media_results.result)
  • structured output adds possiblySensitive on tweets and quoted tweets, plus adultContent, graphicViolence, otherWarning on each media item
  • additive only: existing keys are unchanged; new bools default to false

Tests

  • serialization roundtrip for the new fields
  • home timeline fixture with possibly_sensitive + ext_sensitive_media_warning
  • _extract_media nested sensitive_media_warning

Documented in SCHEMA.md.

Twitter GraphQL already returns legacy.possibly_sensitive and
ext_sensitive_media_warning / sensitive_media_warning, but the
parser dropped them. Frontends that inline photos need those
flags to skip adult or graphic media.

Preserve the labels on Tweet / TweetMedia and pass them through
--json / --yaml as possiblySensitive, adultContent,
graphicViolence, and otherWarning.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant