On Mon, 10 Nov 2025 at 16:55, Link Mauve <[email protected]> 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 -- [email protected] > > To unsubscribe send an email to [email protected] > > -- > Link Mauve > _______________________________________________ > Standards mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
