[guardian-dev] xmpp client strategy

Nathan of Guardian nathan at guardianproject.info
Fri Nov 13 12:20:18 EST 2015



On Fri, Nov 13, 2015, at 11:48 AM, Greg Troxel wrote: 
> I really had trouble reading the white-label blog post about xmpp
> clients.  Did I get this right?

I really need to do a follow-up on Chris post, to explain the Guardian
Project point of view on all of this. In general, everything he wrote is
true, but it is a long, detailed post, that makes many points.

>   current chatsecure codebase will be simplified (losing features) and
>   get renamed Zom, intended to be used by normals.

I wouldn't say losing features, more of a redesign of how you think
about an XMPP app should look and work. Basically, everyone still
designs apps as if you are using Pidgin or Adium, and that you know how
to get an XMPP account on a server, etc. Zom is our attempt to make an
app that looks and works as close as possible to a mainstream messaging
app, supporting insanely easy new user setup process, and still use
XMPP+Tor+OTR underneath.

We are also focusing as much on sharing media (voice messages, photos,
files) as much as we are on text, so with many on the non-western user
communities we work with, actually writing a text message on a phone is
pretty rare. Finally, we wanted to make OTR key fingerprint sharing and
verification a nearly automatic process, since that is one of the most
confusing aspects of teaching people about secure messaging today.

>   guardianproject people will get tor support into Conversations, and
>   then there will be a build of Conversations that is labeled
>   Chatsecure, but is really no different than the normal build.  This is
>   intended for use by nerds.

We realized that some users may not like the direction we are going in
with Zom, and in fact, what they may want, is something more like
Conversations. Yes, Conversations still needs Orbot/Tor support,
message/file encryption, certificate pinning, etc, and we'd rather help
them add those, then continue to complete with them. Plus they have
OMEMO which looks pretty great.

> In an xmpp phone client, what I find missing from both current
> chatsecure and Conversations is control over presence and coexisting
> with my using other clients.

Conversations is very focused on co-existing with other clients, in that
they want to support message carbons and sync between multiple devices.

> Basically, I want to be able to set my status/priority on the phone to
> some sort of "away - phone" so that people see that when that's the best
> status, they realize I'm sort of there but not necessarily, and see
> available status from other clients based on idle.

You can modify the online priority in ChatSecure, such that it is lower
than another client. This means, both may be online, but messages should
go to whichever has a higher priority. We did use to have a more
traditional status dialog switcher, but after observing how rarely it
was used, we decided to remove it from the UI. 

> Then I'd like to be able to set status to other values manually.  I
> tried Conversations' option to set status from whether the phone screen
> is on, but I really didn't like the concept.

I think we are all trying to come up with a more natural, automated way
for a mobile user status/priority to be represented, as opposed to
expecting people to toggle dialog box settings all of the time. Also the
notion of status/priority as a user facing experience basically doesn't
exist in mainstream apps. Ideas like message read indicators,
typing/attention focus indicators are more the norm, and something that
XMPP can definitely support.
 
> Finally, this reminds me that one of the issues I have with xmpp is that
> I consider presence to be very private data.  I resolve this by using
> private servers and tending to peer only with people on other private
> servers whose operators I feel ok about (which would not include big
> company cloud stuff :-).  I don't see any reasonable way out of this.
> The unreasonable way is to do all presence encrypted e2e (which would be
> good anyway, not unreasonable) and then have it sent at regular
> intervals by my server whether I'm logged in or not.

You can use XMPP in a rosterless manner, and not send presence at all.
It is not required by any means. This is a usage model we have thought
of, again since the idea of presence is not really part of what
mainstream messaging users expect.

Thanks for your patience as we sort all of this out. Along with
Conversations, you might also check out Xabber, which already supports
Orbot.

+n

-- 
  Nathan of Guardian
  nathan at guardianproject.info


More information about the guardian-dev mailing list