[guardian-dev] xmpp client strategy

[Greg Troxel]

Nathan of Guardian <nathan at guardianproject.info> writes:

> On Fri, Nov 13, 2015, at 11:48 AM, Greg Troxel wrote: 

>> 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. 

What I would like, is for new sessions to start in this order

  Adium/pidgin - present
  phone
  Adium/pidgin - away

I admit that I haven't tried hard enough.  But I had the impression that
this worked among pidgin on multiple computers.

>> 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.

That all sounds great, except that I don't see it as helpful to have
people not be able to set presence manually.  I've found that even when
in the middle of something I will look at my phone for a few seconds,
and I definitely don't want that to generate a presence event.  So I
would suggest that while making this natural is a great long term goal,
having the manul hooks (in Conversations, not Zom) helps the uber-nerdy
figure out what they want.  It may turn out that presence from phones
isn't actually useful and some sort of second-class-slightly-away is the
right answer, but I think the jury will be out for a while on that and
different people will want different things Perhaps there should be some
sort of intent system so that this is built into overall phone behavior,
integrating with quiet time and busy appointments.

>> 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.

True.  But it turns out in my usage of xmpp, presence is 95% of what I
care about.  I go entire days without saying anything, but like it that
within team/social-group/whatever I am aware of others.  (Often I will
email, make a voice call, or walk to someone's office, knowing that
someone is around.)  So while you're quite right that it's optional,
having secure presence is a great feature.

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

No worries - I think you are heading in a generally good direction and
my concerns are long term and not so much for me as in general.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20151113/c5dcfc81/attachment.sig>