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