Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Feature/bug] Manually force SMS fallback #919

Closed
generalmanager opened this issue Mar 1, 2014 · 10 comments
Closed

[Feature/bug] Manually force SMS fallback #919

generalmanager opened this issue Mar 1, 2014 · 10 comments
Assignees
@mcginty

Comments

@generalmanager
Copy link

I just found the feature to manually send an unencrypted message (long press on the send icon), which I thought is what I wanted. Exept it isn't.
I'm not sure what this should accomplish, so I don't know if the behaviour is a bug or if I want a new feature.

This is what I want:
Case 1: I am in a data chat and have an internet connection

  • the mesage gets sent via sms
  • the message is encrypted

Case 2: I am in a data chat and turn wifi and mobile internet off

  • the message gets sent via SMS
  • the message is encrypted

Case 3: I am in an encrypted SMS chat

  • the message gets sent via SMS
  • the message is encrypted

Case 4: I am in an unencrypted SMS chat

  • the message gets sent via SMS
  • message is not encrypted

This is what I would expect from "send unencrypted message":
Case 1: I am in a data chat and have an internet connection

  • the mesage gets sent via data
  • message is not encrypted

Case 2: I am in a data chat and turn wifi and mobile internet off

  • the message gets sent via SMS
  • message is not encrypted

Case 3: I am in an encrypted SMS chat

  • the message gets sent via SMS
  • message is not encrypted

Case 4: I am in an unencrypted SMS chat

  • the message gets sent via SMS
  • message is not encrypted

