|
| 1 | +# MSC4230: 'Animated' flag for images |
| 2 | + |
| 3 | +Since animated images are thumbnailed to a still image, clients need to download the full |
| 4 | +image in order to display an animated image (or even to tell whether or not it is animated). |
| 5 | +However, there is currently no way of telling that an image is animated without downloading |
| 6 | +the original image. This means that clients wishing to display the image as animated must |
| 7 | +download the original image for any image format which is capable of being animated. This |
| 8 | +means they download the full size image for non-animated images even when the user never |
| 9 | +chooses to enlarge the image. |
| 10 | + |
| 11 | +Even clients that animate images on hover must pre-fetch the full size image if they want the |
| 12 | +animation to start without a delay while it's downloaded. |
| 13 | + |
| 14 | +## Proposal |
| 15 | + |
| 16 | +We add an optional boolean flag, `is_animated` to the `info` object of `m.image` and `m.sticker` events indicating if |
| 17 | +the image is animated or not. This SHOULD match whether the original image contains animation. Note |
| 18 | +that this will require clients probe the image file for animation. If a client is unable to determine |
| 19 | +whether an image is animated, it should leave the flag unset. |
| 20 | + |
| 21 | +Example: |
| 22 | + |
| 23 | +```json5 |
| 24 | +{ |
| 25 | + "body": "partyparrot.gif", |
| 26 | + "file": { |
| 27 | + [...] |
| 28 | + }, |
| 29 | + "info": { |
| 30 | + "w": 640, |
| 31 | + "h": 480, |
| 32 | + "mimetype": "image/gif", |
| 33 | + "size": 35295, |
| 34 | + "is_animated": true, |
| 35 | + } |
| 36 | +``` |
| 37 | +
|
| 38 | +If this flag is `false`, receiving clients SHOULD assume, but not trust, that the image is not animated. |
| 39 | +If `true`, they SHOULD assume that it is, again, without trusting. |
| 40 | +
|
| 41 | +Behaviour when the field is omitted is left up to the client. They might choose to behave as if it is present |
| 42 | +and set to `true`, ensuring backwards compatibility whilst still saving bandwidth for images where the flag |
| 43 | +is present and set to `false`. Perhaps they might decide to change this behaviour once more clients start |
| 44 | +sending the flag. |
| 45 | +
|
| 46 | +## Potential issues |
| 47 | +
|
| 48 | +Clients may lie about the flag which would cause unexpected behaviour, for example, an image which |
| 49 | +the client did not tell the user was animated might then animate when the user clicks to enlarge it, |
| 50 | +allowing for 'jump scares' or similar. Clients may wish to prevent images from being animated if the |
| 51 | +flag is set to false. |
| 52 | +
|
| 53 | +As above, supporting animated images becomes harder for sending clients because they must work out if |
| 54 | +an image is animated in order to set the flag. We must accept that some clients, particularly browser-based |
| 55 | +clients, may get this wrong. |
| 56 | +
|
| 57 | +## Alternatives |
| 58 | +
|
| 59 | +We could specify that clients behave as if the flag is set to true if it's absent. This would mean |
| 60 | +clients that didn't want to probe images on upload could omit the flag, at the expense of receiving |
| 61 | +clients needing to download the original to probe for animation. |
| 62 | +
|
| 63 | +We could require that servers, or clients in the case of encrypted rooms, preserve animation on |
| 64 | +thumbnailing. This is quite a burden for clients and would make thumbnails larger. |
| 65 | +
|
| 66 | +This could also potentially be extended to `m.sticker` events. |
| 67 | +
|
| 68 | +## Security considerations |
| 69 | +
|
| 70 | +Potential for clients to lie about the flag and cause unexpected animation is covered in 'Potential |
| 71 | +Problems'. |
| 72 | +
|
| 73 | +## Unstable prefix |
| 74 | +
|
| 75 | +Until stable, the flag will be `org.matrix.msc4230.is_animated`. |
| 76 | +
|
| 77 | +## Dependencies |
| 78 | +
|
| 79 | +None. |
0 commit comments