💾 Archived View for blakes.dev › hdoc › WaOUus4PTrWtDhH45o0U1A.gmi captured on 2024-12-17 at 09:19:32. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

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"
    }
}