[Standards] [Members] 33C3 talk on Signal and current XMPP issue in providing a similar UX
stpeter at stpeter.im
Fri Dec 30 00:04:43 UTC 2016
On 12/29/16 4:07 PM, Mathieu Pasquet wrote:
> It was indeed a nice talk.
> On Thu, Dec 29, 2016 at 04:48:19PM -0600, Sam Whited wrote:
>> A few scattered thoughts after a first reading of this thread:
>>> * Current SPAM/SPIM issue needs to be addressed in some way.
>> The slides (with no other context, I wasn't at the talk) say that
>> "Centralized and proprietary services have considerable advantages
>> when it comes to abuse management." I'm not sure this is true. I very
>> *very* rarely have spam get through my email filters (which is not
>> proprietary or centralized), and don't see why individual services
>> that use XMPP (server operators) couldn't also implement the exact
>> same spam filters on their XMPP servers. We may not have the big data
>> of gmail, but even simple filters do wonders for Spam (the filter in
>> Thunderbird is pretty good in my experience).
>> That being said, it does need to be "addressed" in the sense that
>> someone has to actually do that and maybe tie it in with
>> https://xmpp.org/extensions/xep-0377.html (which no client implements
>> as far as I know; it all ties back to incentivizing clients to
>> implement modern features, so I think that's the more important issue;
>> I'm not entirely sure how the SPAM slides tied in with the rest of the
>> presentation… does Signal do anything about this, or is it just not
>> popular enough to be a target for spammers?).
> This was also covered; one of the crucial antispam mechanisms of Signal
> is the use of phone numbers as identifiers, and even using the "desktop"
> client requires to approve using the mobile client first.
I'm curious how the Signal folks use phone numbers as identifiers yet
still ensure some aspects of privacy.
> I personally see more email spam than XMPP spam nowadays, but as a
> server administrator it’s the opposite, having to watch for automated
> registration patterns. A reporting and reputation system would go a long
> way towards reducing the amount, and maybe a multi-tiered system would
> work (I would hate to prevent people from creating and connecting to
> account from Tor exit nodes, but at the same time we have a lot of bogus
> registrations and spam and DDoS using it).
We need to aggressively address the spam problem.
>>> * XMPP on-boarding. New users finding the right XMPP service for them, one
>>> that matches their law requirements and privacy expectations. After
>>> registration, they need to easily/secure/privacy-enforcing fill up their
>>> roster with contacts based on known contact information like phone number or
>>> e-mail address.
>> In my mind this is probably the single biggest issue with most public
>> services based on XMPP these days; we need to provide a clear path
>> forward, although I must confess that I'm at a loss as to how that
>> could be done.
> One of the points was that the dichotomy between applications and
> accounts is only an issue in the federated world, as most "apps" are the
> only way of accessing the silo, and even gmail which offers external
> POP/IMAP/SMTP connectivity is still primarily used through the web
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.
> 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
> 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.
More information about the Standards