[Standards] Proposed XMPP Extension: Compatibility Fallbacks
xmpp at larma.de
Mon Jan 10 01:23:29 UTC 2022
On 09.01.22 21:50, Dave Cridland wrote:
> I'd still argue that it's a bad idea these days, even if Matrix haven't
> learned from the trouble it's caused in email. Most other proprietary
> messaging apps just have one form, the only reason email (and us, and
> Matrix) went for alternatives is because of an existing deployed base
> that only understood plaintext. This causes not only the problem of
> messages having potentially wildly different meanings between the
> alternatives, but also you can never get rid of the compatibility layer.
I do not agree here at all. The "compatibility layer" is not only for
older clients that don't implement the latest version of the protocol.
It is also to make client development easier (so that clients don't have
to support a large set of features to do basic things) and for
situations where rich text is just technically not feasible.
I just also took a look at two popular proprietary apps:
Slack messages have two alternatives: one is plain text or markdown, the
other one is using "blocks" [https://api.slack.com/block-kit/building].
Every message must have the plain/markdown version, blocks are optional,
but if present should be preferred for rendering. Notifications on
mobile (which are transported through the heavily restricted OS native
push messaging systems) always use the plain/markdown variant.
Microsoft Teams messages can be plaintext or HTML. Both have a plain
text "summary" which is the same as the body for plain text messages and
is meant for push notifications and as a fallback for when HTML
rendering is not possible.
To me it rather looks like whenever a complex markup system is available
(HTML, "Blocks") a simple version (plain text, markdown) is provided as
Of course a lot of messengers just only support plain text or markdown
and are fine with it, especially as inputting any formatting on mobile
More information about the Standards