
Easy XMPP: What are we doing here? - psiconaut
https://mail.jabber.org/pipermail/standards/2017-January/031903.html
======
hackuser
These would be my concerns about potential differences between Signal and an
'Easy XMPP' client; would someone who knows Signal say whether these are
accurate?:

* Signal users are not anonymous; Signal requires users' phone numbers.

* Signal is centralized. Is there a way to run your own Signal server?

* Signal uses Google Chrome on the desktop (and Android?) and Google Play Services (or some part of them) on Android (I don't know about iOS). Whatever you think of Google's intentions, they are one of the leading surveillance organizations in the world. Signal users must trust Google.

* Is Signal's system (not user data) fully open and transparent, end-to-end?

* Would I need to trust Signal more than I would need to trust Jabber?

\----

EDIT: I came across this comment from Moxie in late 2015 which addresses some
of these issues and provides a broader view:

[https://news.ycombinator.com/item?id=10665520](https://news.ycombinator.com/item?id=10665520)

 _If we were going to rank our priorities, they would be in this order:

1) Make mass surveillance impossible.

2) Stop targeted attacks against crypto nerds.

It's not that we don't find #2 laudable, but optimizing for #1 takes
precedence when we're making decisions.

If you don't want to use your phone number, don't use it. You can register
with any GV, Twilio, Voicepulse, or other throwaway VoIP number.

If you don't want to run Chrome, use Chromium instead.

If you don't want to use Google Play Services, use GcmCore.

The world you want this software for is not the world that everyone else lives
in. You can certainly make it work in that world with a little effort, but
because of how we've prioritized our objectives, that's not the default
experience._

~~~
ge0rg
_Signal requires users ' phone numbers._

True for Signal. XMPP is using JIDs which are functionally comparable to email
addresses, and similarly anonymous (or not).

 _Is there a way to run your own Signal server?_

The Signal client is open source, the server mostly so. You could create your
own semi-Signal community, but it would not be able to talk to official-Signal
users.

XMPP is designed for federation by default, and you can run your own server,
akin to email. Though some server operators decide to disable or cripple the
federation feature (Facebook, Gmail).

 _Would I need to trust Signal more than I would need to trust Jabber?_

This is a complicated matter. You need to trust the server operators to handle
metadata in both scenarios, but you can run your own server with XMPP. You
need to trust the client developer, which is Signal in one case, or the
developer of your choice (or yourself) in the other. You need to trust the
device manufacturer/Google in both cases.

~~~
gurrone
What is this constant rumor about that Google killed XMPP federation? I think
they killed the XMPP support in their own clients, but in general they still
provide the service. I've at least three active @gmail.com XMPP accounts in my
roster on a private server. I've read some rumor that they do not do TLS for
server2server traffic, but in the end if you use XMPP on your desktop you most
likely use OTR.

~~~
ge0rg
In 2013, the xmpp community decided to enforce TLS on all server-to-server
links [0]. Google still doesn't support this, essentially preventing non-gmail
users to communicate with them.

While OTR is a possible solution, it has its own can of worms (multi-device,
offline use).

Besides of this, Gmail xmpp silently fails if the other party upgraded to
hangouts.

