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

MSC4230: Flag for animated images #4230

Open
wants to merge 8 commits into
base: main
Choose a base branch
from
Open

Conversation

dbkr
Copy link
Member

@dbkr dbkr commented Nov 21, 2024

Proposes adding a boolean flag to images that indicates whether they're animated.

Impl: element-hq/element-web#28513

Rendered

Disclosure: This is presented wearing my, "Element Employee and Element Web Engineer" hat.


FCP tickyboxes

MSC checklist

@turt2live turt2live added proposal A matrix spec change proposal client-server Client-Server API kind:feature MSC for not-core and not-maintenance stuff needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels Nov 21, 2024
@turt2live turt2live marked this pull request as draft November 21, 2024 16:24
@dbkr dbkr marked this pull request as ready for review November 21, 2024 17:07
@dbkr dbkr changed the title [Placeholder] Flag for animated images Flag for animated images Nov 21, 2024
@dbkr dbkr changed the title Flag for animated images [MSC4230]: Flag for animated images Nov 21, 2024
@dbkr dbkr changed the title [MSC4230]: Flag for animated images MSC4230: Flag for animated images Nov 21, 2024

## Proposal

We add an optional boolean flag, `ia_animated` to the `info` object of image events indicating if
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To clarify, this field would be allowed in the info on msgtype: m.image and type: m.sticker events?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess just images for now: clarified.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason not to allow it for stickers?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not really sure to be honest, which is exactly why I'm leaving it for someone else to propose if they think it's appropriate.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that stickers are ~renamed images, I agree with Sumner that the same should apply to stickers.

We don't have extensible events yet, but MSC3552 goes in the same direction about the images and stickers relation ship.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, let's do it for stickers too.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm afraid I am somewhat drowning with other commitments at the moment. If anyone would like to propose an update to this that would encompass stickers then please go ahead, otherwise I will put this on the back burner for a bit.

Co-authored-by: R Midhun Suresh <[email protected]>

Clients may lie about the flag which would cause unexpected behaviour, for example, an image which
was not presented might then animate when the user clicks to enlarge it, allowing for 'jump scares'
or similar. Clients may wish to prevent images from being animated if the flag is set to false.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't be sensible for an implementation to use this flag only as a hint as to whether it should preload the original, and probe the media regardless of when it was downloaded to confirm the animation? I feel like this MSC is recommending a client behaviour that is a tad too "trusting".

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They could do that if they saw a need to. I've tried to be specific though and call out a distinct case where clients might want to take care over. I don't think it's really the spec's job to enumerate every detail that clients might possibly mess up, although we can certainly give more hints if you think there's something else worth calling out.


## Proposal

We add an optional boolean flag, `is_animated` to the `info` object of `m.image` events indicating if
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to bring it up, we could also give this flag a more general name prefetch_original to express "you might wanna prefetch this", and apply it optionally to any attachment type. A client might assume based on the attachment type, mime type, flag, and other metadata combinations, whether it wants to prefetch, e.g. to play an animated image/gif without delay. Then again I fail to come up with other reasons you might want to hints about prefetching attachments.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally I'm more persuaded by the idea of giving information about the media rather than trying to second guess what the client might want to do.

Co-authored-by: Will Hunt <[email protected]>
@zecakeh
Copy link
Contributor

zecakeh commented Jan 13, 2025

This is implemented in Fractal too as of today:

@dbkr dbkr removed the needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. label Feb 19, 2025
@dbkr
Copy link
Member Author

dbkr commented Feb 19, 2025

As per discussion on element-hq/element-web#28311 and since this now has 2 impls, I'm going to

@mscbot fcp merge

@mscbot
Copy link
Collaborator

mscbot commented Feb 19, 2025

Team member @mscbot has proposed to merge this. The next step is review by the rest of the tagged people:

Concerns:

  • Checklist incomplete

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.

@mscbot mscbot added proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the final comment period. disposition-merge labels Feb 19, 2025
@turt2live
Copy link
Member

turt2live commented Feb 24, 2025

MSCs proposed for Final Comment Period (FCP) should meet the requirements outlined in the checklist prior to being accepted into the spec. This checklist is a bit long, but aims to reduce the number of follow-on MSCs after a feature lands.

SCT members: please check off things you check for, and raise a concern against FCP if the checklist is incomplete. If an item doesn't apply, prefer to check it rather than remove it. Unchecking items is encouraged where applicable.

