On Mon, 10 Nov 2025 at 16:55, Link Mauve <linkmauve@linkmauve.fr> wrote:
Hi,
On Sat, Nov 08, 2025 at 04:59:56PM +0100, Thilo Molitor wrote:
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.
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.
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@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
-- Link Mauve _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org