Add XMPP transport support #390

Open
wants to merge 1 commit into
from

Conversation

Projects
None yet
@BLeQuerrec
Member

BLeQuerrec commented Apr 27, 2016

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.

@BLeQuerrec BLeQuerrec self-assigned this Apr 27, 2016

BLeQuerrec referenced this pull request May 12, 2016

@paride

This comment has been minimized.

Show comment
Hide comment
@paride

paride May 12, 2016

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.

paride commented May 12, 2016

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.

@BLeQuerrec BLeQuerrec referenced this pull request in LibreSignal/LibreSignal May 12, 2016

Closed

Please add LibreSignal to f-droid #37

@eighthave

This comment has been minimized.

Show comment
Hide comment
@eighthave

eighthave May 12, 2016

Contributor

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.

Contributor

eighthave commented May 12, 2016

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

This comment has been minimized.

Show comment
Hide comment
@BLeQuerrec

BLeQuerrec May 12, 2016

Member

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

Member

BLeQuerrec commented May 12, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@paride

paride May 13, 2016

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.

paride commented May 13, 2016

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

This comment has been minimized.

Show comment
Hide comment
@BLeQuerrec

BLeQuerrec May 13, 2016

Member

@legovini Added.

Member

BLeQuerrec commented May 13, 2016

@legovini Added.

@BLeQuerrec

This comment has been minimized.

Show comment
Hide comment
@BLeQuerrec

BLeQuerrec May 14, 2016

Member

@legovini Here it is:
screenshot_20160514-172639

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

Member

BLeQuerrec commented May 14, 2016

@legovini Here it is:
screenshot_20160514-172639

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

@doodhout

This comment has been minimized.

Show comment
Hide comment
@doodhout

doodhout Jul 13, 2016

Any reason why this hasn't been merged yet?

It would be nice to have a single app to do all my messaging. Right now: Silence + Conversations, but the less the better.

doodhout commented Jul 13, 2016

Any reason why this hasn't been merged yet?

It would be nice to have a single app to do all my messaging. Right now: Silence + Conversations, but the less the better.

@zoff99

This comment has been minimized.

Show comment
Hide comment
@zoff99

zoff99 Jul 13, 2016

will this add internet permission to the app? that would be bad

zoff99 commented Jul 13, 2016

will this add internet permission to the app? that would be bad

@pR0Ps

This comment has been minimized.

Show comment
Hide comment
@pR0Ps

pR0Ps Jul 13, 2016

Member

The app already has internet permissions (needed to retrieve MMS messages).
As an aside, the internet permission is implicitly given to all apps by
Android.

XMPP will also only be introduced as an opt-in extra, it won't be enabled
by default and it won't replace the existing SMS transport. If you deny
internet permissions via Xprivacy then it just won't connect.

On Wed, Jul 13, 2016 at 12:21 PM, Zoff notifications@github.com wrote:

will this add internet permission to the app? that would be bad


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#390 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAcf_VHTxMHAiqTL-4dEDt6HiHzSKpCjks5qVRCMgaJpZM4IQ2DK
.

Member

pR0Ps commented Jul 13, 2016

The app already has internet permissions (needed to retrieve MMS messages).
As an aside, the internet permission is implicitly given to all apps by
Android.

XMPP will also only be introduced as an opt-in extra, it won't be enabled
by default and it won't replace the existing SMS transport. If you deny
internet permissions via Xprivacy then it just won't connect.

On Wed, Jul 13, 2016 at 12:21 PM, Zoff notifications@github.com wrote:

will this add internet permission to the app? that would be bad


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#390 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAcf_VHTxMHAiqTL-4dEDt6HiHzSKpCjks5qVRCMgaJpZM4IQ2DK
.

@doodhout

This comment has been minimized.

Show comment
Hide comment
@doodhout

doodhout Jul 14, 2016

As an aside, the internet permission is implicitly given to all apps by Android.

I really hope that that isn't true. I'm safe because I use a firewall to block apps by default, but many many people don't, so they are exposed. Isn't it so that apps only get internet access when they state that requirement in their permissions list?

As an aside, the internet permission is implicitly given to all apps by Android.

