Should new features utilize different namespaces?
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
On Wed, 10 Dec 2025 12:04:37 -0500 Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
I was wondering whether some features, which have visual impact on messages, should have XML Namespaces (xmlns).
This is already how everything works.
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?
Somebody claiming to be Schimon Jehudah wrote:
On Wed, 10 Dec 2025 12:04:37 -0500 Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
I was wondering whether some features, which have visual impact on messages, should have XML Namespaces (xmlns).
This is already how everything works.
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.
On Wed, 10 Dec 2025 at 17:47, Schimon Jehudah <sch@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.
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.
participants (3)
-
Dave Cridland -
Schimon Jehudah -
Stephen Paul Weber