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. 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
Hi Thilo, I haven’t looked into this from a protocol perspective yet, but from a server developer’s point of view: even if we implemented this tomorrow and released it in a few months (which is pretty fast in server time), keep in mind that many server admins update… let’s say… at their own pace. That means new features often reach only a subset of users at first. This is not as dramatic as it may sound, as it happens for all new server features. Usually, it is fine: early adopters naturally gravitate toward servers that keep up to date anyway. But if your solution requires broad deployment to really be useful (which might be implied by the fact that you're explicitly asking for server developer perspectives) it might be worth considering alternative approaches. Kind regards, Guus On Sat, Nov 8, 2025 at 5:00 PM Thilo Molitor <thilo@eightysoft.de> 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.
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
Hi, Both XEPs are only implemented by one client, so before we go on maybe we should ask if these XEPs actually solve a problem in a good way. My opinion on this would be a definitive, no. Putting a pin element into bookmarks never made much sense, this was pointed out when the XEP was published, and when i recall the conversation back then, the author was sadly not aware that bookmarks are only for group chats. The chat notification XEP is kind of fine, it just misses a place where we can use it. It feels like it should be part of a bigger spec that defines where to store these kind of settings. I would first start with gathering requirements what we would expect from a chat settings/pinning XEP. The most important for me would be, I want to set settings for all entities, this means every JID, independent if they are in my roster or not, or if they identify as group chat or whatever else. And i want to get them form a single location, not merge multiple sources into one. Pubsub would be the logical place for me to implement something like that. Regards Philipp On Sat, Nov 8, 2025, at 16:59, 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.
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
Hi, Please note that in the context of my incoming work on reducing metadata exposure in XMPP (https://nlnet.nl/project/ServerlessXMPP/) I'm planning to work on roster and pubsub, the main goal being to enable the use of e2ee with roster data, while also adding extra information without breaking backward compatibility. It could be something that fits your use case. Best, Goffi Le samedi 8 novembre 2025, 18:50:28 heure normale d’Europe centrale Philipp Hörist a écrit :
Hi,
Both XEPs are only implemented by one client, so before we go on maybe we should ask if these XEPs actually solve a problem in a good way.
My opinion on this would be a definitive, no.
Putting a pin element into bookmarks never made much sense, this was pointed out when the XEP was published, and when i recall the conversation back then, the author was sadly not aware that bookmarks are only for group chats.
The chat notification XEP is kind of fine, it just misses a place where we can use it. It feels like it should be part of a bigger spec that defines where to store these kind of settings.
I would first start with gathering requirements what we would expect from a chat settings/pinning XEP.
The most important for me would be, I want to set settings for all entities, this means every JID, independent if they are in my roster or not, or if they identify as group chat or whatever else. And i want to get them form a single location, not merge multiple sources into one.
Pubsub would be the logical place for me to implement something like that.
Regards Philipp
On Sat, Nov 8, 2025, at 16:59, 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.
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
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.
While I have always been team "1:1 items in bookmarks2 is fine" this seems like a very clean solution here. I don't know that we need an <extensions/> element per se but a XEP to specify that custom children of roster items should be preserved would solve the "yet another roster in pep" issue we seem to keep having.
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.
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
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
On 08/11/2025 16.59, Thilo Molitor wrote:
I'm volunteering to write a XEP adding an <extensions/> element alongside the <group/> element to allow arbitrary extensions for roster items. Extending roster items is tempting and seems like an ideal fit at first, but there is a reason this isn't usually done (probably besides some internal deployments):
It's fragile, inefficient, and there are better alternatives. There is a good summary of the problems that come up in the "Bookmarks 2 extensibility" thread from Nov 2019. I'll try to come up with a link (assuming this is still accessible somehow). Basically, things you have to keep in mind include: you have to avoid clients overriding unknown extensions when re-submitting things. You may end-up with having to resubmit extensions even though you did not modify them (which is ineffective). You may want to distinguish between extensions that have been synthesized by the server. A dedicated PubSub node is in every case the better approach. - Florian
On Tue, Nov 11, 2025 at 6:57 PM Florian Schmaus <flo@geekplace.eu> wrote:
On 08/11/2025 16.59, Thilo Molitor wrote:
I'm volunteering to write a XEP adding an <extensions/> element alongside the <group/> element to allow arbitrary extensions for roster items. Extending roster items is tempting and seems like an ideal fit at first, but there is a reason this isn't usually done (probably besides some internal deployments):
It's fragile, inefficient, and there are better alternatives.
There is a good summary of the problems that come up in the "Bookmarks 2 extensibility" thread from Nov 2019. I'll try to come up with a link (assuming this is still accessible somehow).
Basically, things you have to keep in mind include: you have to avoid clients overriding unknown extensions when re-submitting things. You may end-up with having to resubmit extensions even though you did not modify them (which is ineffective). You may want to distinguish between extensions that have been synthesized by the server.
I think Philipp somewhere else in the thread brought up a valid concern with regards to wanting to store information for people not in the roster; However the unsupporting clients overwriting extensions is something we can easily fix. The server needs explicit support for it anyway. So on roster push a lack of an <extensions/> wrapper element would mean the client either doesn’t support them or doesn’t want to modify them. (An empty <extensions/> would indicate delete.) This solves both non-supporting clients and avoids the traffic issue that Florian brought up. (However in most deployments you are not constantly editing individual roster items anyway. That’s only on add, delete and occasional name changes). There are potentially some overlapping problems with Bookmarks 2 but accidental overwrite is not one of them. All in all I’m more or less in favor of this although we should consider what Philipp wrote wrt annotations for conversations not in your roster. WRT extensions synthesized by the server. We can just address this if we feel we need that feature. cheers Daniel
All in all I’m more or less in favor of this although we should consider what Philipp wrote wrt annotations for conversations not in your roster.
Add them to roster? There doesn't need to be any subscription or anything to be in roster, so I don't see how adding it there is any different than adding to Yet Another Bookmark Node would be.
On Wed, Nov 12, 2025 at 7:38 PM Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
All in all I’m more or less in favor of this although we should consider what Philipp wrote wrt annotations for conversations not in your roster.
Add them to roster? There doesn't need to be any subscription or anything to be in roster, so I don't see how adding it there is any different than adding to Yet Another Bookmark Node would be.
To be clear by consider I mean 'address those concerns'; not not do the roster thing.
Hi, I think we need a list of JIDs where we can store data per JID. What i would expect for this list is - It can contain any JID - Notifications on changes of single items - Version support, i want to be able to only request the latest changes since version XX Option 1: Extending the Roster and put also group chats in it - Seems to have everything we need - Historically clients expect no group chats in the roster, even though not strictly disallowed by the RFC. (At least i did not find anything). If backwards compat is a goal, this is probably not a good option - Takes probably years to role out because of explicit server support needed - Clients would need to implement fallbacks for missing server support for years or forever depending if all servers adapt this or not -> This brings us to a chicken-egg problem, as clients have an incentive not implement before broad server support Option 2: Splitting the data between Roster and Bookmarks - Complexity pushed to clients to merge different stores with different capabilities - Pubsub versioning would be nice (XEP-0312), how good is this supported? Its not strictly a requirement just an optimization - Use cases like very natural follow ups like, define a order between pinned chats probably complex to implement if data split across multiple stores - Takes probably years to role out because of explicit server support needed - Clients would need to implement fallbacks for missing server support for years or forever depending if all servers adapt this or not -> This brings us to a chicken-egg problem, as clients have an incentive not implement before broad server support Option 3: Using only Pubsub - No server support needed, clients could immediately role out support - Pubsub versioning would be nice (XEP-0312), how good is this supported? Its not strictly a requirement just an optimization Regards Philipp
Hi, XEP-0312 is not needed at all, we have MAM and we get notifications for any change in a pubsub node (if we are subscribed of course). I actually think that XEP-0312 should be obsoleted. I'm known for being a pubsub advocate, but pubsub brings out of the boxes end- to-end encryption, and indeed we can roll-it out immediately. However, I'm not strictly opposed to the roster with extension options either, but we need to have end-to-end encryption for metadata not directly needed by the server (i.e.; everything but JID and presence subscription). And I'm afraid too that this can take years. Best, Goffi Le mercredi 12 novembre 2025, 19:58:00 heure normale d’Europe centrale Philipp Hörist a écrit :
Hi,
I think we need a list of JIDs where we can store data per JID.
What i would expect for this list is
- It can contain any JID - Notifications on changes of single items - Version support, i want to be able to only request the latest changes since version XX
Option 1: Extending the Roster and put also group chats in it
- Seems to have everything we need - Historically clients expect no group chats in the roster, even though not strictly disallowed by the RFC. (At least i did not find anything). If backwards compat is a goal, this is probably not a good option - Takes probably years to role out because of explicit server support needed - Clients would need to implement fallbacks for missing server support for years or forever depending if all servers adapt this or not -> This brings us to a chicken-egg problem, as clients have an incentive not implement before broad server support
Option 2: Splitting the data between Roster and Bookmarks
- Complexity pushed to clients to merge different stores with different capabilities - Pubsub versioning would be nice (XEP-0312), how good is this supported? Its not strictly a requirement just an optimization - Use cases like very natural follow ups like, define a order between pinned chats probably complex to implement if data split across multiple stores - Takes probably years to role out because of explicit server support needed - Clients would need to implement fallbacks for missing server support for years or forever depending if all servers adapt this or not -> This brings us to a chicken-egg problem, as clients have an incentive not implement before broad server support
Option 3: Using only Pubsub
- No server support needed, clients could immediately role out support - Pubsub versioning would be nice (XEP-0312), how good is this supported? Its not strictly a requirement just an optimization
Regards Philipp
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
On Wed, Nov 12, 2025 at 7:59 PM Philipp Hörist <philipp@hoerist.com> wrote:
Option 2: Splitting the data between Roster and Bookmarks
- Complexity pushed to clients to merge different stores with different capabilities
The extensions themselves would be all marked as in "works for both extensions. And the capability itself (does my server have roster extension support) is relatively boolean.
- Pubsub versioning would be nice (XEP-0312), how good is this supported? Its not strictly a requirement just an optimization
We at some point need some optimization for PEP. Both Bookmarks and MDS and possibly other needs this. However I would consider that as an orthogonal problem for now.
- Use cases like very natural follow ups like, define a order between pinned chats probably complex to implement if data split across multiple stores
Both rosters and bookmarks are collections of things that do not have an inherent order to them. So a pinning mechanism that comes with a priority / order to them would likely do it as a floating point priority attribute or something like that anyway. So on the UI side of things I imagine this to be fairly simple. Merge those two lists and then order by that attribute. (which would occur in both)
- Takes probably years to role out because of explicit server support needed
In my personal experience server support these days doesn’t take years anymore - if we get buy in from the server devs. SASL2, channel binding, bind 2 all happened relatively quickly. (May one year; not multiple) I guess that’s why it would be nice to hear from server devs specifically for this feature. *IF* they are willing to implement it (and if they consider that _somewhat_ easy) I imagine that this could happen fairly quickly.
- Clients would need to implement fallbacks for missing server support for years or forever depending if all servers adapt this or not -> This brings us to a chicken-egg problem, as clients have an incentive not implement before broad server support
Some clients (Conversations for example) already have pinning and notification settings locally. So the work around is already in place. Depending on server support it's just a question of "do we push this information to the server". And then the answer - for a little while - could be: we push it for group chats - but we don’t push it for 1:1 chats. Which is very slightly confusing but we are already coming from a place were neither is pushed to the server. cheers Daniel
Hi, So you think we can use Option 2 but - It needs more developer resources, and you hope they will be available - Merging, conflict resolution between 2 different stores will hopefully be handled in the spec in a good way Whats your opinion on the other options? Regards Philipp On Thu, Nov 13, 2025, at 16:28, Daniel Gultsch wrote:
On Wed, Nov 12, 2025 at 7:59 PM Philipp Hörist <philipp@hoerist.com> wrote:
Option 2: Splitting the data between Roster and Bookmarks
- Complexity pushed to clients to merge different stores with different capabilities
The extensions themselves would be all marked as in "works for both extensions.
And the capability itself (does my server have roster extension support) is relatively boolean.
- Pubsub versioning would be nice (XEP-0312), how good is this supported? Its not strictly a requirement just an optimization
We at some point need some optimization for PEP. Both Bookmarks and MDS and possibly other needs this. However I would consider that as an orthogonal problem for now.
- Use cases like very natural follow ups like, define a order between pinned chats probably complex to implement if data split across multiple stores
Both rosters and bookmarks are collections of things that do not have an inherent order to them. So a pinning mechanism that comes with a priority / order to them would likely do it as a floating point priority attribute or something like that anyway. So on the UI side of things I imagine this to be fairly simple. Merge those two lists and then order by that attribute. (which would occur in both)
- Takes probably years to role out because of explicit server support needed
In my personal experience server support these days doesn’t take years anymore - if we get buy in from the server devs.
SASL2, channel binding, bind 2 all happened relatively quickly. (May one year; not multiple)
I guess that’s why it would be nice to hear from server devs specifically for this feature. *IF* they are willing to implement it (and if they consider that _somewhat_ easy) I imagine that this could happen fairly quickly.
- Clients would need to implement fallbacks for missing server support for years or forever depending if all servers adapt this or not -> This brings us to a chicken-egg problem, as clients have an incentive not implement before broad server support
Some clients (Conversations for example) already have pinning and notification settings locally. So the work around is already in place. Depending on server support it's just a question of "do we push this information to the server". And then the answer - for a little while - could be: we push it for group chats - but we don’t push it for 1:1 chats. Which is very slightly confusing but we are already coming from a place were neither is pushed to the server.
cheers Daniel _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
participants (9)
-
Daniel Gultsch -
Dave Cridland -
Florian Schmaus -
Goffi -
Guus der Kinderen -
Link Mauve -
Philipp Hörist -
Stephen Paul Weber -
Thilo Molitor