I really hope that that isn't true. I'm safe because I use a firewall to block apps by default, but many many people don't, so they are exposed. Isn't it so that apps only get internet access when they state that requirement in their permissions list?

@paride

This comment has been minimized.

Show comment
Hide comment
@paride

paride Jul 14, 2016

@doodhout, unfortunately it's true. The official explanation for this is:

The question was brought up in the session on Android M Permissions at Google I/O 2015, during the Q&A portion of the talk. An attendee confirmed that there was no permission group for Internet, and went on to ask if absolutely any app could have access to the Internet. The session speaker, Ben Poiesz, gave affirmative responses to both questions and explained that the logic for this decision was based around the idea that if all of a user's data is protected by default, there's very little reason to be concerned that an app can communicate with the outside world.

but it's clearly done so don't disable the Internet permission to block ads.

I'm also looking forward to the merge of this PR.

paride commented Jul 14, 2016

@doodhout, unfortunately it's true. The official explanation for this is:

The question was brought up in the session on Android M Permissions at Google I/O 2015, during the Q&A portion of the talk. An attendee confirmed that there was no permission group for Internet, and went on to ask if absolutely any app could have access to the Internet. The session speaker, Ben Poiesz, gave affirmative responses to both questions and explained that the logic for this decision was based around the idea that if all of a user's data is protected by default, there's very little reason to be concerned that an app can communicate with the outside world.

but it's clearly done so don't disable the Internet permission to block ads.

I'm also looking forward to the merge of this PR.

@doodhout

This comment has been minimized.

Show comment
Hide comment
@doodhout

doodhout Jul 14, 2016

@doodhout, unfortunately it's true. The official explanation for this is:

The question was brought up in the session on Android M Permissions at Google I/O 2015, during the Q&A portion of the talk. An attendee confirmed that there was no permission group for Internet, and went on to ask if absolutely any app could have access to the Internet. The session speaker, Ben Poiesz, gave affirmative responses to both questions and explained that the logic for this decision was based around the idea that if all of a user's data is protected by default, there's very little reason to be concerned that an app can communicate with the outside world.

but it's clearly done so don't disable the Internet permission to block ads.

I'm also looking forward to the merge of this PR.

I understand the motive, but what I don't understand is why they would still list (or not) "full network access" in the list of app permissions when that clearly doesn't matter at all.

I'm quite concerned about this; I will try rooting my GFs Android phone and install a firewall on there as well. The less they can snoop and send the snooping results home, the better.

@doodhout, unfortunately it's true. The official explanation for this is:

The question was brought up in the session on Android M Permissions at Google I/O 2015, during the Q&A portion of the talk. An attendee confirmed that there was no permission group for Internet, and went on to ask if absolutely any app could have access to the Internet. The session speaker, Ben Poiesz, gave affirmative responses to both questions and explained that the logic for this decision was based around the idea that if all of a user's data is protected by default, there's very little reason to be concerned that an app can communicate with the outside world.

but it's clearly done so don't disable the Internet permission to block ads.

I'm also looking forward to the merge of this PR.

I understand the motive, but what I don't understand is why they would still list (or not) "full network access" in the list of app permissions when that clearly doesn't matter at all.

I'm quite concerned about this; I will try rooting my GFs Android phone and install a firewall on there as well. The less they can snoop and send the snooping results home, the better.

@zoff99

This comment has been minimized.

Show comment
Hide comment
@zoff99

zoff99 Jul 14, 2016

i don't like that this app should now get XMPP.
why would you merge this?

just my 2 cents.

zoff99 commented Jul 14, 2016

i don't like that this app should now get XMPP.
why would you merge this?

just my 2 cents.

@doodhout

This comment has been minimized.

Show comment
Hide comment
@doodhout

doodhout Jul 14, 2016

@zoff99 Introducing federated or p2p XMPP (possibly through Tor) into this app lowers the amount of metadata (that makes you more likely to be personably identifiable) that third parties are able to gather from your communications.

@zoff99 Introducing federated or p2p XMPP (possibly through Tor) into this app lowers the amount of metadata (that makes you more likely to be personably identifiable) that third parties are able to gather from your communications.

@zoff99

This comment has been minimized.

Show comment
Hide comment
@zoff99

zoff99 Jul 14, 2016