That's how it "works", at least for me:
Case 1: I am in a data chat and have an internet connection

  • the message gets sent via data (I don't know it this should be happening)
  • message is encrypted (this should probably not happen)

Case 2: I am in a data chat and turn wifi and mobile internet off

  • the message gets sent via SMS
  • the message is not encrypted

I haven't tested case 3 and 4 yet (tell me if you want me to).

Is there any use in having this function? If so, could you quickly explain what it's supposed to do and why?
It doesn't really help if two people write via SMS and somehow the session gets messed up - you could just go ahead and end or renew the session via the lock in the top bar.

I would personally like to be able to manually force the use of SMS and several friends asked me if it's implemented already.
For most of them the usecase for that looks like this: The receiver turns off wifi and mobile internet to not be disturbed by instant messages or mails while doing important work. The expectation is, If somebody really needs to contact you, they'll either call or write a text message.
Many people I know use exactly this behaviour at work and others know that.
So when it's working hours, the other one doesn't immediately reply to your push messages, and you have to contact them, forcing TS to send an SMS is the next best option.
No need for TS to know if they are offline (#677, #678)
@L3st3r
Copy link

L3st3r commented Mar 2, 2014

For cases 2-4 the message will already be sent via SMS, won't it?
But in case 1 it would be a nice option to send just one message via SMS. Maybe this could be accomplished as a second option one gets when pressing long on the send icon.

@generalmanager
Copy link
Author

For cases 2-4 the message will already be sent via SMS, won't it?

yes but they are unencrypted. I want the same functionality as with the fallback function.

But in case 1 it would be a nice option to send just one message via SMS. Maybe this could be accomplished as a second option one gets when pressing long on the send icon.

We could do that, but I don't really see the point of sending an unencrypted data message or SMS.
If there is no real use case for the existing and broken "send unencrypted" function, we could just replace it.

@L3st3r
Copy link

L3st3r commented Mar 2, 2014

Ah ok, then I didn't really understand what you meant. I just wanted to say that the cases 2-4 of what you want are already the default behaviour, so we only need to care for the first case.

But I also can't think of an use case where one would need this function because it would be easier to just end the secure session. So I agree that it would make sense to replace this function with the "send via SMS"-option.

This was referenced Mar 2, 2014
Closed
Closed
Hellmy pushed a commit to Hellmy/TextSecure that referenced this issue Mar 9, 2014
- Fix signalapp#919 and addressing signalapp#671: Option to prefer pu…
3d22fd4 
…sh and a force send sms
Hellmy pushed a commit to Hellmy/TextSecure that referenced this issue Mar 10, 2014
- signalapp#919: Menu item to send a sms
49ed0b6
This was referenced Mar 11, 2014
Closed
Closed
@oiceberg
Copy link

Hi Buddies! My humble opinion about the question proposed in this topic. I read lots of issues and messages in the mailing list about it and related things, and I'm from the opinion that SMS channel is not a fallback: it's an alternative! The PUSH channel has pros and contras, and the same about SMS channel.

PUSH channel is great to whose who have data connects (Wi-Fi, 3G...) available and/or free, and do not care if the destinatary just will receive the message when he connects to Internet (if he connects!). SMS channel is great to whose who have plans in which it's cheaper to use SMS than 3G, and prioritizes the delivery speed. Both channels support encrypted messages. One is not better than the other. Originally, you know, TextSecure was a SMS great client before to be, too, a PUSH great messenger.

So, I would like to reinforce the proposal that when both channels are available to be chosen (it means: both are TextSecure users with PUSH mode on), the choice should be given in each message to the user. It is the user who knows his haste and urgency, and if is better to him to burn megabytes on 3G or burn a SMS.

Currently, TextSecure just offers two ways to send PUSH and SMS: to send PUSH, the sender has to be online in that moment; to send SMS, the sender has to be offline in that moment. However, it should not be a problem to send a PUSH when the mobile is offline (every normal WhatsApp or Telegram user knows what happens: the message just will be sent when he connects to Internet and just will be delivered when the destinatary connects too), and should not be a problem to send a SMS when the mobile is online.

My 2 cents Buddies!
It never hurts to say that TextSecure is really great!
Congrats and thanks a lot for all the work!
Hugs!

@generalmanager
Copy link
Author

@Hellmy already introduced a PR to implement this:
#1116

@oiceberg oiceberg mentioned this issue Mar 17, 2014
Closed
@generalmanager generalmanager mentioned this issue Mar 23, 2014
Closed
Hellmy pushed a commit to Hellmy/TextSecure that referenced this issue Apr 11, 2014
- signalapp#919: Menu item to send a sms
d296aaf
Hellmy pushed a commit to Hellmy/TextSecure that referenced this issue Apr 11, 2014
- signalapp#919: Menu item to send a sms
631e2dd 
- "Send unencrypted" forces a unencrypted sms
Hellmy pushed a commit to Hellmy/TextSecure that referenced this issue Apr 11, 2014
Squashed commit of the following:
88926a6 
commit f0356de8686bf67b938722c97dd7326f4f536ed3
Merge: 3c0a910 3300058
Author: Manuel <manuel@zeunerds.de>
Date:   Tue Mar 25 13:48:49 2014 +0100

    - "Send unencrypted" forces a unencrypted sms

commit 3300058
Author: Jake McGinty <me@jake.su>
Date:   Tue Mar 25 03:31:44 2014 -0700

    one more try at that one..
    // FREEBIE

commit e651f35
Author: Jake McGinty <me@jake.su>
Date:   Mon Mar 24 17:02:39 2014 -0700

    fix NPE in isPushDestination
    // FREEBIE

commit ccc1f5e
Author: martinstingl <martinstingl@gmail.com>
Date:   Sat Mar 15 21:51:49 2014 +0100

    Added the dependency "Android SDK Build-tools".
    //FREEBIE

commit b860aef
Author: Moxie Marlinspike <moxie@thoughtcrime.org>
Date:   Sun Mar 16 14:36:21 2014 -0700

    Minor ConversationList scrolling optimization.

commit 34c885f
Author: Martin Ranta <martinranta@users.noreply.github.com>
Date:   Sat Mar 15 17:58:10 2014 +0200

    Fixed a few localization names.

commit 71ab6f5
Merge: 8b21f3f 61fbf38
Author: Moxie Marlinspike <moxie@thoughtcrime.org>
Date:   Sun Mar 16 10:02:59 2014 -0700

    Merge pull request signalapp#1178 from backspace/extract-input-settings-string

    Extract Input Settings preference header string.

commit 61fbf38
Author: Buck Doyle <buck.doyle@gmail.com>
Date:   Sat Mar 15 22:18:14 2014 -0400

    Extract Input Settings preference header string.

    Fixes signalapp#1159

    FREEBIE

commit 3c0a910f3f0e13937680433dd6f5b1c119dc094d
Merge: 4923c0b 9385454
Author: Manuel <manuel@zeunerds.de>
Date:   Fri Mar 14 21:43:42 2014 +0100

    Merged mcginty sent-sms changes and updated to master

    Merge remote-tracking branch 'remotes/upstream/master' into send_sms

    Conflicts:
    	src/org/thoughtcrime/securesms/database/model/MessageRecord.java

commit 8b21f3f
Author: Moxie Marlinspike <moxie@thoughtcrime.org>
Date:   Fri Mar 14 10:18:13 2014 -0700

    Bump version to 2.0.5

commit 941d008
Author: Moxie Marlinspike <moxie@thoughtcrime.org>
Date:   Fri Mar 14 09:40:58 2014 -0700

    Add languages to selector

commit 8b8c6dd
Author: Moxie Marlinspike <moxie@thoughtcrime.org>
Date:   Fri Mar 14 09:28:50 2014 -0700

    Updated translations
    //FREEBIE

commit 9385454
Merge: 4701e59 d827ab1
Author: Jake McGinty <me@jake.su>
Date:   Thu Mar 13 21:03:02 2014 -0700

    Merge pull request signalapp#984 from mcginty/sms-prefs

    more precise sms controls

commit d827ab1
Author: Jake McGinty <me@jake.su>
Date:   Sat Mar 1 14:17:55 2014 -0800

    more precise sms controls
    // FREEBIE

commit 4701e59
Merge: 2b2da84 f51989b
Author: Jake McGinty <me@jake.su>
Date:   Thu Mar 13 13:05:56 2014 -0700

    Merge pull request signalapp#1076 from phenx-de/fix-big-fontsize

    Fix conversation list view for larger text sizes.

commit 2b2da84
Merge: 6471177 d229a42
Author: Moxie Marlinspike <moxie@thoughtcrime.org>
Date:   Wed Mar 12 18:58:08 2014 -0700

    Merge pull request signalapp#1140 from psm14/bugs/group_mms_local_number

    Also check cc for duplicates in group MMS

commit d229a42
Author: Pat McLaughlin <me@patmclaughl.in>
Date:   Wed Mar 12 20:45:21 2014 -0400

    Also check cc for duplicates

commit 6471177
Author: 3xo <xlmullalx@gmail.com>
Date:   Tue Mar 11 18:47:35 2014 +0100

    Fix locale when using country codes.

commit ad54d2a
Author: Moxie Marlinspike <moxie@thoughtcrime.org>
Date:   Wed Mar 12 09:57:12 2014 -0700

    Modify string tag.
    //FREEBIE

commit 068c403
Author: Wikinaut <mail@wikinaut.de>
Date:   Thu Mar 6 00:07:59 2014 +0100

    added Google Play Store text

commit 11cfc4f
Author: Jake McGinty <me@jake.su>
Date:   Tue Mar 11 01:05:24 2014 -0700

    upgrade gradle version
    // FREEBIE

commit 4923c0ba9ea3c0fd0387fdce5e845710980b92ee
Merge: 49ed0b6 a8f3df7
Author: Manuel <manuel@zeunerds.de>
Date:   Mon Mar 10 18:28:08 2014 +0100

    Merge branch 'send_sms' of github.com:Hellmy/TextSecure into send_sms

commit 49ed0b6
Author: Manuel <manuel@zeunerds.de>
Date:   Sun Mar 9 19:46:07 2014 +0100

    - signalapp#919: Menu item to send a sms

commit a8f3df7e300a00a3644409a127ecb57f42e6bdff
Author: Manuel <manuel@zeunerds.de>
Date:   Sun Mar 9 19:46:07 2014 +0100

    - signalapp#919: Menu item to send a sms

commit f51989b
Author: phenx-de <eiko.wagenknecht@web.de>
Date:   Mon Mar 10 10:32:32 2014 +0100

    Fix conversation list view for larger text sizes.
Hellmy pushed a commit to Hellmy/TextSecure that referenced this issue Apr 11, 2014
- "Send unencrypted" forces a unencrypted sms
7e85f6b 
- signalapp#919: Menu item to send a sms
@floetenpiet
Copy link

Another usecase for "always force sms with this contact" (I have already experienced): Another textsecure user uninstalls Textsecure/gets his phone stolen/breaks his phone WITHOUT unregistering push (and doesn't bother using the ways provided). In order to send him a text message (SMS), I either have to disable Textsecure as standard sms app manually or unregister from push, disable encrypted conversation with this very contact an afterwards register push again. Such a hassle.
In these cases, I would like to have an option to either 'always force unencrypted sms' for a specific contact or another way to (a little dirty) "phone, please forget that this user has whisperpush registered".
To merge this issue, #1116, #1223 and #984, an implementation of a 'multi layer solution' seems desirable:

  • global: default conversation style priority (as already implemented), maybe even extended to "data/push encrypted", "data/push unencrypted", "sms encrypted", "sms unencrypted". This would be against moxies comment in Can't send unencrypted  #619 ("push ALWAYS encrypted"). So "data/push encrypted" and "data/push unencrypted" could be merged to "data/push (always encrypted)"
  • user specific (long press userchat OR userchat menutab): if default/global way not desired, define user specific default (consider this in appearance of SEND-arrow)
  • long press send: dropdown menu: choose for ONE TIME delivery: "data/push encrypted", "data/push unencrypted", "sms encrypted", "sms unencrypted". This range of choices should / should not (I am not sure) depend on the global "push available", "sms available" menu entries already available. This dropdown menu could be configured in global options. Then, if only 1 option remained, the longress should instantly work as this 1 option. Seems complicated, but I think, this improved usability a lot regarding using Textsecure as your fully customizable standard messaging-app with other Textsecure users, Cyanogenmod Users, FORMER , but still registered users of both, IOS users, "normal" contacts.
    Keep on your great work! (I'm not that deep into programming, otherwise I would participate)

@generalmanager
Copy link
Author

@floetenpiet I don't think this would be the proper way to do this.
Did you see this: #1049 ?

@floetenpiet
Copy link

@generalmanager No, but I've read it now. Ok, then I'll have to wait for these: #1049, #619

@generalmanager
Copy link
Author

@Hellmy already programmed the functionality I asked for in this issue, it just has to get merged: #1116

This was referenced Apr 16, 2014
Closed
Closed
@generalmanager generalmanager mentioned this issue Jun 12, 2014
Closed
@generalmanager
Copy link
Author

I'm going to close this, as #1116 just got merged.

@generalmanager generalmanager mentioned this issue Jun 21, 2014
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mcginty mcginty

Labels
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@mcginty @oiceberg @generalmanager @L3st3r @floetenpiet