💾 Archived View for blakes.dev › hdoc › WaOUus4PTrWtDhH45o0U1A.source.txt captured on 2024-12-17 at 09:19:38.
View Raw
More Information
⬅️ Previous capture (2024-05-10)
-=-=-=-=-=-=-
---
title: Thoughts on the current state of Matrix-as-MIMI
---
The most recent [Matrix-as-MIMI ("Matrix as a Messaging Framework" or "Linearized Matrix") document](https://turt2live.github.io/ietf-mimi-matrix-framework/draft-ralston-mimi-matrix-framework.html) I can find is more or less a summary of Matrix as it is. In my opinion, this is bad.
- 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"
}
}