but one app should do just 1 thing and do it good. and this app should do SMS (and maybe MMS) and nothing else.
said to see it go in another direction now ..

zoff99 commented Jul 14, 2016

but one app should do just 1 thing and do it good. and this app should do SMS (and maybe MMS) and nothing else.
said to see it go in another direction now ..

@doodhout

This comment has been minimized.

Show comment
Hide comment
@doodhout

doodhout Jul 14, 2016

@zoff99 The assignee @BastienLQ has stated in LibreSignal/LibreSignal#37 that he wants to incorporate crypto-XMPP-support into Silence because Silence offers a unique way of exchanging initial keys to start your secure chats: via SMS. Most other cryptochat apps do no offer this functionality.

You (or someone else) can always fork Silence (or maybe one of the current maintainers is willing to do so) to create a build that is free of anything XMPP related.

@zoff99 The assignee @BastienLQ has stated in LibreSignal/LibreSignal#37 that he wants to incorporate crypto-XMPP-support into Silence because Silence offers a unique way of exchanging initial keys to start your secure chats: via SMS. Most other cryptochat apps do no offer this functionality.

You (or someone else) can always fork Silence (or maybe one of the current maintainers is willing to do so) to create a build that is free of anything XMPP related.

@BLeQuerrec

This comment has been minimized.

Show comment
Hide comment
@BLeQuerrec

BLeQuerrec Jul 16, 2016

Member

To be clear:

  • This PR do not add new permission. Silence already have explicit INTERNET permission to be able to get MMS messages.
  • Silence will always be an SMS/MMS app. Removing SMS/MMS support would be a non-sense as Silence aims to replace the stock SMS app. Moreover, XMPP address exchange currently uses encrypted SMS messages; but this won't be the only way to exchange XMPP addresses.
  • XMPP messages won't be mandatory to use Silence or to chat with other Silence users.
  • This PR is not ready yet. The TODO-list in the description of this PR needs to be all-checked before merging.
Member

BLeQuerrec commented Jul 16, 2016

To be clear:

  • This PR do not add new permission. Silence already have explicit INTERNET permission to be able to get MMS messages.
  • Silence will always be an SMS/MMS app. Removing SMS/MMS support would be a non-sense as Silence aims to replace the stock SMS app. Moreover, XMPP address exchange currently uses encrypted SMS messages; but this won't be the only way to exchange XMPP addresses.
  • XMPP messages won't be mandatory to use Silence or to chat with other Silence users.
  • This PR is not ready yet. The TODO-list in the description of this PR needs to be all-checked before merging.
@IBPX

This comment has been minimized.

Show comment
Hide comment
@IBPX

IBPX Jul 20, 2016

Will XMPP use Axolotl, OTR, or some other form of encryption? Also, could it be possible to have a switch in settings that force-allows unencrypted XMPP messages, with a sort of "Warning, this is generally bad, do this at your own risk" sort of warning?

IBPX commented Jul 20, 2016

Will XMPP use Axolotl, OTR, or some other form of encryption? Also, could it be possible to have a switch in settings that force-allows unencrypted XMPP messages, with a sort of "Warning, this is generally bad, do this at your own risk" sort of warning?

@BLeQuerrec

This comment has been minimized.

Show comment
Hide comment
@BLeQuerrec

BLeQuerrec Jul 20, 2016

Member

@IBPX: XMPP messages are Axolotl encrypted. They use the same private key than in SMS/MMS messages. OMEMO would be great, but Smack, the library used to add XMPP capabilities, doesn't support it yet.

Unencrypted XMPP messages won't be included in Silence as it aims to fix the metadata issue in SMS messages: adding another vulnerability (clear messages) is not the right thing to do. Additionally, XMPP transport is designed to be used with Silence, so the recipient will always have encryption capabilities. If OMEMO is included, Silence users will be able to chat with other OMEMO clients and in that case they will also have encryption capabilities.

Member

BLeQuerrec commented Jul 20, 2016

@IBPX: XMPP messages are Axolotl encrypted. They use the same private key than in SMS/MMS messages. OMEMO would be great, but Smack, the library used to add XMPP capabilities, doesn't support it yet.

