Re: Extending the roster item element

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]