[Operators] Future of the XMPP network vs. individual operators

Moonchild moonchild at palemoon.org
Tue Dec 3 19:52:11 UTC 2013

Hash: SHA1

Sorry if I'm sidestepping here but in the end, reading all the recent
discussions about bandwidth, parsers, Google not cooperating with encryption
of traffic, etc., I'll have to let go here.

Until things are sorted at the political/XMPP-net "management" level, I'll be:
- - Running my service, with my "small time" single domain, with a CA-signed
certificate. (Side note: running 250 domains with no way to automate cert
management or using wildcard/multi-domain certs is probably not a good thing)
- - Running my service with "S2S encryption optional" until such time as there
is consensus that it won't break the entire interoperability of the XMPP
- - Keep using Google S2S unencrypted for as long as they allow talk
connections (and possibly stop running a public service if it's no longer
possible, since it'd cut 90+% of connectivity for my users - Google wins in
that case, congrats).
- - Bowing out from the manifesto of "forced encryption days". I know my
service works as it is, so feel free to test the encryption against it, but
I'll no longer participate in the "crypto-only days" as proposed. It's a
nice goal, but if it's not even clear what the goals are now or if the
jabber network is even viable long term, I'd rather take an apprehensive
approach with minimal downtime/disconnections for my users and reducing
hassle for myself.

Peter, please remove me from the manifesto for crypto-only days. Thanks.


BTW: Many high-availability protocols run on top of XML, including
high-volume authentication servers (something I've been doing administration
for at a governmental level in the past) - I'd say it's very robust, and
hardly a bandwidth problem if you calculate in TL compression, even if the
volume would be huge.
Version: GnuPG v1.4.11 (MingW32)


More information about the Operators mailing list