Thoughts on the current state of Matrix-as-MIMI

The most recent Matrix-as-MIMI ("Matrix as a Messaging Framework" or "Linearized Matrix") document[1] I can find is more or less a summary of Matrix as it is. In my opinion, this is bad.

➤1: "Matrix-as-MIMI ("Matrix as a Messaging Framework" or "Linearized Matrix") document"

➤Source (manually imported from Hedgedoc)

• It seems to still mandate that the entire message history be available at all times. Some services cannot or don't want to do it.
• It's still using Matrix-style messages, which is cool and all, but I'd definitely rather use standard typing that's already well understood: MIME types. I am in support of MSC1767-style "mixins" and extra fields being allowed, but we should be using MIME types for most things.
• The odd arbitrary `mxc:` URIs for media need to go. I'm not sure if it's even standard but HTTPS URIs should be the go-to. Even for existing Matrix stuff. It just complicates resolution, even if in theory it would let you change the "real" subdomain of the server -- you're never going to do that anyway.
• It still mandates Matrix style IDs. Nobody likes the odd Matrix style IDs. They just make things more confusing. It's not intuitive, it's not pronounceable, it's just confusing.
• Individual mixins shouldn't be a part of the spec, implied or otherwise. We should have a registry for publicly-useful mixins, types, and states.

In all honesty, I'd like to write a better spec, but I don't know enough about the federation mechanics to do that. Such a spec should be heavily inspired by, but ultimately independent from, the existing Matrix spec; basically, a summarized version, but complete, better, and respective of existing, easy to use standards like MIME types.

Possible MIME structures

Irrelevant fields omitted.

{
    "type": "text/plain",
    "content": {
        // `body` is used as a JSON-stringified body. It could be binary.
        "body": "This is a plain text body.",
        "m.automated": true
    }
}

{
    "type": "multipart/alternate",
    "content": {
        // Multipart types use `parts`, where each item is a part
        "parts": [
            {
                "type": "text/markdown; variant=CommonMark; lang=en_US",
                "body": "# This is a CommonMark document in English!"
            },
            {
                "type": "text/markdown",
                "body": "This is probably original or GFM markdown, and it could be in any language. Don't allow any special formatting."
            }
        ]
    }
}

{
    "type": "application/json",
    "content": {
        // JSON types do not use the body field
        "first": "John",
        "last": "Doe",
        "age": 48
    }
}

{
    "type": "image/png",
    "content": {
        // you can use url in place of body to look up the contents; usually this is only done for media types but no such mandate is made
        "url": "https://example.org/cat.png"
    }
}