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 <[email protected]> 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 -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
