Add XMPP transport support

[BLeQuerrec]

This PR adds XMPP transport to send secure messages only.

TODO/Features:

• Add XMPP page into intro screen
• Add new "XMPP address" message type to do not use a centralized directory
• Add new XMPP message type when transport is set to XMPP
• Switch to secure SMS if the recipient is offline
• Allow user to use a custom XMPP server
• Delete XMPP account if the user disables XMPP feature
• Display a warning if the custom XMPP server doesn't support XEP-0198 Stream Management (required to do not lost messages when switching from a network to another or on unreliable connectivities)
• Fix bad encryption with long XMPP messages
• Display an XMPP icon for XMPP messages
• Ask the user to optionally set up XMPP on first boot
• Improve XMPP address sharing mechanism
• Share XMPP address when a secure session is started
• Implement a form to manually set up an XMPP address
• Fix recipient status (sometimes a recipient is seen as offline but it is actually online)
• Add support for XMPP media messages (for now, Silence crashes)
• Write documentation
• Include a list of trusted XMPP servers to allow users to register
• OMEMO?

This PR fixes #370 as a side effect because it starts Silence on boot.
For now, the list of "trusted XMPP servers" only contains xmpp.silence.im, which is not designed to be used except for testing. We won't host an XMPP server in the short term.

[paride]

XMPP messages are encrypted and no unencrypted message will be sent using XMPP transport. Moreover, XMPP transport relies on SMS messages to exchange XMPP address and avoid a centralized directory (Signal uses a centralized directory at the cost of a privacy issue). So Silence is, and will always be an SMS/MMS app ; XMPP transport will not change this.

Thank you for the clarification. This is very interesting, and it's worth pinging LibreSignal/LibreSignal#37 about it, as there is a lot of attention on alternatives to Signal there.

[eighthave]

I think that SMSSecure as a put SMS/MMS app is quite nice. For XMPP, why not join forces with Conversations, Zom, ChatSecure, Kontalk, Xabber, etc.? There are lots of XMPP apps, what we need to make them work better.

[BLeQuerrec]

@eighthave In my opinion, users doesn't instinctively open a 3rd app on their phone to see if the recipient is online. Silence is designed, like Signal, to replace stock SMS/MMS apps to encourage people to do not use SMS/MMS messages when they can. Adding XMPP transport to Silence will do the same as Signal, with the advantage of a federated protocol.

[paride]

As the TODO list is still open, I drop here an idea. Should the XMPP account be created automatically (on a random server) the first time the app is started, unless the user taps on some "advenced options" button?

In this way the UX would be more streamlined ad similar to what users are already used to.

[BLeQuerrec]

@legovini Added.

[BLeQuerrec]

@legovini Here it is:

Tapping on the link will display the activity to register an account.

[betsythefc]

I love this idea though I would support an "advanced" area where techies can specify their own server and a user/password. I think it would work if we could allow unencrypted XMPP chat to non Silence users but I would have a GUI element that specifies the transport and the encryption status.

If 2 users have Silence and have separate XMPP accounts, they would by default start sending encrypted XMPP because Silence would let them both know they are using XMPP. My 2 cents.

[BLeQuerrec]

@betsythefc Users will be able to use their own XMPP server. Silence's goal is not to be another XMPP client, but to merge secure SMS communications with secure XMPP ones. Additionally, in a post-Snowden world, unencrypted communications should be banned. So we won't support unencrypted XMPP messages.

OMEMO is a great response. I was quite reluctant to use OMEMO before, and this was a mistake. OMEMO support in Silence will allow people to chat with non Silence users on Android (Conversations) and with non Silence users on iOS (ChatSecure). So OMEMO will allow to chat with iOS users via encrypted XMPP messages and this will address a major flaw in Silence: it can't be ported on iOS.

In short: Silence won't support unencrypted XMPP messages, but it will still be able to communicate with OMEMO clients on Android and iOS.

[betsythefc]

@BLeQuerrec
I never even thought about OMEMO. I support that over unencrypted communications.

[SkewedZeppelin]

Not to add to the notification spam, but https://omemo.top/ is a great site to track the progress of OMEMO in all the clients. @BLeQuerrec you should create a issue or PR on https://github.com/bascht/omemo-top to add Silence referencing this issue.

[ArchangeGabriel]

Hum… Coincidentally I’ve been thinking a lot about this feature y-day, and those new messages change my way of thinking.

@BLeQuerrec Could you please (re-)explain clearly the goals of this integration, in what this would be different than using e.g. Conversations (or a encryption-only version of that), how different would Silence be from those XMPP clients that exists? Since the goal seems to have shifted a bit from allowing XMPP encrypted message between Silence users to a larger support of XMPP, those questions seem back to the table for me.

If you’re now so close from an XMPP client, why not just “fully” integrate Conversations into Silence (while making removal choices based on security/encryption)?

[BLeQuerrec]

