Modern XMPP project discussion - 2026-04-24

I rather think that 393 should be discarded in favor of 394. If you want to support markdown style input for endusers, you can do that and translate it to 394 before sending. The issue with 393 is that certain markup can't be expressed (same for Markdown) and users accidentally markup things they didn't intend (e.g. when doing math formulars). I would consider XHTML-IM superior to 393 for almost all purposes, but we do know that it has security impact when people just drop the HTML in a full HTML engine. 393 is also intentionally incompatible with Markdown, because Markdown to HTML converters have the same issue.

Discovery is not helpful, because our discovery only works for online clients, meaning that any offline clients are not considered, even if those are the primary clients. Especially with push notifications on mobile devices, where you can be offline in XMPP sense, but still be able to receive messages, discovery becomes almost useless. Also, you can't really know what to do if there are multiple clients with different features

Even when senders are trusted, using HTML has some downsides (depending on the implementation). Notably if you don't take enough care, bugs (or intentional harmful HTML) can lead to one message affecting the rendering of other messages (I remember seeing this in Pidgin long ago), even if you protect against any kind of scripting attacks. The only way to safely use full HTML (with scripting and networking disabled) is to have an independent HTML rendering per message, which is very unflexible and also ressource inefficient.

> but we do know that it has security impact when people just drop the HTML in a full HTML engine. I think you can mitigate this by sanitizing on the server and providing recommendations to client developers. This isn't a threat unique to XMPP. That said markdown would probably be a okay option for the vast majority of rich text use cases. It has the added bonus of being readable (tables less so) with zero client support.

Markdown is pretty ubiquitous these days, it's in ticketing systems, wikis, code repos, documentation, etc.

Someone already did the mistake of feeding 393 bodies trough a markdown library that allowed html passtrough, I would not want to encourage more of that.

I don't think one person doing something dumb is good justification. Markdown is used all over the place safely.

You making a good point, I never thought from this side. I see that the security was probably the main concideration. From a practical point of view the Markdown\MessageStyleing\HMTL will be always simpler for senders than a separate markup. Imagine you have a an IoT bot that generates a text (like return a list of light lamps on a room): you need to generate a <li> list in on function and then you'll need to de-HTMLize it before sending to collect the <markup>. Another scenario: I don't want to use a visual editor but I'll use a Markdown when typing a message. Now my client has to convert my MD to the <markup>.

This potentially *may* work if eventually will be implemented in all libraries and clients. That's a question of effort and time. Given that the <markup> is implemented now only in one library and one client I'm afraid that may simply never happen

XEP-0393 is too barebones, you at least need lists and headings and ideally tables. XEP-0394 is missing alot of stuff too - like no bold? -You use * for a list but not back ticks for code/monospace? It also looks like a pain in the ass to implement (but that's how message references work so maybe that's not a issue in reality)

I would just provide a hint the message contains markdown, maybe what flavour it is and let clients figure out how to render that.

https://xmpp.org/extensions/xep-0481.html

For me the biggest problem is that I can't just use any tags in the `<markup` because they simply not described there in a spec and other client may simply not show them, and that's an intentional behavior. Also the mapping is not by the HTML tags i.e. `<em>` become `<emphasis/>`.

> https://xmpp.org/extensions/xep-0481.html https://xmpp.org/extensions/#xep-0481-implementations ↺

zero implementations, I don't know how such specs are applied if there is no any implementation

> https://xmpp.org/extensions/xep-0481.html I like that. Not a huge fan of having alternate content types sent in a message but it's what 0071 does. You also have the option to just have it be a hiint. ↺

what a content-type is possible in a body except of the MD and HTML?

They have a example of xml

and who is probably going to use it? I just can't imagine

So, someone already wrote that XEP. I do not think it is a good idea in any way.

I only think of some audio/video records. Now they are sent as an HTTP link that has own content type. Inlining the raw audio in a message... not sure

> and who is probably going to use it? I just can't imagine I don't understand the usecase of XML - maybe to define a non standard markup. The rest of the XEP is fine to me, you send markdown if a client can render it it does, if you can't it's readable. ↺

0393 looks like it won though.

As I see it, if some client needs to use own special markup (XML, maybe AsciDoc) then they know that other clients are probably wont read it. If this is for internal communication in a company then they don't really need for the XEP because they can use whatever they want

The MD by itself was designed to be readable in raw. There are MD libraries for all languages, for decades. And everybody knows the MD. AI tools generates the MD in responses. Slack, Flock and other corporate messengers support it. Online translators understands it. Yes, it has a problem that a user can mess, as larma perfectly explained. The most funny is that people who use the MD just hate WYSIWYG editors for exactly same reason: it often resulted in some mess. I think the only what we can do is to show a Preview tab in editor and add a button (Disable styling) to add the <unstyled> tag

There is a need to send formatted messages - slack, discord, teams, etc all let you send structured text. It's useful for sending announcements, issue tracker tickets, weather alerts, git commits, etc.

I going to add the full markdown by default into the Spark client. It's really needed there. Fear or the MD is probably bigger than it is. So the whole XEP-0393 should be replaced with a text "hey, just use MD. Whatever flavor you want (gitHub, GitLab), they all are compatible on a basic level, just let a user to know. But don't expect that it may work anywhere, we have nothing to do here. P.S. the MD supports all basic HTML <b> <em> <h1> and even <table> ".

I don't think commonmark supports table.

What I like about 0481 is the content type hint. https://xmpp.org/extensions/xep-0481.html#example-1 that's where you could say "this is markdown and GFM"

since the MD supports basic HTML then we have a clear migration path from the XHTML-IM: just take put it into a body and that's it. All the sanitization will be made by the MD parser itself. If someone has big html files (rss bots) then they can convert html to the MD, such converters exist

XHTML is still used in new XEP's https://xmpp.org/extensions/xep-0472.html#rich_content ✏

Granted thats 'experimental'

Well, it looks like there wasn't other options at the moment.

Why would you migrate away from XHTML-IM? It's awesome. I wish it was extended to support `<audio>` and `<video>`