[Standards] Re: Extending the roster item element

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