[Standards] Easy XMPP

Dave Cridland dave at cridland.net
Mon Jan 16 17:32:09 UTC 2017


On 16 January 2017 at 16:28, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> On 1/16/17 7:00 AM, Evgeny Khramtsov wrote:
>>
>> Mon, 16 Jan 2017 14:29:42 +0100
>> Georg Lukas <georg at op-co.de> wrote:
>>
>>> The goal of Easy* was to write down the things that can easily be
>>> done today. However, few client developers are sufficiently
>>> motivated, aware of Easy* or competent in the UX domain. Just to pick
>>> a random example: Gajim, the most actively developed (or user
>>> visible) desktop client, is a nightmare to configure for a user who's
>>> new to XMPP.
>>
>>
>> Easy configuration is not the only problem. All XMPP clients has really
>> terrible UI. What I'm wondering is: don't client developers see their
>> UI sucks? They never saw popular clients' UI (Viber, Skype, etc) or
>> what? OK, I can understand that the majority of clients are targetted
>> on advanced users, but in that case no easy onboarding is required and
>> XMPP will never be a popular protocol. So all Easy_* initiatives are
>> pointless at this point.
>
>
> Recently I tried Signal because it was mentioned in another thread on this
> list. Although I'm sure folks could quibble with various aspects of Signal,
> it was very easy to get started and it's very secure. It's also built by
> maybe 6 people working at a non-profit organization in San Francisco - a lot
> fewer people than are active on this list!
>
> If someone like Sam's friend told me they wanted to find a secure messaging
> service, I'd tell them to just use Signal.
>
> So, at this point, I wonder what we're doing here. :-)
>
> I fully understand that XMPP can be useful for organizations who want to
> develop or deploy their own messaging systems, either on-premises or
> integrated with an existing system like an e-learning platform - there are
> server packages you can download, libraries you can develop on, companies
> you can contract with for support or consulting, and overall it's pretty
> secure.
>
> However, why run a public XMPP service? Why try to convince normal end users
> to switch to XMPP? Are companies still offering dedicated email services?
> Even ISPs got out of that business years ago.
>
> As the administrator of jabber.org, I've been thinking for the last few
> years that it might be useful for jabber.org to offer a large, secure,
> privacy-respecting, easy-to-use messaging service with dedicated clients
> ("just download the Jabber app!") and always-on end-to-end encryption. The
> stumbling block for me has been that I'd need to create a small non-profit
> orgnanization and find people to staff it, but I'm always too busy with my
> $dayjob to get this going. (I'd also need to brand it as JABBER™ and make
> hard choices about which XMPP software to use and which not to use, and
> probaby stop being executive director of the XSF to prevent a conflict of
> interest.) But Signal has beaten me to the punch, and as far as I can see
> they've done a great job of it. So hats off to them!
>
> Thus I repeat the question: what are we doing here?

There's a number of implications to this.

One could, indeed, build a "closed" service around an XMPP service and
use a bundled client restricted to that service. I'm sure it'd work
just fine. You could set your own security policy over it, because
it's your domain to do this with.

What XMPP gives is the ability for someone else to do the same - and
still talk to their friends on yours. This is a powerful thing, and I
think we really underestimate how important it is, because it's part
of XMPP that works sufficiently well as to be almost transparent to
the user. Even when different security domains can remain entirely
autonomous in policy.

And don't kid yourself that Signal is some kind of a charity - they're
doing multimillion dollar deals and setting lawyers on people, after
all. Bear in mind they won't allow others to use their encryption
protocol as-is without enforcing the GPL on the implementation, for
example. And as a single service, that's a single place for a foreign
power to require complete metadata collection.

The XSF has a huge disadvantage by remaining entirely
implementation-neutral (to a fault, as I've pointed out before) - and
we should be, perhaps, a little more discerning about what we list on
the website, for example. And federation's very existence - as well as
being a genuinely useful feature - makes a lot of things harder (like,
for example, onboarding or friend-discovery).

But just because something is hard, does not mean it isn't worth doing.

So what am I here for? To work on the hard problems, because I believe
they're worth solving.

Dave.


More information about the Standards mailing list