Unencrypted XMPP messages won't be included in Silence as it aims to fix the metadata issue in SMS messages: adding another vulnerability (clear messages) is not the right thing to do. Additionally, XMPP transport is designed to be used with Silence, so the recipient will always have encryption capabilities. If OMEMO is included, Silence users will be able to chat with other OMEMO clients and in that case they will also have encryption capabilities.

@IBPX

This comment has been minimized.

Show comment
Hide comment
@IBPX

IBPX Jul 20, 2016

@BastienLQ I feel it would be needed to have the ability to send cleartext messages (to say, communicate with a server admin who isn't using Axolotl or OMEMO), but hidden away in the settings somewhere that you would really have to know what you're doing.

IBPX commented Jul 20, 2016

@BastienLQ I feel it would be needed to have the ability to send cleartext messages (to say, communicate with a server admin who isn't using Axolotl or OMEMO), but hidden away in the settings somewhere that you would really have to know what you're doing.

@zoff99

This comment has been minimized.

Show comment
Hide comment
@zoff99

zoff99 Jul 20, 2016

this PR only makes sense if you do not need to register manually for XMPP. meaning you press a button in the app and totally automated an account is created for you and setup for you.
prefereably with a random user name (like is possible in Chatsecure now).

regular users will not be able to search for an XMPP service provider , register there and also put those values correctly into silence.

on the other hand, adding XMPP at all is really crazy. as you just sort of recreate "Signal". so users will go to the real thing, rather than use silence

zoff99 commented Jul 20, 2016

this PR only makes sense if you do not need to register manually for XMPP. meaning you press a button in the app and totally automated an account is created for you and setup for you.
prefereably with a random user name (like is possible in Chatsecure now).

regular users will not be able to search for an XMPP service provider , register there and also put those values correctly into silence.

on the other hand, adding XMPP at all is really crazy. as you just sort of recreate "Signal". so users will go to the real thing, rather than use silence

@IBPX

This comment has been minimized.

Show comment
Hide comment
@IBPX

IBPX Jul 21, 2016

@zoff99: Recreating Signal is kind of the point; more specifically, Signal without central servers.

IBPX commented Jul 21, 2016

@zoff99: Recreating Signal is kind of the point; more specifically, Signal without central servers.

@BLeQuerrec

This comment has been minimized.

Show comment
Hide comment
@BLeQuerrec

BLeQuerrec Jul 21, 2016

Member

@zoff99: This is exactly what the PR does: users just have to tap on a button to register an account on a random trusted server, with a random username and a random password. Everything is transparent for the user. And for techies, it's also possible to use a custom server (username and password are still generated randomly).

A trusted server is an XMPP server picked from a list in Silence (in src/org/smssecure/smssecure/util/XmppUtil.java). For testing only, xmpp.silence.im is put in that list, but we do not plan to maintain a server when this PR will be merged. I'm soliciting NGOs to ask them if they want to add their XMPP servers in the list (requirements are Roster and Stream Management support). For now, an organisation based in France is ready to add its server.

@IBPX: I definitely won't add clear XMPP messages, because of the points I developped and because this will require a lot of work for a small benefits.

@IBPX @zoff99: The goal of this PR isn't really to recreate a decentralized Signal. Signal devs point a real weakness of SMS messages (metadata leaks), but their conclusion (removing SMS support and to creating a centralized service that do not respect users' privacy) is wrong. This PR wants to add a new transport that solves the metadata problem; but I'm aware of new issues raised by XMPP messages (Internet connectivity required) and XMPP transport is not designed to replace SMS/MMS transport.

Member

BLeQuerrec commented Jul 21, 2016

@zoff99: This is exactly what the PR does: users just have to tap on a button to register an account on a random trusted server, with a random username and a random password. Everything is transparent for the user. And for techies, it's also possible to use a custom server (username and password are still generated randomly).

A trusted server is an XMPP server picked from a list in Silence (in src/org/smssecure/smssecure/util/XmppUtil.java). For testing only, xmpp.silence.im is put in that list, but we do not plan to maintain a server when this PR will be merged. I'm soliciting NGOs to ask them if they want to add their XMPP servers in the list (requirements are Roster and Stream Management support). For now, an organisation based in France is ready to add its server.

@IBPX: I definitely won't add clear XMPP messages, because of the points I developped and because this will require a lot of work for a small benefits.

@IBPX @zoff99: The goal of this PR isn't really to recreate a decentralized Signal. Signal devs point a real weakness of SMS messages (metadata leaks), but their conclusion (removing SMS support and to creating a centralized service that do not respect users' privacy) is wrong. This PR wants to add a new transport that solves the metadata problem; but I'm aware of new issues raised by XMPP messages (Internet connectivity required) and XMPP transport is not designed to replace SMS/MMS transport.

@IBPX

This comment has been minimized.

Show comment
Hide comment
@IBPX

IBPX Jul 21, 2016

@BastienLQ I have an existing XMPP account, will I be able to just log in with that?

IBPX commented Jul 21, 2016

@BastienLQ I have an existing XMPP account, will I be able to just log in with that?

@BLeQuerrec

This comment has been minimized.

Show comment
Hide comment
@BLeQuerrec

BLeQuerrec Jul 24, 2016

Member

@IBPX: I didn't implemented this and I probably won't do it: it avoids conflicts that may occur if the same account is shared between Silence and another IM app. So Silence will create a new account on custom servers too.

Member

BLeQuerrec commented Jul 24, 2016

@IBPX: I didn't implemented this and I probably won't do it: it avoids conflicts that may occur if the same account is shared between Silence and another IM app. So Silence will create a new account on custom servers too.

@IBPX

This comment has been minimized.

Show comment
Hide comment
@IBPX

IBPX Jul 24, 2016

@BastienLQ: What conflicts could possibly occur, if I'm using Silence as the sole XMPP app? Why not just allow a custom sign in for people who "know what they're doing"? What if you already had an account from Silence, but you lost your phone, and you'd like to sign into the existing account Silence made before?

IBPX commented Jul 24, 2016

@BastienLQ: What conflicts could possibly occur, if I'm using Silence as the sole XMPP app? Why not just allow a custom sign in for people who "know what they're doing"? What if you already had an account from Silence, but you lost your phone, and you'd like to sign into the existing account Silence made before?

@BLeQuerrec

This comment has been minimized.

Show comment
Hide comment
@BLeQuerrec

BLeQuerrec Jul 24, 2016

Member

@IBPX: XMPP protocol uses a resource name in addition to the XMPP address itself (ie blah-blah-blah@xmpp.silence.im/Silence). I can use the same JID with a different resource name (ie blah-blah-blah@xmpp.silence.im/SomethingElse), but each resource will have a different priority. If a user is connected to the same JID with 2 different resource names, the risk is to send messages from Silence to non-Silence clients and to receive non-Silence messages in Silence.

Member

BLeQuerrec commented Jul 24, 2016

@IBPX: XMPP protocol uses a resource name in addition to the XMPP address itself (ie blah-blah-blah@xmpp.silence.im/Silence). I can use the same JID with a different resource name (ie blah-blah-blah@xmpp.silence.im/SomethingElse), but each resource will have a different priority. If a user is connected to the same JID with 2 different resource names, the risk is to send messages from Silence to non-Silence clients and to receive non-Silence messages in Silence.

@IBPX

This comment has been minimized.

Show comment
Hide comment
@IBPX

IBPX Jul 24, 2016

@BastienLQ If I'm using a Silence as my only client, there will be only 1 resource, correct? If so, there would be no risk.

IBPX commented Jul 24, 2016

@BastienLQ If I'm using a Silence as my only client, there will be only 1 resource, correct? If so, there would be no risk.

@BLeQuerrec

This comment has been minimized.

Show comment
Hide comment
@BLeQuerrec

BLeQuerrec Jul 24, 2016

Member

@IBPX: Exactly, so in that case you can let Silence create the account for you. And if you lost your phone, you can recreate an account and resend the address to your friends (if the message is encrypted, the old address is replace by the new one transparently).

Member

BLeQuerrec commented Jul 24, 2016

@IBPX: Exactly, so in that case you can let Silence create the account for you. And if you lost your phone, you can recreate an account and resend the address to your friends (if the message is encrypted, the old address is replace by the new one transparently).

@IBPX

This comment has been minimized.

Show comment
Hide comment
@IBPX

IBPX Jul 24, 2016

@BastienLQ: I don't follow your line of reasoning. I meant, say, I used to use another XMPP client, and my address is ibpx@example.com. But now, I want to switch and use Silence as my client, and get rid of the other one. In this case, I would want to use my existing address, so my contacts don't have to re-add me. There is no risk in this case, so why couldn't I just keep my address?

IBPX commented Jul 24, 2016

@BastienLQ: I don't follow your line of reasoning. I meant, say, I used to use another XMPP client, and my address is ibpx@example.com. But now, I want to switch and use Silence as my client, and get rid of the other one. In this case, I would want to use my existing address, so my contacts don't have to re-add me. There is no risk in this case, so why couldn't I just keep my address?

@IBPX

This comment has been minimized.

Show comment
Hide comment
@IBPX

IBPX Jul 24, 2016

(also, ibpx@example.com is more convenient to tell people than qkvhwovjahehwjvjaw@example.com.)

IBPX commented Jul 24, 2016

(also, ibpx@example.com is more convenient to tell people than qkvhwovjahehwjvjaw@example.com.)

@BLeQuerrec

This comment has been minimized.

Show comment
Hide comment
@BLeQuerrec

BLeQuerrec Jul 24, 2016

Member

@IBPX: In that case, contacts won't be able to chat with you if they don't use Silence and don't have an encrypted session with you. So it's simpler to create a new account on your own server then send your new XMPP address using the build-in sharing mechanism.

Member

BLeQuerrec commented Jul 24, 2016

@IBPX: In that case, contacts won't be able to chat with you if they don't use Silence and don't have an encrypted session with you. So it's simpler to create a new account on your own server then send your new XMPP address using the build-in sharing mechanism.

@ArchangeGabriel

This comment has been minimized.

Show comment
Hide comment
@ArchangeGabriel

ArchangeGabriel Jul 26, 2016

@IBPX: I think that what you’re missing is that Silence isn’t going to be a conventional XMPP client. It will rather let you exchange encrypted messages using XMPP with your “Silence contacts”, i.e. those people in your phonebook that uses Silence too.

@IBPX: I think that what you’re missing is that Silence isn’t going to be a conventional XMPP client. It will rather let you exchange encrypted messages using XMPP with your “Silence contacts”, i.e. those people in your phonebook that uses Silence too.

@IBPX

This comment has been minimized.

Show comment
Hide comment
@IBPX

IBPX Jul 26, 2016

@ArchangeGabriel I don't see the benefit of this. This would essentially make it a walled off section away from the already established XMPP.

IBPX commented Jul 26, 2016

@ArchangeGabriel I don't see the benefit of this. This would essentially make it a walled off section away from the already established XMPP.

@doodhout

This comment has been minimized.

Show comment
Hide comment
@doodhout

doodhout Jul 27, 2016

@IBPX Walled off section away from XMPP, exactly! Just like SMS is. Think of this PR as a means to have walled of chatting based on telephone numbers as identification, but without the need to actually use SMS for that, although keeping (almost) all the benefits of SMS: federated, not in the hands of a private company (except for your SIM card and telephony provider, of course), etc.

@IBPX Walled off section away from XMPP, exactly! Just like SMS is. Think of this PR as a means to have walled of chatting based on telephone numbers as identification, but without the need to actually use SMS for that, although keeping (almost) all the benefits of SMS: federated, not in the hands of a private company (except for your SIM card and telephony provider, of course), etc.

@paride

This comment has been minimized.

Show comment
Hide comment
@paride

paride Dec 1, 2016

Will Silence automatically fallback from XMPP to SMS if the sender or the recipient are offline?

paride commented Dec 1, 2016

Will Silence automatically fallback from XMPP to SMS if the sender or the recipient are offline?

@BLeQuerrec

This comment has been minimized.

Show comment
Hide comment
@BLeQuerrec

BLeQuerrec Dec 1, 2016

Member

@legovini Yes, it will.

Member

BLeQuerrec commented Dec 1, 2016

@legovini Yes, it will.

@zoff99

This comment has been minimized.

Show comment
Hide comment
@zoff99

zoff99 Dec 1, 2016