@ArchangeGabriel Silence allows to encrypt SMS/MMS messages, so it requires authorization to send and receive SMS/MMS messages. Thus, Silence cannot be ported to iOS because this OS forbids third apps to manage SMS/MMS messages.
Additionally, metadata of SMS/MMS messages cannot be hidden.

XMPP support with OMEMO will address this two flaws:

• Metadata: XMPP addresses won't be linked to a phone number. Phone numbers are quite convenient to share, but make surveillance easier. XMPP addresses will be randomly generated (using a UUID, ie. f8f0ffd6-1528-11e7-93ae-92361f002671@example.org) and exchanged with key exchange messages.
• Communicate with non Silence users: using OMEMO will allow Silence users to securely communicate with non Silence users (for example iOS users via ChatSecure). SMS/MMS messages won't be available with those users and exchanging XMPP address will be less convenient (UUID instead of a phone number).

Communicating via XMPP messages between two Silence users will allow them to hide their metadata while being able to fallback to encrypted SMS/MMS messages in case of unavailable/unreliable data network. Silence doesn't aim to be yet another XMPP client but to merge a SMS/MMS client with a XMPP client. In one interface, people will be able to use the best available communication channel.

Signal/TextSecure did the same: historically, TextSecure was a SMS client then offered push messages. But in my opinion TextSecure's devs made two mistakes:

• encrypted SMS message should not be dropped because 3G/4G networks aren't always available and communicating using encrypted SMS messages is better than with cleartext SMS messages.
• push messages in Signal relies on a centralised service. Recent major outages highlighted this flaw. XMPP messages in Silence will rely on a decentralised and open protocol.

[eighthave]

Conversations exists, merging it into Silence will only make Silence have an massive code base and UX with difficult issues.

[zoff99]

when will this be merged? when will the first working beta be on f-droid?

[BLeQuerrec]

@zoff99 Really don't know. Proper dual-SIM support is quite stable and will be merged in master soon. Then I'll focus on XMPP messages.

[pR0Ps]

I should start this by saying that I personally have no use for XMPP in Silence so naturally I'm a little biased against including it.

With that being said, I tend to agree with @eighthave . Conversations is a very mature application with a lot of work put into it (4,000+ commits, more than 1.5x as many as Silence). If we try to do everything it's doing inside Silence, we're setting ourselves up for having an inferior implementation that pulls limited dev hours away from other issues. Conversations has been averaging ~10 commits a week, and from what I can see, most of them are maintenance and bug fixes, not new features. Even if we managed to get something that was on the same level of quality as Conversations tomorrow (extremely unlikely), that kind of extra maintenance load isn't trivial.

I'd hate to see SMS/MMS-related issues go unfixed because of XMPP-related things. There are other great options for encrypted XMPP clients. There are no other good options (that I know of) for encrypted SMS clients.

In short: I don't think having everything conveniently in a single app is worth it if that single app is going to suffer quality issues because the development resources are spread to thin.

---

EDIT:
From a technical side of things, using XMPP to talk to other Silence users with an encrypted SMS fallback seems like it will actually limit the options that person has for receiving your messages.

If you have some of your messages going over XMPP, and some automatically falling back to encrypted SMS, other XMPP apps will only ever see the XMPP half the conversation. Recipients would have to use Silence as well to get the full conversation, which negates all the federation benefits of XMPP.

Or, both users could pick from the many XMPP clients out there and feel free to use whichever one(s) they want. And if the person is offline, switch to Silence and send them an encrypted SMS.

[betsythefc]

@pR0Ps I don't think the point is to replace an app like conversations but to allow IM'ing with other Silence users akin to Signal, but without a central server. I like the idea of using Axolotl to encrypt messages between Silence users, and if you had other contacts, you could message them using OMEMO encryption.

Again the point isn't to create another XMPP client, but to have a second, less metadata leaking, method of encrypted communications in one place with seamless failover.

[pR0Ps]

@betsythefc

allow IM'ing with other Silence users akin to Signal, but without a central server

My point is that this is already possible using other, more mature apps. Just read this: https://conversations.im/#xmpp . Those are just the specifically called out features. As @SpotComms mentioned earlier, there are many more. I really don't think all that is going to be super simple to implement in a slick UI that also has to deal with falling back to SMS/encrypted SMS. I know I don't have the skill/time/desire to do it.

This would be an absolutely huge undertaking and frankly I think it would be better to put that effort into making improvements to the unique core aspect of Silence - encrypted SMS/MMS and the easy-to-use UI around it. I haven't had a lot of time for Silence dev in my life recently, but that's where I'll be focusing my efforts when I do.

[zoff99]

the real question is: why did Signal drop encrypted SMS? stubborn developer.

Conversations is not usable by the average non technical person. maybe Zom will do better.

[eighthave]

my guess is that Whisper Systems dropped SMS support because it was more work to keep it working with a modern messaging experience than they could reasonable allocate to the task. Whisper Systems isn't WhatsApp, Facebook Messenger, etc. Its a pretty small team. And they have proven themselves good at prioritizing. Silence is a great app, and covers a need that nothing else does. Adding XMPP support to it will likely break that.

