10 Nov
2025
10 Nov
'25
6:38 p.m.
On Mon, 10 Nov 2025 at 16:55, Link Mauve <linkmauve(a)linkmauve.fr> wrote:
Hi,
On Sat, Nov 08, 2025 at 04:59:56PM +0100, Thilo Molitor wrote:
I think we've a little more scope with the roster, since we could have the
client signal that it understands extensions (as a general concept), in
which case it has to copy them etc - and clients that don't either don't
see them at all, or are assumed not to be changing them (or both).
FWIW, I'm pretty sure I remember a discussion about doing all of this for
RFC 6121, but we decided not to for some reason. Or forgot to.
Hi all!
With XEP-0469: Bookmark Pinning and XEP-0492: Chat notification settings
we now
have two XEPs that allow syncing pinning and
notification settings
across
clients on the same account using the
<extensions/> element of XEP-0402:
PEP
Native Bookmarks.
Unfortunately, this now means that normal 1:1 chats (that are
synchronized as
roster items) lag behind.
I'm volunteering to write a XEP adding an <extensions/> element
alongside the
<group/> element to allow arbitrary
extensions for roster items. This
would
bring 1:1 roster items on-par with bookmarks2 and
immediately allow
XEP-0492
and XEP-0469 to be applied to roster items as
well.
This has the same issue extending the original bookmarks had, that all
current clients will blissfully override the bookmark/roster item
without the extensions element on save.
This is the reason bookmarks2 had to have a namespace bump while it
still wasn’t used that much, to require every client to copy extensions
including those they don’t understand.
So even if all servers were to add support for it, it’s enough for one
client to destroy all previous extensions.
Thus I would recommend to use a different mechanism, for instance
similar to bookmarks2 you could have a PubSub node where the item id is
the JID of the remote entity, and the content is whatever you want to do
in that extension.
But before I start I want to ask especially the server developers on
this
list: would you consider implementing this?
If the answer is no or "some day far far in the future", it might be
worth to
try to invent some other mechanism that could be
deployed faster.
In my opinion, however, extending the roster items is by far the most
elegant
and simplest solution.
What do you think?
-tmolitor
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
--
Link Mauve
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org