will there be an option to avoid MMS at all cost?
because MMS here are super expensive, and you pay by kbyte.

so if you try to send a foto it should go XMPP -> stop (don't fall back to MMS ever)

zoff99 commented Dec 1, 2016

will there be an option to avoid MMS at all cost?
because MMS here are super expensive, and you pay by kbyte.

so if you try to send a foto it should go XMPP -> stop (don't fall back to MMS ever)

@johanw666

This comment has been minimized.

Show comment
Hide comment
@johanw666

johanw666 Dec 3, 2016

@zoff99 You can always use a stopgap to disable MMS by setting MMS override parameters and then setting them to incorrect values.

@zoff99 You can always use a stopgap to disable MMS by setting MMS override parameters and then setting them to incorrect values.

@paride

This comment has been minimized.

Show comment
Hide comment
@paride

paride Dec 3, 2016

@johanw666 that's not a good solution. I agree with @zoff99: it should be easy and straightforward to disable MMS sending altogether as it is normally very expensive, not considered in "all inclusive" plans, and in general it's not useful.

paride commented Dec 3, 2016

@johanw666 that's not a good solution. I agree with @zoff99: it should be easy and straightforward to disable MMS sending altogether as it is normally very expensive, not considered in "all inclusive" plans, and in general it's not useful.

@zoff99

This comment has been minimized.

Show comment
Hide comment
@zoff99

zoff99 Dec 3, 2016

it's really important to control (with an option) that MMS are never downloaded and never sent.
in europe MMS is the most expensive thing there is. even worse if you travel and should by accident send MMS when you are roaming.

zoff99 commented Dec 3, 2016

it's really important to control (with an option) that MMS are never downloaded and never sent.
in europe MMS is the most expensive thing there is. even worse if you travel and should by accident send MMS when you are roaming.

@gdt

This comment has been minimized.

Show comment
Hide comment
@gdt

gdt Dec 4, 2016

That's surprising about .eu and MMS (but I believe you). In the US, the normal plans have unlimited voice/text/mms and some amount, e.g. 2 GB, of data. Given that some get charged a lot for MMS, I agree it makes sense to have a first-class control to disable it. Also, there have been vulnerabilities in MMS parsing libraries before, so I can see people wanting to turn it off.

gdt commented Dec 4, 2016

That's surprising about .eu and MMS (but I believe you). In the US, the normal plans have unlimited voice/text/mms and some amount, e.g. 2 GB, of data. Given that some get charged a lot for MMS, I agree it makes sense to have a first-class control to disable it. Also, there have been vulnerabilities in MMS parsing libraries before, so I can see people wanting to turn it off.

@ArchangeGabriel

This comment has been minimized.

Show comment
Hide comment
@ArchangeGabriel

ArchangeGabriel Dec 4, 2016

It depends where in Europe, and even then it also depends on plans/carrier. Here in France, the most common (I think, no real data to back that) plans are like it is in the US: unlimited voice/text/mms and some amount of data (50 GB in mine for instance). But you also have cheaper plans with unlimited text, only some hours of voice and… no MMS.

It depends where in Europe, and even then it also depends on plans/carrier. Here in France, the most common (I think, no real data to back that) plans are like it is in the US: unlimited voice/text/mms and some amount of data (50 GB in mine for instance). But you also have cheaper plans with unlimited text, only some hours of voice and… no MMS.

@zoff99

This comment has been minimized.

Show comment
Hide comment
@zoff99

zoff99 Dec 4, 2016

best would be 3 radio buttons in settings:
[x] SMS
[x] XMPP
[ ] MMS

where the user can select which transports he wants. with sensible default values.
and make sure that disabled transports are never used.

zoff99 commented Dec 4, 2016

best would be 3 radio buttons in settings:
[x] SMS
[x] XMPP
[ ] MMS

where the user can select which transports he wants. with sensible default values.
and make sure that disabled transports are never used.

@TheCapsLock

This comment has been minimized.

Show comment
Hide comment
@TheCapsLock

TheCapsLock Dec 9, 2016

@legovini Yes, it will.

@BastienLQ is there an option to prevent this behaviour : eg. if having metadata protected is mandatory to me, can I prevent fallback to SMS ?

TheCapsLock commented Dec 9, 2016

@legovini Yes, it will.

@BastienLQ is there an option to prevent this behaviour : eg. if having metadata protected is mandatory to me, can I prevent fallback to SMS ?

@ghost ghost referenced this pull request Dec 26, 2016

Closed

include new Emojis #502

@BLeQuerrec BLeQuerrec added this to the v1.0 milestone Jan 7, 2017

@betsythefc

This comment has been minimized.

Show comment
Hide comment
@betsythefc

betsythefc Mar 29, 2017

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.

betsythefc commented Mar 29, 2017

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

This comment has been minimized.

Show comment
Hide comment
@BLeQuerrec

BLeQuerrec Mar 29, 2017

Member

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

Member

BLeQuerrec commented Mar 29, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@betsythefc

betsythefc Mar 29, 2017

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

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

@SkewedZeppelin

This comment has been minimized.

Show comment
Hide comment
@SkewedZeppelin

SkewedZeppelin Mar 29, 2017

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.

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

This comment has been minimized.

Show comment
Hide comment
@ArchangeGabriel

ArchangeGabriel Mar 29, 2017

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)?

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

This comment has been minimized.

Show comment
Hide comment
@BLeQuerrec

BLeQuerrec Mar 30, 2017

Member

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

BLeQuerrec commented Mar 30, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@eighthave

eighthave Mar 30, 2017

Contributor
Contributor

eighthave commented Mar 30, 2017

@zoff99

This comment has been minimized.

Show comment
Hide comment
@zoff99

zoff99 Mar 30, 2017

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

zoff99 commented Mar 30, 2017

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

@BLeQuerrec

This comment has been minimized.

Show comment
Hide comment
@BLeQuerrec

BLeQuerrec Mar 30, 2017

Member

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

Member

BLeQuerrec commented Mar 30, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@pR0Ps

pR0Ps Mar 31, 2017

Member

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.

Member

pR0Ps commented Mar 31, 2017

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

This comment has been minimized.

Show comment
Hide comment
@betsythefc

betsythefc Mar 31, 2017

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

This comment has been minimized.

Show comment
Hide comment
@pR0Ps

pR0Ps Apr 1, 2017

Member

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

Member

pR0Ps commented Apr 1, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@zoff99

zoff99 Apr 1, 2017

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.

zoff99 commented Apr 1, 2017

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

This comment has been minimized.

Show comment
Hide comment
@eighthave

eighthave Apr 1, 2017

Contributor
Contributor

eighthave commented Apr 1, 2017

@zoff99

This comment has been minimized.

Show comment
Hide comment
@zoff99

zoff99 Apr 2, 2017

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

zoff99 commented Apr 2, 2017

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

@pR0Ps

This comment has been minimized.

Show comment
Hide comment
@pR0Ps

pR0Ps Apr 2, 2017

Member

Please stay civil and on topic.

Member

pR0Ps commented Apr 2, 2017

Please stay civil and on topic.

@ArchangeGabriel

This comment has been minimized.

Show comment
Hide comment
@ArchangeGabriel

ArchangeGabriel Apr 4, 2017

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?

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

This comment has been minimized.

Show comment
Hide comment
@zoff99

zoff99 Apr 4, 2017

@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

zoff99 commented Apr 4, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@ArchangeGabriel

ArchangeGabriel Apr 4, 2017

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

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

@licaon-kter licaon-kter referenced this pull request in siacs/Conversations May 5, 2017

Closed

SMS/texting support #1906

@1xPdd

This comment has been minimized.

Show comment
Hide comment
@1xPdd

1xPdd Jul 9, 2017

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!

1xPdd commented Jul 9, 2017

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 rugk referenced this pull request Sep 17, 2017

Open

How is maintenance going? #612

@rugk

This comment has been minimized.

Show comment
Hide comment
@rugk

rugk Sep 17, 2017

Seeing the commit history, maybe better focus on the "core product". See #612 for my full statement.

rugk commented Sep 17, 2017

Seeing the commit history, maybe better focus on the "core product". See #612 for my full statement.

@licaon-kter licaon-kter referenced this pull request in siacs/Conversations Nov 2, 2017

Closed

Plugin Architecture #2674

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment