[Standards] [Members] 33C3 talk on Signal and current XMPP issue in providing a similar UX
tmarkmann at googlemail.com
Fri Dec 30 13:22:11 UTC 2016
On Fri, Dec 30, 2016 at 1:04 AM, Peter Saint-Andre <stpeter at stpeter.im>
> I'm curious how the Signal folks use phone numbers as identifiers yet
> still ensure some aspects of privacy.
Although that approach doesn't work directly in a distributed/federated
setting, it could probably combined with private information retrieval
https://en.wikipedia.org/wiki/Private_information_retrieval or something
> We need to aggressively address the spam problem.
Indeed. Proposed solutions I've heard about so far are mostly requiring
captcha on first contact or reputation systems. I think end-to-end captchas
could result in a very bad UX and a reputation system where admins would
have an incentive to keep spamming users from their servers or else it
would effect other users on their server (e.g. by rate limiting s2s
connections or stanzas per JID, or similar).
Although captchas are definitely the go to way to at least prevent too much
automatic account generation.
> Federation is hard. Although it's by no means easy to run a large
> messaging service, you have more control over account creation,
> misbehavior, user experience, and security.
> One approach for us would be to have easily skinnable clients, so that
> each service could offer their own branded version.
The only secure way this would work is if general XMPP clients would
download skins from the server on login. You can't have all of them provide
their custom versions of clients. It'd be one more thing they'd have to
maintain, have to keep up to date for bug fixes, provide auto updates, ship
them to the app stores, etc. I don't think that will scale well.
Another approach could maybe be a URL scheme for clients to fill in custom
login configuration (probably except for passwords, or maybe only a OTP and
the password has to be set by the user in the client on first login). The
UX then would be like install client from store or website, click a link on
website, and the rest would continue in the client.
Although an approach where users wouldn't have to leave the client would be
nicer from an UX perspective.
> I think ideally clients should provide clear defaults like what
>> conversations does, and of course options, but hidden from the view of
>> normal users who don’t understand this kind of things. This is sad (as
>> it might lead to “megaservers” for popular clients), but that really
>> needs to be straightened out.
> It seems to me that megaservers are hard to avoid. I've thought about this
> a lot, and my feeling is most users flock to services with easily
> remembered names. This ties in with centralization and even with the
> economic basis for offering services in the first place (the venture
> capitalists who fund you want to make sure you have a big userbase so they
> can offer ads, sell user data, or otherwise "monetize"). The original
> "Jabber" brand was very catchy, and as the proprietor of jabber.org I
> can't tell you how many password change requests I receive for users at
> other "Jabber" services (even ones inside companies and government/military
> I could envision a "pick your username" dialog giving new users a
>> random server among a list of curated services.
> Matthew Wild was working on something like a few years ago.
Yeah, the ideal UX for completely new users would be 1. download client, 2.
open client, 3. enter username, 4. approve to service agreement of a chosen
server 5. register and done.
The crucial part here is step 4 with issues like:
a) Selecting the right server. Ideally it would be one close to the user.
Not only in a network sense but also from a geographical/political sense.
Users are probably most familiar with local law and local regulations and
would expect local data protection from their service.
b) We as a community need to prevent service agreement bloat similar to
EULAs or standard software licenses or else they won't be read.
c) Clients should suggest servers based on their support for essential
features, high availability, spam reputation, etc. This should provide an
incentive for admins to run modern servers or else they won't have new
users directed to them, and most admins probably run their public open
servers so users will register there.
In the end this is also something where we as a community have been missing
a central place and hosting capabilities. In the past, the Jabber Software
Foundation was a lot about the software developed around the Jabber
protocol. With the change to the XMPP Standards Foundation, this changed to
a highly standards focused community. The essential thing missing here I
think is an online presence for the community of XMPP client developers and
service providers. A place where we can collect and provide central
information and services to all service providers and client developers. A
place for central service information, client recommendation, etc.
I'm not completely sure this should all happen under the term XMPP
Standards Foundation. Currently we blindly list clients and users are just
one cent smarter than before which client to choose. XMPP.net has a list of
services, the server software they run and their security properties.
However, end users probably care less so about the software used and more
so about support for modern features.
Though, I definitely think we as a community should definitely work towards
providing these kind of services. If it's part of the XSF it would probably
require some change of the bylaws but maybe there is a majority of members
that would like to see us going in this direction.
Let me know what you think about this.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards