Since use of XEP-0033 for more efficient S2S has reared its ugly head once more, I thought I'd try tackling this problem from a different direction.
We've rejected a number of designs (around 6 or 7) over the years aimed at solving this general problem - sending multiple stanzas to a set of jids on the same remote domain. The rejections (at least of those that worked) fell into three categories: 1) Bandwidth Inefficient: The design didn't benefit post-compression. Generally speaking, a design which you can transform from the unextended format into the new format and vice-versa by some simple programmatic means (XSLT, for example) without domain knowledge is not going to benefit post-compression. 2) Security/Privacy: Specifically, those cases where the distribution lists were owned by a third party server (ie, the destination server, typically). This has two problems, the first is of trust, and the second is of sharing what might be sensitive information. There's another problem with these designs which is in synchronization, though that's not a security issue per-se. 3) Round-trip inefficient: Either the design requires an additional round-trip for each change (and initial setup), or requires an additional S2S session to be raised - generally both. The converse of these - bandwidth efficient, secure/private, RTT efficient - would form our requirements. I'd note a couple of changes to the server landscape might affect our thoughts here. a) As annoying as it is to me, compression seems related to a number of security attacks which are poorly understood in the XMPP community - TLS compression seems to be generally turned off these days, and XEP-0138 may or may not be sufficient to mount various attacks. In addition, scalability of servers has reached the point where a major scalability issue is in compression memory usage. So there's a strong argument that mere representational tricks might actually be more useful than they were. b) Security within the XMPP network has improved dramatically over the past few years in terms of authentication and encryption. In addition, there are several cases where XMPP is used within closed networks with a general trust of peers much higher than is typical on the Internet. I suspect that between trusted peers we can do something useful. c) Metadata tracking by traffic analysis seems to be a valid threat; a suitable design would homogenise traffic to a degree, which might reduce the data one can glean from an encrypted session. Anyone want to shoot down any of these subjective statements presented as fact? Dave.