[0]
[https://github.com/stpeter/manifesto/blob/master/manifesto.t...](https://github.com/stpeter/manifesto/blob/master/manifesto.txt)

~~~
tptacek
Apologies in advance for pedantry, but OTR and TLS aren't comparable security
solutions. Unlike TLS, OTR is end-to-end. You can't trust the security of an
XMPP conversation that occurs over TLS connections without also trusting all
the servers in between.

------
0XAFFE
I recently tried riot.im and I'm realy blown away by the good UI they have and
how easy it is to get started to develop your own stuff.

It is a shame that nothing by the likes exists in the XMPP-sphere.

EDIT: As a side note: Daniel Gultsch from the conversations-fame is doing a
great job by providing/developing a realy awesome XMPP client for android and
pushing the standard forward.

~~~
unicornporn
I registered when it was called called Vector and recently started using it
more seriously. It is freaking fantastic. Voice/video calls actually works and
the Android app is very good. It was long since I had such as strong feeling
of "this is it".

When it comes to protocols (as opposed to "services"), they're seldom
replaced. I mean, we're still using IRC for open source projects. Matrix/Riot
gives me a glimpse of the future.

I recommend reading this: [http://www.titus-
stahl.de/blog/2016/12/21/encrypted-messenge...](http://www.titus-
stahl.de/blog/2016/12/21/encrypted-messengers-why-riot-and-not-signal-is-the-
future/)

~~~
kuschku
> I mean, we're still using IRC for open source projects. Matrix/Riot gives me
> a glimpse of the future.

Matrix/Riot does tend to break down in channels with 30k users all chatting,
sending hundredthousands of messages per minute. (Which is a real use case of
IRC).

~~~
riquito
I'm ignorant on the subject, how can hundred/thousands messages per minute be
a real use case? I would expect such massive amount to be parsed by robots,
not humans, and in that case why use IRC at all instead of a queue system like
RabbitMQ? Maybe because it's easier to share an IRC channel than an open
queue?

~~~
kuschku
Well, take QuakeNet's #eurovision during the ESC. Tenthousand users, all
spamming as fast as they can type.

If that is a meaningful discussion is another topic, but many chats for live
evenys, especially on Twitch, have these numbers of users and messages.

------
woliveirajr
> A single decision by Moxie or a single court order in some country can make
> Signal unavailable to a large part of its user base.

This is a great point made later on the thread.

And already happened in some countries, for example, with whatsapp.

Social pressure was big enough to revert it in a reasonable time, but _time_
is very relative on how much you or your business relies on it.

~~~
tehabe
But even if Moxie does something weird or some country breaks Signal. You and
your contacts can easier switch to another system.

While when your XMPP server admin does something weird or a country breaks it
you are locked in.

For Signal you use an ID which is not owned by Signal. So for Signal and alike
the decentralisation doesn't come from the service but from your own social
graph which is your phone book on your smartphone.

Moxie explained it much better I think.
[https://whispersystems.org/blog/contact-
discovery/](https://whispersystems.org/blog/contact-discovery/)

~~~
nine_k
Is mobile number portability a thing in every country?

I suspect that relying on IDs owned by _another_ system can have its
drawbacks. Maybe it's not likely that an entire country is forced to change
phone numbers. It's still possible to lose a number for various reasons (most
entirely benign). An oppressive government could definitely disrupt
communication of suspects by forcing the phone company(-ies) to terminate
their contracts and unlist their numbers.

(But IDs being piggy-backed to a different system which is not easily
disrupted on a mass scale does have some advantages, too.)

~~~
tehabe
Good question, also it was only a remark that the phone number or email
address is not owned by the IM system. They can change anyway.

I got my mobile number in 1999 and already switched twice with the number.
Sadly it is kinda expensive to take the number with you, 25 to 30 euros.

------
rvern
People who care more about convenience than freedom and privacy can and do use
Skype, iMessage, and Snapchat. If you give up freedom and privacy to make a
more convenient client, you're not improving the freedom and privacy
situation, you're just making more of the miserable proprietary software that
we're trying to get away from.

If it's not free software, you have neither freedom nor privacy. If it's not
decentralized or federated, you have neither freedom nor privacy. The only
contenders for freedom and privacy are XMPP and Matrix. All the others are
contenders for money and popularity, but not for freedom and privacy.

Popularity and money are useful and not inherently incompatible with freedom
and privacy, but they are secondary. Creating a new application that is not
federated or decentralized _does not help_ , no matter how much more popular
or convenient it is.

~~~
kelnos
Except that messaging services are useless if the people you want to talk to
don't use them. If all the people you want to talk to share your
prioritization of freedom & privacy above everything else, then you're
probably ok using a federated, self-run XMPP style messaging system.

Unfortunately, for the vast majority of people, that just isn't the case. I
would love it if I could use XMPP-based services to talk to everyone I care to
talk to, but, in practice, I use 8 different messaging services, and all of
them are walled-garden non-XMPP services.

In the end, the people I know who care about privacy and security communicate
with me using Signal (can count that number on one hand), and the rest use one
of the others.

You can say and wish all you want that popularity and money are secondary, but
in the world we actually live in, they're #1. I expect that won't change until
and unless something horrible happens and "regular people" have their privacy
compromised in a way that causes them real, tangible, extreme harm.

~~~
chriswarbo
> Except that messaging services are useless if the people you want to talk to
> don't use them.

This applies to centralised/proprietary systems as well, including those 8
walled gardens that you use.

When Slack was created, nobody was using it. When Signal came out, nobody was
using it. Same with Telegram, Skype, Twitter and all the other
centralised/proprietary systems.

Some of those _did_ manage to gain enough users for positive network effects
to kick in, so "nobody uses it" isn't specific to FOSS/decentralised/federated
systems, it applies to messaging systems in general. The fact that so many
messaging systems keep being created, and so many users hop from one to
another, shows that it's not a particularly strong argument either.

The real problems for systems like XMPP are the levels of investment required
in marketing, UI design, etc. to compete with the proprietary systems.

~~~
kelnos
Right, I think the point I was -- poorly -- trying to make is that your
average user doesn't care about federation (or openness). It comes down to
which service has the best marketing and can capture the most market share.

------
upofadown
The real issue is federated IM vs non-federated IM. Anyone can make a IM
system work off a single server. People do it all the time and we have had a
series of incompatible IM systems in the past. Signal and Whatsapp are just
the current flavours. Soon they will be gone and there will be new hotness. At
this point I consider any non-federating IM system to be part of the problem.

As mentioned by someone in the linked thread, part of the user problem is that
users can't even conceive of a federated IM system and don't know what one
might be like. Asking someone to get a XMPP client so they can communicate
with you normally just ends in confusion. There is no download button on the
xmpp.com site.

* [https://mail.jabber.org/pipermail/standards/2017-January/031...](https://mail.jabber.org/pipermail/standards/2017-January/031898.html)

~~~
zanny
I'd argue the future isn't just federation but bridging. We have already seen
repeated attempts on the client side to abstract IM platform - Pidgin being
the largest, but a ton of effort was invested into the Telepathy framework for
about a decade.

The adoption rates show a general failure of the model.

Server-side transparent interoperability like Riot has with several services,
however, seems extremely promising as a way to break that cycle.

~~~
bigbugbag
Bridging is the problematic issue that gave birth to federation, so I'm pretty
sure you're mistaken here.

~~~
zanny
I said isn't just, meaning you need both.

XMPP was a tower built too tall and wide and it crumbled under its own
optiomal extension weight.

Just bridges mean you are still selling your soul to a primary operator, which
prevents trust.

Federation and bridges without extension hell means you can use whatever
homeserver you want, bridge to whatever you need to, and finally have working
interoperable IM.

------
ge0rg
The context of the discussion ("Easy XMPP") is an attempt to fix the UX of
XMPP clients, which starts with a set of small steps documented in the pages
linked from
[https://wiki.xmpp.org/web/Easy_XMPP](https://wiki.xmpp.org/web/Easy_XMPP)

------
nextos
I think the issue with XMPP is the myriad of XEPs (XMPP extensions) which are
optional, causing excessive fragmentation.

Some clients are excellent, like conversations.im. The problem is accidental
complexity. Perhaps a solution would be to have a meta XEP that aggregates a
few basic XEPs and defines a minimum common denominator.

~~~
ge0rg
There are attempts at creating an XMPP compliance suite[0], but the biggest
problem is actually a lack of volunteers / money to improve the clients and
servers. Conversations is driven by one full time developer, most other
applications are hobby projects.

[0]
[http://xmpp.org/extensions/xep-0375.html](http://xmpp.org/extensions/xep-0375.html)

~~~
digi_owl
It was a real sad day when Facebook and Google decided that proprietary was
the way to go...

~~~
ariwilson
The writing was on the wall before that, though. WhatsApp was eating
everyone's lunch and Facebook / Google wanted to move faster and own the
messaging space.

~~~
riquito
WhatsApp didn't exist yet

~~~
ariwilson
WhatsApp has existed since 2009, which preceded Google Hangouts by 4 years.

------
reidrac
I'm not sure "popular clients" is a good thing to look at; Skype UI isn't
great (and really bad if you use the IM part of it).

On this topic; I wouldn't mind hosting my own XMPP service, but most clients
aren't good enough (specially on Android). I can't advocate for a service
(protocol?) that can't offer some basics that are covered and seamless
everywhere else (eg, sending files, showing media files in the client itself,
etc).

I understand standards are slow, but when I think how difficult was to get
avatar support everywhere... it makes me sad.

After many years, I gave up on XMPP recently for "internal family"
communications. I'm using Telegram now, although it really bothers me that I
need a phone to start using it.

~~~
detaro
I thought Android is one of the best-supported platforms with
conversations.im?

~~~
reidrac
Yes, you're correct; but I found the UI too ugly and at that point I was
already too frustrated. It's probably me, but I had put already too much time
on something that shouldn't be an issue.

~~~
detaro
Fair enough, and not good if that is the feedback about a well-supported
plattform. Still looking for a more-than-basic desktop client.

------
anotheryou
I have 0 friends using signal so it's hard to give it a try: Did they fix the
multiple devices end-to-end problem? Can I continue a conversation from my
smartphone on my desktop? ( _should_ be possible by mirroring the
conversations and having 2 keys). This was what killed OTR for me (and that it
fails on unstable mobile connections, and the setup).

~~~
jimmies
Yes, you can carry the conversation from phone to several desktop platforms.
It uses a Chrome extension to achieve that.

You can't have two phones synchronizing yet, though.

~~~
izacus
Yes, you can't have two phones, or a phone or a tablet, or two computers
synchronizing. It also won't synchronize SMS conversations, it'll hijack the
SMS datastore if you want to use the seamless mode and do a bunch of other
annoying stuff :/

~~~
lima
You can workaround it somewhat by using groups and join both of your devices.
The cryptographic primitives for multi user messaging are there.

~~~
jimmies
Your crypto-enthusiast friends will be like "why is our conversation CC'ed to
another number?" and you'll have to explain to every single one of them that
it is a multi-device workaround.

And then when the NSA decided that they need their number CC'ed, your friends
won't ask you...

------
ploggingdev
I think there is still place for an end to end encrypted Jabber app with an
option to self host the server. This would avoid the single point of failure
issue that Signal has (Signal servers being blocked in certain countries).

~~~
scaryclam
Also for companies where we want to self host and not have our communications
routed through a third party.

------
geofft
What federated / decentralized protocols have been actual successes? For what
protocols can I set up my own server in my house or in some cloud service, and
have a comparable experience to using a major provider's service (modulo
scalability and personal sysadmin effort)?

I'm worried that the _only_ ones seem to be email and the web, both of which
came into existence when the internet was small and academic and it was
natural for universities to decentralize. And running email on your own is
getting increasingly hard because of spam and IP reputation. (We seem to have
more-or-less won the war on spam, but at the cost of making email much less
decentralized than it used to be.)

There's a mention of BitTorrent elsewhere in these comments, and there might
be an argument for Bitcoin. But even for IRC, people tend not to run their own
servers (although they could); there are a very small number of IRC networks,
run by random people.

I would love to see a decentralized and federated team chat app along the
lines of Slack or Discord, but I'm having trouble believing that such a thing
would have a chance of success in a post-1995 internet.

~~~
bigbugbag
> running email on your own is getting increasingly hard because of spam and
> IP reputation.

Are you sure ? [https://mailinabox.email/](https://mailinabox.email/)

~~~
geofft
I am not sure, but that page doesn't talk about deliverability at all, as far
as I can see. Is it generally true that spawning a mail server on a random
cloud instance will work for deliverability? I would have assumed that any
given cloud IP has a nonzero chance of having been used by a spammer in the
past.

(Or, in other words, if this does work, why do people who have small- to
medium-scale deliverability needs use a dedicated email-sending provider
instead of just using a t2.nano running an AMI with Postfix?)

------
niftich
The technical merits and drawbacks of XMPP aside, deployment only works if
there's an appetite from deployers. For high-visibility consumer chat that
average people use, this appetite has vanished.

Around the mid-2000s, IM networks started getting tired of constantly changing
their protocols to thwart third-party reverse engineering efforts like
Microsoft logging into AIM, libpurple (Pidgin), or Trillian. But then Google
Talk appeared [1] in 2006 inside the coveted invite-only Gmail, supporting
XMPP, and significantly raised the bar.

So interoperability became a tool to maintain market share. The underdogs WLM
and Yahoo started seamless interop [1] in July 2006, while Google Talk and AIM
started a limited interop [1] in 2007. AIM briefly dabbled with XMPP it in
2008 [2] (great source -- see comments for AIM's response).

In the meantime, Facebook opened up for everyone, introduced Chat and rapidly
lured away the myspace/AIM generation, becoming a major player in chat.
Facebook introduced XMPP in February 2010 [3] but discontinued it [4] in 2015
after having deprecated it the year prior. This neatly coincided with their
announcement to monetize the Messenger ecosystem, in ways that require a
captive client [5].

Other vendors are similarly pursuing monetization within the client --
Snapchat and Kik as a content portal [6][7][8][9], Google as a context-aware
assistant, Microsoft is lost at sea, Whatsapp as a Facebook data mining
scheme, the Asian apps as a combination of all other techniques and
microtranactions -- when anyone can bring a third-party client, their
monetization strategy suffers. This makes XMPP's deployment future exceedingly
bleak, perhaps restricted solely to corporate deployments.

[1]
[https://news.ycombinator.com/item?id=11114518](https://news.ycombinator.com/item?id=11114518)
[2]
[https://web.archive.org/web/20080120143857/http://florianjen...](https://web.archive.org/web/20080120143857/http://florianjensen.com/2008/01/17/aol-
adopting-xmpp-aka-jabber/) [3]
[http://web.archive.org/web/20100318030410/http://developers....](http://web.archive.org/web/20100318030410/http://developers.facebook.com/news.php?blog=1&story=361)
[4]
[https://developers.facebook.com/docs/chat](https://developers.facebook.com/docs/chat)
[5]
[https://developers.facebook.com/blog/post/2015/03/25/introdu...](https://developers.facebook.com/blog/post/2015/03/25/introducing-
messenger-platform-and-businesses-on-messenger/) [6]
[https://news.ycombinator.com/item?id=11935956#11941090](https://news.ycombinator.com/item?id=11935956#11941090)
[7]
[https://news.ycombinator.com/item?id=12000854#12002773](https://news.ycombinator.com/item?id=12000854#12002773)
[8]
[https://news.ycombinator.com/item?id=12206846#12207459](https://news.ycombinator.com/item?id=12206846#12207459)
[9]
[https://news.ycombinator.com/item?id=12272973#12273447](https://news.ycombinator.com/item?id=12272973#12273447)

~~~
billiam
Great footnoted history....I will reference this when younger developers ask
me the "WTF messaging" question, which happens a couple of times a year. I
suspect it will be useful for many years to come.

------
SamWhited
I think the real issue here is that too many people conflate XMPP the protocol
with the various XMPP based services (most of the smaller free public services
do this). If we tell people to "go sign up for an XMPP account" it's obviously
going to be too complicated; they're going to search, find the XSF websites or
a bunch of random libraries and protocol information, and give up. Meanwhile,
companies can use XMPP and build their own brand around chat products based on
it (while never mentioning it, because their users don't care) and regardless
of whether they choose to federate or not they can reap the benefits of a
community of protocol developers, the plethora of libraries, and maybe even
existing client and server code.

~~~
niftich
Didn't OpenID have this exact same problem?

Interestingly, email didn't, despite acronyms like POP3, IMAP, SMTP being a
frequent occurrence once you try to supply an email client of your choice. So
what was different about email, once internet users started escaping the
walled gardens of old?

~~~
rakoo
Users were all registered by default to an email account at their ISP. _All_
of them could send emails back and forth to people inside and outside their
ISP. When they started to suck, they registered new addresses on specialized
email providers, and they kept their contact list with them, so emails could
still be used. Because emails was pretty much the first way of communicating
and because of how common it is it won't disappear soon.

------
eponeponepon
It would (will..?) be a crying shame to see XMPP grind to a halt - but I
suspect, sadly, that the honest answer to the question is "not one heck of a
lot really". I don't know if it got started too early, or moved too slowly, or
what - but in the end, it missed its boat.

~~~
ausjke
what's the universal alternative for XMPP?

~~~
JustSomeNobody
In the U.S.? SMS is as close to universal as one can get (which is to say, not
very).

------
leonroy
XMPP is still pretty relevant in the server to server space and in large
companies requiring a scalable API which offers async, full duplex comms over
a single socket connection and offers libraries and message brokers in pretty
much every language.

That said I do believe some of our XMPP customers are starting to look around
and ask for REST/Websocket based APIs as their new dev team hires look to
reinvent the wheel ;)

Seriously speaking though - I think XMPP missed the boat as far as messaging
goes. Smart phone apps took everyone unawares and XMPP didn't move fast enough
to provide a solution for low power devices on high latency networks.

That said I wonder if there is a future in which XMPP does prove to be a
compelling solution. I wouldn't put money on it, but even today a full duplex
API which is highly secure, async and which offers schema enforced validation
of your messages sounds pretty damn compelling. That said there is a lot of
progress with things like STOMP, RabbitMQ etc. providing the pieces necessary
to replace XMPP.

It's a pity since XMPP makes it so damn easy to build reliable, realtime apps.

------
bborud
I wanted to like XMPP, but I never did. It drowns developers in complexity so
they never get around to solving anything interesting or useful.

Bonus: I once discovered I had two of the main culprits for XMPP getting one
of its worst misfeatures (lack of sensible framing) in the same room so I got
to yell at them for it.

XMPP was form over function. And it wasn't even pleasant form.

~~~
upofadown
In a sense the problem with XMPP is that it is too simple. If you are willing
to type some XML you can log into a server and have a basic chat session over
a telnet session. Hence the requirement for extensions to do anything else.

The alternative is to try to anticipate everything anyone would want to do
with a protocol. That has problems as well. The XMPP approach is to accept
everything and aggressively ignore everything not supported. XML is quite
compatible with this approach.

XMPP uses the XML as the framing. An approach that could actually be
considered clever if one is striving for simplicity in a protocol.

~~~
bborud
Good protocols have a layered design where you deal with different concerns in
a fashion that promotes simplicity, robustness and performance. For instance
first the complexity in framing individual messages, then the way you
represent the payload (on at least 2 levels), and then the semantics you can
layer on top of that.

Using XML framing in XMPP was the opposite of simplicity. (Sure it was simple
in the sense that it required zero experience with actual implementation of
protocols to arrive at the conclusion, but the result was something that was
harder to implement properly).

It is "simple" for moronic, bad, implementations of the protocol, but it only
complicates the situation when you need performance, quality and efficiency.
It complicates it greatly. In essence, you end up having to write two parsers:
a shallow framing parser and a deep parser.

And if you think you are going to get any help from the fact that there are
lots of XML parsers: I've got bad news for you. There's lots of XML parsers
that are meant to parse documents. Not millions of simultaneous, "endless"
streams of data from dodgy clients.

XMPP is not good protocol design. It is brutally stupid protocol design.

(An irony is that right now there are several areas where you would want to
use a messaging protocol for small devices. This ought to be the moment where
a messaging standard had a chance to shine. And XMPP ends up being one of the
least desirable protocols because so little care was taken in designing it)

~~~
upofadown
> There's lots of XML parsers that are meant to parse documents.

You obviously wouldn't use such a parser for XMPP. You would use a parser
designed for the purpose. Very few people would ever have to even think about
the issue, there are XMPP libraries available for pretty much any environment
in existence.

~~~
bborud
This is true for people who write applications. It is not true for people who
would like to write servers and XMPP libraries that are somewhat efficient.

XMPP also isn't usable for many new IoT applications where it _should_ have
had its opportunity to shine, but where there just isn't enough memory to deal
with the ridiculous bulk.

But I do get that most developers don't really try all that hard. I mean, look
at the resource usage of Slack. It is an application that does _nothing_ that
requires CPU, yet it gobbles it up. It tells you something about the kinds of
people that write chat applications today. Not exactly the sharpest tools in
the shed.

~~~
upofadown
>...the ridiculous bulk.

Well presumably this hypothetical IoT application would have to support
TCP/IP. Against that, a few hundred bytes of state table for the limited
subset of XML required for basic XMPP would count for much.

~~~
bborud
You presume. I write code that has to deal with it. That's the difference.

------
panic
The fundamental problem with decentralized messaging these days is push
notifications. Apple, at least, makes it very hard for you to deliver APNS
notifications without running a centralized server. XMPP and IRC will never
work as well as a centralized service until the notification architecture
changes.

~~~
ge0rg
Actually, XMPP has a solution for that for a year now [0]. The principal idea
is that a client developer runs a push proxy component that forwards XMPP push
events to GCM / APNS / whatever. The client tells its server which push
component should be contacted and disconnects.

[0]
[http://xmpp.org/extensions/xep-0357.html](http://xmpp.org/extensions/xep-0357.html)

~~~
panic
These proxy components have many of the same problems as centralized servers.
If the proxy component goes down, your client stops working. You can't just
download any random client and have it work forever. You have to trust that
the developer won't shut it down. Paying the developer can give you this trust
(see IRCCloud), but most people aren't willing to pay for something they can
get for free elsewhere.

------
seqastian
The advantage of slack over jabber is not only that the client doesn't suck
(it's just electron) but that the server logs and creates a continuous
experience for the user no matter if hes on mobile, in a browser or both.

~~~
kalleboo
There's an XEP for the server to keep a message archive and provide the same
experience.
[http://xmpp.org/extensions/xep-0136.html](http://xmpp.org/extensions/xep-0136.html)

What servers, and what clients implement it though? No idea...

~~~
SamWhited
Most things use Message Archive Management these days:
[https://xmpp.org/extensions/xep-0313.html](https://xmpp.org/extensions/xep-0313.html)

It's still experimental, but it should replace message archiving "soon" once a
few final kinks have been worked out (that being said, most servers and
clients implement it already and in my mind it's ready for production).

------
_pferreir_
> A single decision by Moxie or a single court order in some country can make
> Signal unavailable to a large part of its user base.

I think the solution here would be a "lightweight" federation of 3 or 4
entities following a common charter and covering a wide geographical area. If
one drops out for some reason, the others will still ensure the service
remains alive.

~~~
bigbugbag
Then it is a single court order and 3 people agreeing on the same decision
which is quite easy to make when it has to made at gunpoint.

The actual solution has been known for ages: decentralization, federation,
peer-to-peer. pretty much what the internet was designed to be.

~~~
_pferreir_
> Then it is a single court order and 3 people agreeing on the same decision
> which is quite easy to make when it has to made at gunpoint.

Not if the 3 entities reside in different countries/jurisdictions.

> decentralization, federation, peer-to-peer. pretty much what the internet
> was designed to be.

While I agree with you from the theoretical standpoint, it's been already
shown that neither users nor providers care about that. A federation is not by
any means easy to maintain (just look at the amount of work spent in keeping
e-mail relatively free from spam and usable). So, either the federation in
question is small enough that you can keep it under control or you're better
off researching a fully decentralized system that is resilient to all the
problems all other services have (doesn't sound easy to me).

------
RichardHeart
Ricochet.im uses tor hidden services for messaging. No signup, no choosing
your own name, no logging, since it uses tor hidden services, whatever
security improvments tor gets, it should get. A while ago when there was an
explosion in the number of hidden services running, I think it was this
program. Thoughts?

------
ericmoritz
We don't need another federated network. Administrators of those nodes are
putting themselves into danger. What we need to develop is a purely
decentralized p2p network that is resistant to censorship and eavesdropping.

------
hypercluster
Well it would be enough to have one proper client for each platform. On
Android Conversations, iOS Chatsecure now with OMEMO as well. Desktop.. not
sure. But to be honest, I think I'll prefer Matrix with Riot right now.

------
selvakn
Has anyone tried [https://coy.im/](https://coy.im/) ?

~~~
nhxu
The idea looks cool but not that they explicitly don't want to support OMEMO
sticking with old OTR:
[https://github.com/twstrike/coyim/issues/233](https://github.com/twstrike/coyim/issues/233)

------
cdelsolar
competition is healthy

~~~
Faaak
Except when you've got so many clients and so many servers that the typical
user gives up instead

~~~
dsr_
Email exists.

When Slack is bought by Google and merged with Hangouts, and WhatsApp changes
over to a new all-messages-delivered-by-the-NSA protocol, email will still
exist.

~~~
bluesign
Email survived because it is adopted as main identity provider, similar for
SMS

~~~
cyborgx7
I've recently been thinking about xmpp making for a great federated identity
provider for multiplayer video games. With communication already built in,
initialization of peer-to-peer sessions already a common use-case, and the
right XEPs it could replace centralized services like steamworks, psn or xbox-
live.

------
truftruf
Signal is a centralized point of failure and surveillance.

Why can't I run my own signal server? Why doesn't the client support this?

We need something like Signal that that isn't under the control of a single
party.

~~~
mixedCase
That very much sounds like Matrix. Not only it provides a secure, federated
WhatsApp/Signal-like experience, but it can replace Slack as well.

~~~
SamWhited
It also sounds very much like XMPP.

