I have started the changes that were discussed in https://github.com/xsf/xeps/pull/78
I took the approach of ONLY defining entity versioning in terms of the roster in the document, and indicating that one should write a new XEP for other entity versioning "profiles" which would be tracked in a registry. I plan on writing an EV profile for MUC disco#items (based on the examples from the previous version of this XEP), and possibly for service discovery requests. This update also mentions that clients may request a partial list (or updates to a partial list) from the server, and that the server may choose to send down a partial list at any time (eg. it may send down only a part of the roster that it thinks the client is most likely to use on first sync, and send down other roster items as they become necessary or on subsequent syncs at its disgression). The last part of the puzzle which remains undocumented is an "auto complete" IQ which allows the client to query for list items that match a certain simple search criteria. This way even a client with a partial view of its roster can still show all contacts that match a given input in, eg. an "auto complete" view or in some other search. This combination of roster versioning and the ability to do a partial sync of the roster (or other list) should allow this approach to scale to even the largest lists. Eg. a group with 10,000 shared users in the roster may choose to only send down the 500 that it thinks the client is most likely to contact. As the client works, performs searches, requests more roster itmes, etc. it could add to that list. In this way, the user never has to wait for the entire roster to be downloaded. The roster is simply slowly "discovered" over time. Feedback on the initial PR, and the ideas for how this will work in the future (once the "auto complete" IQ is specified) are welcome. Best, Sam
