Hi all, I appreciate that the subject line is a bit, well, pretentious. Sorry. In a meeting the other day, a requirement popped up to avoid the existing full-mesh routing in XMPP. I didn't comment, or explore it. Existing cases (Openfire's "trunking", Metre, Isode M-Link Edge/Gateway) have done this by explicit configuration, some gnarly DNS spoofing, and odd-ball TLS overrides. I'm wondering if it's worth exploring a standards-based solution here, where we'd have something like a routing protocol (like a BGPish or OSPFish thing for XMPP)? This would mean that when a.example talks to b.example, it might be told that b.example can forward traffic to c.example (and possibly how), and a.example could decide by some metrics, configuration, and trust that it would then send traffic to c.example via b.example. Or, not. I imagine the security implications will require quite a bit of thought, to say the least... Is there any interest in discussing this further? Dave.