15 Nov
2025
15 Nov
'25
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