MSC2191: Markup for mathematical messages

[uhoreg]

Rendered

This proposal is related to element-hq/element-web#1945, and is a counter-proposal to #1722

Implementations:

• Element Web
• Element Android
• Cinny

FCP tickyboxes

[Half-Shot]

(FYI, matrix-org/matrix-react-sdk#3251 just arrived)

[KitsuneRal]

While I don't have a conclusive "ship it!" opinion about this I certainly believe we should pursue the LaTeX path rather than the MathML one. To alleviate the mentioned issues it may make sense to select the allowed subset of LaTeX - ultimately it's a language for document preparation, not just math rendering, so has much more than necessary to facilitate math chatting.

[thosgood]

(FYI, matrix-org/matrix-react-sdk#3251 just arrived)

@Half-Shot This pull request should be compatible with either proposal choice, but tends more towards this one than the other.

[turt2live]

This is not my sphere of knowledge at all, but LaTeX seems like the better of the options.

[Evidlo]

This may be the wrong place, but what are people's thoughts about blocking this on extensible events? I don't

It seems like exactly the sort of thing extensible events and this might provide enough motivation to get that issue resolved, finally.

[Cadair]

This may be the wrong place, but what are people's thoughts about blocking this on extensible events?

While this could definitely make use of extensible events to provide richer fallbacks, I don't want to block this on it. Extensible events are a massive change and this is reasonably trivial. Would rather see this land imperfectly than wait an undefined amount of time behind a major change to the protocol.

[behrmann]

Just to throw in a user perspective: This is a killer feature for users in a university natural sciences setting and the people who would use this, would mostly not care about having to read LaTeX as a fallback since they use it all the time anyways.

[uhoreg]

This may be the wrong place, but what are people's thoughts about blocking this on extensible events?

Extensible events is solving a different problem. Extensible events is aimed at the situation where the entire message is some strange new thing, not for when the new thing is part of a message. As an example, suppose that both spoilers and this MSC were implemented using extensible events. How would you send a message that had both a spoiler and math? (e.g. What is <span data-mx-latex="x^2">x^2</span> at <span data-mx-latex="x=1">x=1</span>? <span data-mx-spoiler="answer"><span data-mx-latex="1">1</span>) That's not something that extensible events would be able to do very well.

[Evidlo]

Extensible events is solving a different problem. Extensible events is aimed at the situation where the entire message is some strange new thing, not for when the new thing is part of a message.

I guess I misinterpreted m.message, then. I thought it was an ordered list and that the messages of different types were supposed to be concatenated after rendering.

How would you send a message that had both a spoiler and math? (e.g. What is <span data-mx-latex="x^2">x^2</span> at <span data-mx-latex="x=1">x=1</span>? <span data-mx-spoiler="answer"><span data-mx-latex="1">1</span>) That's not something that extensible events would be able to do very well.

    "m.message": [
        {
            "mimetype": "text/x-latex",
            "body": "What is $x^2$ at $x=1$?",
            "formatted_body": "What is x^2 at x=1?"
        },
        {
            "mimetype": "text/html",
            "body": "<span data-mx-spoiler=\"answer\">1</span>",
            "formatted_body": "1",
        }
    ],

If I was writing a TUI client, it seems like the above would be easier, as I could just use off the shelf TeX->plaintext and HTML->plaintext rendering libs for each message part and not need to parse html. If my client doesn't support the message type, then it can just use the fallback for that message part.

[Sorunome]

Extensible events is solving a different problem. Extensible events is aimed at the situation where the entire message is some strange new thing, not for when the new thing is part of a message.

I guess I misinterpreted m.message, then. I thought it was an ordered list and that the messages of different types were supposed to be concatenated after rendering.

How would you send a message that had both a spoiler and math? (e.g. What is <span data-mx-latex="x^2">x^2</span> at <span data-mx-latex="x=1">x=1</span>? <span data-mx-spoiler="answer"><span data-mx-latex="1">1</span>) That's not something that extensible events would be able to do very well.

    "m.message": [
        {
            "mimetype": "text/x-latex",
            "body": "What is $x^2$ at $x=1$?",
            "formatted_body": "What is x^2 at x=1?"
        },
        {
            "mimetype": "text/html",
            "body": "<span data-mx-spoiler=\"answer\">1</span>",
            "formatted_body": "1",
        }
    ],

If I was writing a TUI client, it seems like the above would be easier, as I could just use off the shelf TeX->plaintext and HTML->plaintext rendering libs for each message part and not need to parse html. If my client doesn't support the message type, then it can just use the fallback for that message part.

Your example did not make the 1 answer latex. The idea was to put latex inside a spoiler, which is not possible with that proposed approach

[jvoisin]

I would argue that the vast majority of users will never send mathematical expression to each other. Is the complexity really worth it? LaTeX is non-trivial to parse nor to render.

Also, if Matrix is going to access mathematical notations, what about other domains, like chemistry, physics, … al the myriad of other notations?

[turt2live]

Clients aren't required to render or parse the notation, which is why a fallback is present. Several clients do wish to represent mathematical expressions to users though, and having a consistent and standardized way to do so is important.

MSCs for other notations are equally accepted, provided they have similar fallback mechanics.

[K4LCIFER]

Is this proposal only limited to LaTeX, or would it also extend to more modern alternatives like Typst?

[turt2live]

This proposal is limited to the expression format of LaTeX, whereas Typst appears to be a full document editor. A separate proposal would be required to express Typst, I believe, as it has a different scope.

[K4LCIFER]

whereas Typst appears to be a full document editor.

Errr, well, no — Typst is a typsetting language like LaTeX. They do offer a sort of IDE on the side (which functions similaraly to overleaf) to help fund the project.

[mscbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

[uhoreg]

Is this proposal only limited to LaTeX, or would it also extend to more modern alternatives like Typst?

This proposal states what it is proposing, which is only adding support for the mathematical markup from LaTeX. Any other markup could be proposed in a different proposal.

[uhoreg]

spec PR: matrix-org/matrix-spec#1816

[uhoreg]

Merged! 🎉