10 Dec
2025
10 Dec
'25
5:54 p.m.
Greetings.
This is a concern about backward compatibility.
Preface
-------
Earlier, this evening, after I have sent a series of corrections to
messages at the group chat of XSF Discussion, Mr. Guus has mentioned
the concern of backward compatibility with clients that do not support
message corrections, or reactions and other features that have a visual
impact.
Wed 10 Dec 2025 06:21:44 PM - Guus:
My client displays a wall of text in this chat room,
full of quote
chains, reactions, links, and corrections.
It's completely unreadable. I'm using a very old client with a basic
interface, but until recently, this was never an issue.
It's disappointing to see that modern XMPP usage can make my
experience so abysmal - at least in rooms where newer clients are
active (even if _or perhaps because_ they try to implement "backwards
compatibility" features).
Wed 10 Dec 2025 06:31:45 PM - lissine:
Check https://logs.xmpp.org/xsf/2025-12-10 to have an
idea about the
experience of Guus
Concern
-------
I was wondering whether some features, which have visual impact on
messages, should have XML Namespaces (xmlns).
Consideration
-------------
This would mean that messages that are marked as "corrected messages"
will not be displayed with clients that do not support message
correction, due to a namespace which is not recognized by clients that
do not support that feature.
Kind regards,
Schimon
6:47 p.m.
New subject: Should XEP features with apparent impact be hidden to older clients?
On Wed, 10 Dec 2025 12:04:37 -0500
Stephen Paul Weber <singpolyma(a)singpolyma.net> wrote:
Sorry. I was not aware of it. I changed the title.
So, how is it that older clients *do* display contents of elements with
xmlns that is not supported?
is there a directive in the RFC specifications of the XMPP standard
which recommends to realize only elements of supported xmlns?
I was wondering
whether some features, which have visual impact on
messages, should have XML Namespaces (xmlns).
This is already how everything works. 
7:56 p.m.
New subject: Should XEP features with apparent impact be hidden to older clients?
Somebody claiming to be Schimon Jehudah wrote:
On Wed, 10 Dec 2025 12:04:37 -0500
Stephen Paul Weber <singpolyma(a)singpolyma.net> wrote:
Sorry. I was not aware of it. I changed the title.
So, how is it that older clients *do* display contents of elements with
xmlns that is not supported?
They don't. Most XMPP apps for most features choose to intentionally add
"fall back" content, that is content in more widely-supported namespaces. In
order to avoid having apps miss some content only because it is in a format
they don't understand.
I was
wondering whether some features, which have visual impact on
messages, should have XML Namespaces (xmlns).
This is already how everything works. 
8 p.m.
New subject: Should XEP features with apparent impact be hidden to older clients?
On Wed, 10 Dec 2025 at 17:47, Schimon Jehudah <sch(a)fedora.email> wrote:
So, how is it that older clients *do* display contents
of elements with
xmlns that is not supported?
is there a directive in the RFC specifications of the XMPP standard
which recommends to realize only elements of supported xmlns?
The spec relating to this is this one:
https://xmpp.org/extensions/xep-0428.html
The idea of this is that clients send wall-of-text rendered bodies, and
naive clients display those, but clients which understand particular
extensions then process the rewriting rules within fallback to render a
different (cleaner) message.
But this comes down to a complex product choice - if you're faced with a
reaction, for example, what should a client show? A single emoji as a
message? Unfortunately it's the choice of the sender, rather than the
receiver, what the fallback body ends up being - and worse, non-naive
clients then edit the fallback body according to whatever the
sender dictates.
This was not my idea for this spec at all, but it's where consensus got us.
Dave.
8:02 p.m.
New subject: Should XEP features with apparent impact be hidden to older clients?
This was not my idea for this spec at all, but it's
where consensus got us.
To be fair we were doing this for many years before this spec. But this spec
makes it much, much nicer and I'm very grateful for it.
I'm curious to hear more about how your vision differed from current use.
2
days inactive
2
days old
5 comments
3 participants
participants (3)
-
Dave Cridland -
Schimon Jehudah -
Stephen Paul Weber