Modern XMPP project discussion - 2026-04-23

> stokito, what you want is close to https://xmpp.org/extensions/xep-0394.html This XEP has problems: 1. It's difficult to implement: you need to convert your internal doc tree to the new and then serialize it back. You may already have a text in the HTML in your rich editor and now you have to spend resources on this conversion. 2. The payload with formatting is too big. This might be some some RLE-like string "2<b>4</b>" i.e. bold from 2 to 4. 3. The formatting is not seen in the original string like in markdown when even without a styling you may see that something is `**bold**`. Even if a user will see the raw html that still is better. 4. You have to negotiate in the XEP and reintroduce all tags and attributes that you wish to use. For example if I wish to use the `<details>` tag to hide the spoiler tag then this may be never added to the xep and other clients simply won't have a mapping implemented while a client's renderer can simply process the tag. So we have a problem that by default in the HTML all should be allowed except of dangerous tags (script, iframe). But with the XEP we have everything blocked by default, unless. 5. The markup is better to be in the message because it can be processed additionally. For example the Spark client has a Translator so after the translation word positions will be changed. This is my problem because now I have to serialize the XEP to HTML before processing i.e. translation. That's fine but I just feel stupid because why would we separated markup if anyway we had to merge it again later.

There isn't really any negotiation anymore because you don't know what clients may receive the message later via archives.

Ok so the XEP-0394 is used only by the Dino.The Pidgin 2 and Psi use the XHTML-IM when sending a rich formatted message and it will be more difficult for them to migrate to the XEP-0394.

stokito, 1. you assume that people have an internal doc tree. That's not the case for native implementations on a lot of platforms, at least not on iOS, Android and GTK. Those platforms have an internal format that's similar to XEP-0394 (in that it uses a range and applies formatting to a range). iOS calls it text attributes, android spans, GTK pango attributes. 3. Formatting markup that is inside the body can be removed when using XEP-0428 annotations 4. The <details> tag is not supported by XHTML-IM either. If you used it it would be random if it is supported by the receiving client (and there is no way to negotiate). Many clients that do suport XHTML-IM also don't use a full HTML engine. Cheogram, as an example, actually converts the HTML into the Android native format and then displays that. That format has way less features than HTML, so a bunch of valid HTML is just dropped.

And the Dino always sends the <markup> even if my client doesn's support it. It would be better if it send the XEP-0393: Message Styling (markdown like). There is and additional problem with the spec: it doesn't shown on the discovery if the XEP is supported. So I, as a Spark developer (with a very limited time) have to chose one of the XEPs to support. For now I can add a conversion of the 394 markup to HTML on receiving (to support the Dino's behaviour) but on sending will only use the Markdown-like XEP-0393: Message Styling. But the Spark is intended for business needs where senders are usually internal and trusted so I wish to use the full possible HTML. Which leads me back to the XHTML-IM that has own flaws, but at least they are known.

Ok, thank you for the clarification. I'll get to this later, and will send a mail to the mailing list. I still think that the 394 should be discared (while it's in the experimental state) at least for a reason of not confusing developers and not fragmentize the protocol. The XMPP is mainly a __negotiation__ and I don't see that other clients supported the XEP after more than a year.