Duplicated mimetype info when sending an image to a room

[bmarty]

When I send an image to an e2e room using Element Web, the clear event contains undocumented fields:

{
  "type": "m.room.message",
  "content": {
    "body": "image.png",
    "info": {
      "size": 16144,
      "mimetype": "image/png",
      "thumbnail_info": {
        "w": 166,
        "h": 72,
        "mimetype": "image/png",
        "size": 4770
      },
      "w": 166,
      "h": 72,
      "thumbnail_file": {
        "v": "v2",
        "key": {
          "alg": "A256CTR",
          "ext": true,
          "k": "rpj1sOJ6wO2oy3R0TkmzMtlTfq8gw34DDjBEomEcFg4",
          "key_ops": [
            "encrypt",
            "decrypt"
          ],
          "kty": "oct"
        },
        "iv": "mTh8NqPZ4XgAAAAAAAAAAA",
        "hashes": {
          "sha256": "VehmjJbux6m63u/zWs2zZCElqqGgQ5pFuUNzmm1uovg"
        },
        "url": "mxc://matrix.org/pKlpKPCIpzUBNElxmaAvuwbh",
        "mimetype": "image/png" << This is not documented and redundant info
      }
    },
    "msgtype": "m.image",
    "file": {
      "v": "v2",
      "key": {
        "alg": "A256CTR",
        "ext": true,
        "k": "7ApOyV_yijdMcXWMBvxApSwc_Nkl39GBxhSY3GdZRNI",
        "key_ops": [
          "encrypt",
          "decrypt"
        ],
        "kty": "oct"
      },
      "iv": "eH/zzQF1HEEAAAAAAAAAAA",
      "hashes": {
        "sha256": "EPedp3jPqlPPS4OCInieN9u5X4KHpbGVzb/1LAmIH/g"
      },
      "url": "mxc://matrix.org/TXyRLVIClHHgxJHFwcBfNMLd",
      "mimetype": "image/png" << This is not documented and redundant info
    }
  }
}

According to https://matrix.org/docs/spec/client_server/r0.6.1#extensions-to-m-message-msgtypes, EncryptedFile.mimetype is not documented (but are present in the examples!), and the information it contains is already present at other place in this content.

For some reason, there is the same problem on Element Android, so this issue is probably more a question: why are we adding those fields?

[bmarty]

Or maybe those 2 redundant mimetypes should be set to application/octet-stream? But this would be the only possible value, so very useless...

[turt2live]

This sounds like a spec bug instead of an Element bug. The fields should be documented if they are in the examples, and Android shouldn't have a problem with unknown fields...

[bmarty]

Android does not have pb with unknown fields, I'm not saying that, I just try to understand.

I would like to clean up the Android code to remove those unknown fields, and I'm wondering if it's OK to do that, regarding the spec diff between doc and example.

@anoadragon453 any thoughts about this?

[anoadragon453]

I have a sneaking suspicion that the example was just ripped out of Element Web's /devtools at some point without checking the contents too closely...

If the field is truly redundant and not necessary, I don't think there's any reason to add it to the spec - and the example should be corrected. Element Web - if they want - will need to remove the fields and take care that nothing crucial that relies on it breaks.

If the field is actually useful, then someone should write an MSC for it. Additionally, the field existed before unstable prefixes were introduced, so Element Web shouldn't need to switch to unstable prefixes in this case.

[bmarty]

I've remove the field on Element Android in element-hq/element-android#3273

[bmarty]

FTR removing those fields seems to break Element iOS :/

[anoadragon453]

Worth noting here that this field was apparently intended to be duplicated in the spec, and that's there's currently an open MSC to remove it: matrix-org/matrix-spec-proposals#2582

[bmarty]

this field was apparently intended to be duplicated in the spec

I'm just curious, what makes you say that?

[anoadragon453]

@bmarty I wish I remembered - silly old me forget to leave a reference.

[bmarty]

no worries :)

[anoadragon453]

Now that the spec has removed these fields (MSC2582), I don't believe there are any more blockers to stop sending this information.