Checklist:

  • Are appropriate implementation(s)
    specified in the MSC’s PR description?
  • Are all MSCs that this MSC depends on already accepted?
  • For each new endpoint that is introduced:
    • Have authentication requirements been specified?
    • Have rate-limiting requirements been specified?
    • Have guest access requirements been specified?
    • Are error responses specified?
      • Does each error case have a specified errcode (e.g. M_FORBIDDEN) and HTTP status code?
        • If a new errcode is introduced, is it clear that it is new?
  • Will the MSC require a new room version, and if so, has that been made clear?
    • Is the reason for a new room version clearly stated? For example,
      modifying the set of redacted fields changes how event IDs are calculated,
      thus requiring a new room version.
  • Are backwards-compatibility concerns appropriately addressed?
  • Are the endpoint conventions honoured?
    • Do HTTP endpoints use_underscores_like_this?
    • Will the endpoint return unbounded data? If so, has pagination been considered?
    • If the endpoint utilises pagination, is it consistent with
      the appendices?
  • An introduction exists and clearly outlines the problem being solved.
    Ideally, the first paragraph should be understandable by a non-technical audience.
  • All outstanding threads are resolved
    • All feedback is incorporated into the proposal text itself, either as a fix or noted as an alternative
  • While the exact sections do not need to be present,
    the details implied by the proposal template are covered. Namely:
    • Introduction
    • Proposal text
    • Potential issues
    • Alternatives
    • Dependencies
  • Stable identifiers are used throughout the proposal, except for the unstable prefix section
    • Unstable prefixes consider the awkward accepted-but-not-merged state
    • Chosen unstable prefixes do not pollute any global namespace (use “org.matrix.mscXXXX”, not “org.matrix”).
  • Changes have applicable Sign Off from all authors/editors/contributors
  • There is a dedicated "Security Considerations" section which detail
    any possible attacks/vulnerabilities this proposal may introduce, even if this is "None.".
    See RFC3552 for things to think about,
    but in particular pay attention to the OWASP Top Ten.

@turt2live
Copy link
Member

@mscbot concern Checklist incomplete

(I haven't attempted to pre-populate it this time, sorry)

@mscbot mscbot added the unresolved-concerns This proposal has at least one outstanding concern label Feb 24, 2025
Comment on lines +38 to +39
If this flag is `false`, receiving clients can assume that the image is not animated. If `true`, they should
assume that it is.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The strength of these statements is not quite clear to me in relation to the SHOULD when sending images. Do you intend for "can assume" and "should assume" to translate into "MAY assume" and "SHOULD assume" in the spec?


## Proposal

We add an optional boolean flag, `is_animated` to the `info` object of `m.image` events indicating if

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unrelated thread: how would this work with inline emojis?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

emojis are not animated?

Copy link
Member

@tulir tulir Feb 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Emojis can definitely be animated. Might be better to leave adding a new attribute like data-mx-animated-emoticon to a different MSC though (perhaps MSC2545, or a completely new one, or reuse the data-mx-emoticon attribute by giving it a value)

Copy link
Member

@richvdh richvdh Feb 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it might be that we're using different definitions of "emoji". Are they not just a unicode codepoint? (Which, sure, a client can animate if it wants to be cute, but that's not something we need to represent in an event body)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm assuming the question was about custom emojis, which are inline images (<img> tags in formatted_body)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That was definitely not clear from the question! But yes, that sounds like a question for another MSC, given that such things aren't yet specced.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It also seems irrelevant since there would be no thumbnail support here anyway.

Since animated images are thumbnailed to a still image, clients need to download the full
image in order to display it animated. However, there is currently no way of telling that
an image is animated without downloading the original image. This means that clients wishing
to display the image as animated must download the original image for any image format which
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what does "display the image as animated" mean? An annotation in the UI? Or actually making an animated thumbnail?

Either, I guess. Would be good to be clearer though.

image in order to display it animated. However, there is currently no way of telling that
an image is animated without downloading the original image. This means that clients wishing
to display the image as animated must download the original image for any image format which
is capabale of being animated. This means they download the full size image for non-animated
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
is capabale of being animated. This means they download the full size image for non-animated
is capable of being animated. This means they download the full size image for non-animated


## Proposal

We add an optional boolean flag, `is_animated` to the `info` object of `m.image` events indicating if
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

emojis are not animated?

## Potential issues

Clients may lie about the flag which would cause unexpected behaviour, for example, an image which
was not presented might then animate when the user clicks to enlarge it, allowing for 'jump scares'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"was not presented"?


## Proposal

We add an optional boolean flag, `ia_animated` to the `info` object of image events indicating if
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, let's do it for stickers too.

@richvdh
Copy link
Member

richvdh commented Feb 25, 2025

Other than the nit-picking, this looks good to me, except that I agree with the "let's extend this to stickers" thread.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client-server Client-Server API disposition-merge kind:feature MSC for not-core and not-maintenance stuff proposal A matrix spec change proposal proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the final comment period. unresolved-concerns This proposal has at least one outstanding concern
Projects
Status: Ready for FCP ticks
Development

Successfully merging this pull request may close these issues.