This is a discussion thread for the proposed FEP-dc88: Formatting Mathematics.
Please use this thread to discuss the proposed FEP and any potential problems
or improvements that can be addressed.

Summary

This FEP recommends a method for formatting mathematics in ActivityPub
post content in [MathML Core]. Furthermore, this FEP describes how to
sanitize and convert such mathematics to plain text, if an
implementation does not wish to support mathematical formatting.

Thanks for writing this! This FEP will hopefully help make the Mathematics Fedi better.

Two quick questions:

Do I understand it correctly that this is a different process than mathstodon has implemented?

How does MathML Core relate to MathML? My Firefox has problems rendering the MathML Core samples, I just pasted into a html file, but MathML usually works fine.

Do I understand it correctly that this is a different process than mathstodon has implemented?

Yes, all implementations that I know about (mathstodon and types.pl) currently have added client-side LaTeX-like formatting software to their respective web-apps. What this does is render text between certain delimiters (it is currently \( and \) but they have tried quite a few, and several have been incompatible) as math.

But in my opinion this isnât a reasonable solution, since interoperability is hard (even if everybody could agree on delimiters, there are different quirks between different engines) and it can render text from non-math instances incorrectly.

How does MathML Core relate to MathML? My Firefox has problems rendering the MathML Core samples, I just pasted into a html file, but MathML usually works fine.

MathML is a much broader specification, and while it was originally included as a part of HTML5, it was never implemented in full by browsers (firefox tried).
MathML Core is a much more lean, browser-focused specification, and is implemented by all major browsers. The MDM page about MathML core has a better description that I copied from this FEP, as well as a browser compatibility list.

Can you explain a little bit more about the goals of the requirements in the âFormatting Mathematicsâ section? For example, the requirements as follows:

A math element MUST contain one <semantics> child element, and no other children. The <semantics> element MUST contain a [MathML Core] expression as its first child, and at least one <annotation> element. The encoding property of this <annotation> element SHOULD be "application/x-tex", but MAY be "text/plain", and MUST contain a plain-text description of the mathematicsâpreferably in the authored format. The implementation MAY include additional <annotation> or <annotation-xml> elements with other semantic information.

I think, but am not 100% confident, that this requirement is so that clients which do not wish to render math content can remove math elements. If so, this should be explained further since it was very unclear to me while reading the FEP and the language used seemed very opaque.

This requirement was also specifically confusing to me: " The implementation SHALL NOT remove any [Semantic Attributes] or MathML core Elements and instead should replace a math element with text." What is the purpose of this requirement? How is â[replacing] a math element with textâ not âremoving a Math ML core [sic] Elementâ? In either case an element is removed, no? Also, I donât understand how the requirement âThe implementation MAY remove a math element completelyâ from the later section is compatible with the requirement " The implementation SHALL NOT remove any âŠ MathML core Elements". Isnât that a contradiction?

âThe implementationâ is to be interpreted as an ActivityPub conformant Client, ActivityPub conformant Server or ActivityPub conformant Federated Server as described in [ActivityPub] which wishes to produce or consume mathematically formatted content.

Nit: only ActivityPub Clients produce and consume mathematically formatted content. In the ActivityPub specification world, Servers and Federated servers only relay mathematically formatted content produced by others.

The akkoma proof of concept does not seem to be viable due VueJS incorrectly adding MathML tags to the wrong namespace in the DOM. This looks like it is going to be resolved soon (in the next few months) but can serve as an example of potential issues in client implementations.

Yep! This is the goal. I attempted to clarify this in the âSanitizing Mathematically Formatted Textâ section, but this did not appear to work!
Perhaps some background should be added as to how one of the main issues with mathematical formatting up to this point has been that MathML is not âround trippableâ , and this specification aims to improve that for plain-text preferring clients.

My attempt here was to give two alternative methods of sanitizing elements. Care must be taken not to partially sanitize a MathML expression by removing semantic information (the attribute linethickness=0 on mfrac tags is a great example here). Instead, the implementation should strip the <math> node completely and display text.

This wasnât the easiest to lay out precisely. I will try to re-work how to state explicitly that the <math> node can be removed completely.

Looking at this, and playing around, I noticed that in order to properly render mathML core, one needs to include

<head>
<meta charset="utf-8">
</head>

in oneâs document for it to work. Silly people, who type in vi index.html to test something and then type down plain HTML, might find this information useful.

Something entirely different text/markdown+math is not a valid IANA mime type, see

I wasnât attempting to draft using quarto here, and I donât think we need to aim for a registered MIME type for the contentType of the source property. For example, the ActivityPub standard playfully uses text/x-org here, which isnât a registered mime type either.

My idea was that math instances are going to provide a custom way to draft LaTeX in markdown or plaintext (probably by surrounding by instance-specific delimeters) and could provide a custom source contentType to represent this.

In any case, the source property isnât very important in this specification, and was there to represent a valid text encoding of the message. So I suppose it could be changed to text/plain

Iâm a bit concerned with a fallback level for implementations that do not implement this at all. Without any accomodation, formulas will just be sanitized away completely leaving a probably slightly nonsensical message. Though this problem is not unknown, e.g. previous versions of Mastodon removing strikethrough. I myself do not use the formulas that often so I am not really bothered if some users donât understand my post, but others might have issues with that.

oh awesome! is there a revelant (miss, calc, etc.)key PR or issue that I can reference?

Indeed, this is a valid concern. My justification is that math currently federates in an odd way, and this FEP improves upon that somewhat. Other than that, Iâm not sure how to provide a fallback for mathematics that works well with existing scrubbers.

There are these two commits for Foundkey, one for outputting MathML and one for parsing MathML. âParsingâ is just taking the TeX annotation and putting it back into the respective formula notation of MFM, so it will be rendered again by clients. (If there is no TeX annotation, taking the plaintext and rendering it as code block.)