[zoff99]

@eighthave thats only your opinion. you are against almost any useful change. see f-droid

[pR0Ps]

Please stay civil and on topic.

[ArchangeGabriel]

Sorry for the delay of answer. So, having read those new replies, this is my current understanding about this:

• There is a metadata issue with SMS, that’s the starting point of this discussion and we all agree about that.
• XMPP allows to solve this in a federated manner, replacing SMS/Phone Numbers with Data/XMPP addresses. This is OK, since you’re not going to be better at privacy regarding metadata without switching to Data instead of SMS, and for most systems without removing the Phone Numbers as identification (more debatable, but let’s keep that aside, not really relevant here).
• That being said, you don’t want to create yet another XMPP client, since there is no point in this. We also seem to agree on this.

Now my thoughts: the point is to replace SMS with XMPP messages in the conversations with your Silence contacts without having to care of XMPP settings (random user address, random server picked from a list, initial configuration of the conversation — not an XMPP expert at all, but I guess that means exchange of IDs mainly — through the encrypted SMS canal and reuse of the same key to enhance its “verified” state, or if not possible auto-verification of XMPP keys over the SMS canal and in both cases why not the same for SMS key over XMPP canal).

Then I’m not sure that allowing to contact non-Silence XMPP users is a good idea. Why wouldn’t you just use an XMPP client for that? You don’t want to be one more XMPP client, but supporting this use case would make Silence de facto another XMPP client.

The point is that you want this feature to be as user-friendly as possible, and don’t want to bloat the app. Supporting only one use case (upgrading conversations with your contact to XMPP seamlessly, reusing the current key) is the better thing to do then.

If you want to communicate with non-Silence XMPP users, once again why won’t you just use an XMPP client? You’ll have to know about this technical possibility (this is advertised as a SMS client), enter their address somehow (or give yours, which is not user-friendly), verify the keys (though Silence doesn’t make that important/easy currently for SMS, so I have to maintain a list of my verified keys on my computer)… If you’ve gone that far, you could just as well use a proper XMPP client.

For me Silence is built around phone numbers, and its role is upgrading security of communications between those phone numbers. And it should only do that. They are already a lot of others open-source protocols and corresponding app for secure communications between users that are not based on phone numbers (e.g. federated: XMPP, Matrix; P2P: Ring, Tox).

Side question: do you want to provide encrypted calls using Jingle? Silence looks like a right place to me for this (just as Signal allows encrypted calls between users btw), because this carry the same intention as protecting SMS between mobile phone users (and there is a call button within the app, which could do the same as messages: try over XMPP if possible, fallback to normal call else). BTW, do anyone knows about any app currently providing this?

[zoff99]

@ArchangeGabriel "That being said, you don’t want to create yet another XMPP client, since there is no point in this. We also seem to agree on this."

--> that's the point. nobody agrees on that. and why should anybody.
what is the point in telling people NOT to write software?

that's not what opensource should be like. let everybody write whatever software that suits their need. don't discourage any development.

it's you that does not get the point. xmpp needs registrations and can not do SMS. you need 2 apps.
some people do not like that. and that's ok

[ArchangeGabriel]

@zoff99 I’m just trying to avoid useless spend of developers time. But in the end, it’s their code, they are free to do whatever they want regarding this topic.

Now regarding this one: I might have misunderstood what @BLeQuerrec said numerous time about Silence not going to be another XMPP client but merging SMS and XMPP. It could be that he wants a fully-featured XMPP client (but encrypted only) in Silence.

So if you don’t agree with my above analysis, and if you think this should be a real XMPP client (or said otherwise if you want to use the same app for SMS/XMPP or even Matrix, which almost already provides this — but no idea about the encryption status for XMPP/SMS here), then I think it is probably more worth to add SMS to Conversations (or Zom if you think Conversations is not friendly to normal users) than XMPP to Silence. See also #390 (comment). Reinventing the wheel again and again is not a good idea.

Now my personal take on all this is that, as per UNIX philosophy, one app should do one thing and do it well (a definition that could vary, because you can think of accessibility or enhanced security as goals for instance, and they are not always achievable at the same time). As I define Silence as an app allowing secure communications between phone numbers, what I would like it to do is provide a way to have secure messaging (SMS or XMPP when possible) and calls (XMPP again I guess) with the people I know by their phone numbers. It could even use a custom protocol (for both secure messages and calls), P2P based with seamless exchange of IP over encrypted SMS. That would even be better I think, but probably requires more work.

[1xPdd]

I'm really looking forward to having xmpp support. Is this feature already in the unstable branch in Fdroid? If so, how do I enable it? Thanks!

[rugk]

Seeing the commit history, maybe better focus on the "core product". See https://github.com/SilenceIM/Silence/issues/612 for my full statement.

[rugk]

So you've stopped working on this feature?/stopped the idea?

[williamdes]

@rugk go to https://git.silence.dev/Silence/Silence-Android/tree/xmpp :)