So I think that as far as rosters go, this is duplicating XEP-0237 in a considerably less efficient form.
XEP-0237§4 gives a fairly intense trip down implementation options, and none of them require multiple versions of the roster as claimed by this ProtoXEP. I have a personal preference for §4.3, though it gets complex with shared groups and so on. Nevertheless, it is possible to get perfect efficiency if you're willing to store tombstones. Rosters are a particularly simple case for synchronization, because there is a single view; disco#items has potentially one view per user, and as such is more complex. In particular, assuming a room has configuration A, and then changes to configuration A' - while we can tell if A' is visible to a user U -- let's call this V(A',U) -- we cannot tell if V(A,U) == V(A',U) without having A; and given we don't always know which older configuration needs to be stored to make that comparison, things can get complex fast. As such, a '237 style approach would probably be limited in practise to having a §4.2 approach of hashing the entire list. This ProtoXEP tackles this problem by having the client upload its view for comparison, although it also includes an exact-match mechanism. However, it's not clear from the specification how a server can signal removal (or lack of visibility), nor what advantages a client has in exchanging the download of a large amount of data with the upload of a large amount of data. In short, I think I need a bit more convincing that this represents a significant advantage over the XEP-0237 approach. Dave.
