8 Nov
2025
8 Nov
'25
8:59 a.m.
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
8 Nov
8 Nov
9:47 a.m.
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(a)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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
10:50 a.m.
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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
10 Nov
10 Nov
1 a.m.
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
9:19 a.m.
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.
9:54 a.m.
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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
--
Link Mauve
10:38 a.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
11 Nov
11 Nov
10:56 a.m.
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
12 Nov
12 Nov
3:57 a.m.
On Tue, Nov 11, 2025 at 6:57 PM Florian Schmaus <flo(a)geekplace.eu> wrote:
On 08/11/2025 16.59, Thilo Molitor wrote:
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
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.
11:37 a.m.
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.
13 Nov
13 Nov
8:18 a.m.
On Wed, Nov 12, 2025 at 7:38 PM Stephen Paul Weber
<singpolyma(a)singpolyma.net> wrote:
To be clear by consider I mean 'address those concerns'; not not do
the roster thing.
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.
12 Nov
12 Nov
11:58 a.m.
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
13 Nov
13 Nov
12:25 a.m.
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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
8:28 a.m.
On Wed, Nov 12, 2025 at 7:59 PM Philipp Hörist <philipp(a)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
15 Nov
15 Nov
1:44 a.m.
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(a)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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
17
days inactive
24
days old
14 comments
9 participants
participants (9)
-
Daniel Gultsch -
Dave Cridland -
Florian Schmaus -
Goffi -
Guus der Kinderen -
Link Mauve -
Philipp Hörist -
Stephen Paul Weber -
Thilo Molitor