SMS fallback behaviour when other directory users are offline

[punnie]

Tried this with a friend:

• Both registered in the directory so we could exchange messages through PUSH
• Successfully sent each other messages
• Friend goes offline
• All messages sent hold until friend goes online again

Shouldn't the SMS fallback be kicking in in this type of situations? Is this expected behaviour? Wouldn't it be better if TextSecure noticed friend is offline and prompted me if I wanted to send an (presumably) instant SMS instead?

Cheers.

[virtualritz]

I agree, this use case needs a better solution. Related to #671.

[fwalch]

Duplicate of #677.

[moxie0]

The concept of "online" doesn't really exist in an asynchronous world. The only thing we know is whether the sending device has network connectivity at the moment a message is sent. Beyond that, the push framework tells us nothing about delivery. This is also how iMessage works, and they have much better control over their push framework than we do.

I think the best we can do here is to provide a "delivery confirmation" indicator so that the sender knows whether a message has reached the remote device or not.

[punnie]

That's unfortunate. People have different expectations when using different transports to deliver their messages. I, for one, expect an SMS to be delivered even if the destination is abroad on a trip, deprived of a mobile data connection. If TextSecure, which is my default SMS app, doesn't at least alert me if the message isn't delivered in a defined time window, I'd rather use it for WhisperPush messages only.

Delivery confirmation is good, but TextSecure also needs a mechanism to manually switch to the SMS transport when deliveries don't happen.

Of course a delivery failure notification would be best, but it's understandable it can't happen when that's part of a system TextSecure doesn't control.

[generalmanager]

I would also love 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 either call you or write you a text message. Many people I know use exactly this behaviour at work and others know that. So when it's working hours and the other one doesn't immeadiatly reply to your push message, 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.

[peti]

I think the best we can do here is to provide a "delivery confirmation" indicator so that the sender knows whether a message has reached the remote device or not.

If delivery confirmations (https://github.com/WhisperSystems/TextSecure/issues/957) were available, then TS could easily solve this issue:

1. Push the message.
2. If delivery confirmation doesn't arrive within x seconds, send the message via SMS.
3. If a PUSH message is received that is identical to one received via SMS earlier, ignore it.

In any case, it should be possible for users to configure on a per-recipient basis whether PUSH or SMS should be preferred. (And it should be possible to have Tasker or SecureSettings manipulate those settings for scripting purposes.)

[punnie]

In my opinion, it would be best if the fallback wasn’t automatic. An alert in the notification area prompting the user if he would wish to re-send the message via SMS would suffice, and would possibly avoid SMS charges in cases where the user doesn't notice the automatic fallback behaviour.

+1 on the per-recipient basis control.

--  Pedro Coelho http://pedrocoelho.pt

On 3 Mar 2014 at 19:02:42, Peter Simons (notifications@github.com) wrote:

I think the best we can do here is to provide a "delivery confirmation" indicator so that the sender knows whether a message has reached the remote device or not.

If delivery confirmations (#957) were available, then TS could easily solve this issue:

Push the message. If delivery confirmation doesn't arrive within x seconds, send the message via SMS. If a PUSH message is received that is identical to one received via SMS earlier, ignore it. In any case, it should be possible for users to configure on a per-recipient basis whether PUSH or SMS should be preferred. (And it should be possible to have Tasker or SecureSettings manipulate those settings for scripting purposes.)

— Reply to this email directly or view it on GitHub.

[donjoe0]

+1 on fallback not being automatic. It's something that depends on the situation, therefore I'd like a "Proceed via SMS"/"Try again later" popup every time (with "later" to be defined somewhere in the settings).

[peti]

Personally, I would like to be able to choose whether the application falls back to SMS automatically or not, and I'd like to make that choice per recipient.

[amigthea]

Agree, the perfect option would be:

1) I want to send an sms message and choose this communication channel by long-press the send icon; this will be the next preferred (or forced due to missing data connection as now is) channel until further changes

2) i receive a message via sms in a data conversation and a pop-up show up warning me and asking if i want to switch to sms as preferred channel until further changes (like my friend start again to use data connection)

[mreppen]

If delivery confirmation doesn't arrive within x seconds, send the message via SMS.

Remember that an iOS app would not be able to confirm delivery unless the app has been active very recently. Therefore most messages to such devices would be sent as SMSes as well.

[makubi]

I don't like the idea of automatically falling back to SMS, because I've got many contacts that live in foreign countries. So I would make this optional in any case.

What about ack-ing every message? Couldn't we push that too? And try to re-send it periodically?

[oiceberg]

Hi Buddies! I already studied these issues about SMS x PUSH channels: #625, #671, #677, #678, #697, #699, #910, #919, #940, #984, #1065, #1066, #1116, #1144, #1155, #1129. Above @moxie presented a solution that, combined with the alternative (not present yet) to the TextSecure user (sender) choose to send a PUSH or a SMS message, would resolve as a charm the problem presented in this issue, I guess.

See, if the message is sent over PUSH, and the sender could know that the message was sent to the cloud (one check) but, passed some time, it already was not sent to the receiver (double check), it should be the user, himself, who would choose to send another message over SMS, or even just wait. The reciprocal is true: the user may have sent a SMS that was lost forever in the telcom operator cloud and, passed some time without the confirmation of deliered, choosed to use a more trustable channel (despite the dependence of Internet connection available to both sides) with respect to the certainty that the message will be properly delivered some time, even if just some day in the future, and that the one check and double check confirming the status of the message really works.

So, I know that it's impossible in this stage of the game, to change the conception embedded in TextSecure v2 that the SMS is a fallback, a degradation, instead of an alternative with its pros and contras, and with the great pro that it don't depends that the receiver be connected to Internet just now to receive a message. There are users that would like to renegate WhatsApp and Telegram, only. There are users that would like to change SMS encrypted and use TextSecure as it SMS default client. There are users (my case!) that want both!

Thereby, I think it's not a good idea to establish a priorization of channels (PUSH is better than SMS in which cases, by the way? ;), and that the user should, himself, to choose in real time, as each particular case of his everyday life, to choose which channel is more appropriate to be used: SMS or PUSH. Dozens of combinable variables can change it for each user.

I could list dozens of use cases where it's better to send SMS than PUSH, and vice versa, and try to demonstrate that the choice should be equally available to the user, and not the widely proposed formula "TS try to send first over PUSH and, if some predetermined criteria happens, then TS send over SMS".

Proposal: the one check and two checks solution to inform that a message was sent to the cloud (Internet or SMS Network) and then delivered (or not!), both to PUSH and SMS messages, added a way to easily choose the channel to send the messages, should easily resolve all these issues, I guess, independently of the user origin: Internet messengers world, or SMS world. It would be very usefull for both, apart from that it would be an innovation if compared to what all the other apps do! =)

Do we have consensus about it? If not, I would be very grateful to know different ideas of mine.

My 2 cents Guys! By the way: thanks for all the great job! Hugs!

[generalmanager]

@leandrosalvador I am all for PUSH as the preferred transport. There are some legitimate usecases for SMS, but there is a reason why WhatsApp alone sends more messages a day than all SMS are sent by all carrieres worldwide. Those are just the most important ones:

• They aren't free in many parts of the world, e.g. Europe, Asia and South America.
• They can't transfer images, videos or arbitrary files (MMS are humongously expensive)
• They suck for group chats (MMS costs apply again)
• They leak metadata to the carriers (see #838 )

Because SMS are sometimes preferable over push messages, I opened #919. If someone has free SMS and doesn't want to use the data channel for whatever reason he can turn it off.

If the improvements to the data channel to remedy the "receiver offline" case discussed here are implemented, I see absolutely no reason to show SMS as an equal choice to push.

I have never ever heard from anybody who wanted to always choose the transport for each message with both options there. And even then, #919 solves this with one long click on the send symbol.

To add another button or something like that simply clutters the UI and unnecessarily confuses people. That should be avoided at all cost.

[oiceberg]

@generalmanager, thanks for your fast answer guy! I accept your assumptions, and particularly, I also would prefer PUSH than SMS in every cases that (i) I can assegure that the message is properly delivered (double checked available) or (ii) I'm not worried about if the message will arrive instantly to the receiver. The soluction proposed in #919 (long press on the send icon) would be good enough in my opinion, specially because it treats the choice contextually, to each message, and not to the entire application.

Actually, as you know, the long press on the send icon opens a pop-up with the "Send unencrypted" option which, once clicked, doesn't do what it would be supposed to do: in fact, it sends an encrypted message via PUSH channel.

I think the correct option should be "Send encrypted SMS", considering the fact that this option is just available between TextSecure users with PUSH mode on, don't you agree?

[generalmanager]

@leandrosalvador

I think the correct option should be "Send encrypted SMS", considering the fact that this option is just available between TextSecure users with PUSH mode on, don't you agree?

Yep, that's why I created #919, where I root for this exact behaviour.

[makubi]

I fully agree with @generalmanager .

Sending SMS would be too expensive in my case, not even thinking about MMS. Normally, I also like to fine-tune every part of my applications, but this would not target the masses (which is what we should do). Maybe there are solutions to support both, like an "export mode" or something in the future, but keeping the UI as simple as possible is way more important.

I think the only important feature that is currently missing is a delivery confirmation, like @moxie0 mentioned before + an automatic delivery as soon as the recipient is reachable again.

[oiceberg]

Aloha @makubi! Thanks for interact! I understant that in your cases, makes sense to prefer send messages via data channel than via SMS channel and, consequently, you would choose to prioritize DATA than SMS in architectural choices about the TextSecure course. However, this is not the same case everywhere in the world. In Brazil, for example, it is most common to find free SMS packages available, than hiring data plans.

My consideration just want to put on the table that what is a reality for some persons is not necessarily a reality for all people around the world. I personally, prefer to use DATA channel than SMS, but 98% of my contacts in Brazil don't use TextSecure, 70% not use even WhatsApp, but everybody uses SMS as a reliable mechanism for instant communication.

It is because I ask all of you that not degrade the SMS over the DATA channel. In Brazil an SMS costs around USD 0.02, to give you an idea, and 3G really sucks yet, besides costing super expensive.

I believe that in Brazil will be easier to bring users to the TextSecure as an excellent SMS client that allow encrypted SMS, than as a substitute for WhatsApp for now, and I'm an advocate in favor of using the TextSecure in my circles.

An ordinary postpaid combo of voice + data + SMS in Brazil (for example, Vivo operator), costs about BRA 115 (USD 50), which offers: 60 minutes to others operators + 1GB over 3G + unlimited SMS (to any operator). Check yourselves if you want, ok? =) http://goo.gl/La1gzq

An ordinary prepaid combo, on the other hand, costs about BRA 28 (USD 12), which offers: zero minutes to others operators + 300MB over 3G + unlimited SMS (or BRA 0,05 = USD 0,02 to other operators). It's available to be checked at http://vivotudo.com.br/ ok? :)

Really: SMS pump some places in the world! Data channel is very expensive and slow in Brazil, not worth.

Hugs!

[Prillan]

To complement what @leandrosalvador said. Here in Sweden we have pretty much the same plans as his first example. I believe that most people still use SMS over the different data based IM apps. I might be wrong though, it might depend on the age of the users. If someone could help me verify that it'd be great!

On another note, I always turn off data on my phone to save battery (2 days -> 5-6 days), so a per contact option for my friends to choose SMS when messaging me would be great.

[chuegel]

Well, here in Germany it´s the other way ´round. SMS are more expensive (1 SMS= 9 ct) then a mobile data flat..so the option "Allow outgoing SMS to ->Non-TS users" is more then welcome.

[oiceberg]

Hey Guys! By the way, I was not sure if should open a new issue or deepen this, so I opened the #1207 describing what I think be a severe malfunction in the SMS fallback behaviour. If you could reproduce that in your phones, maybe it would be easier we try to figure out how to prevent others less geeks potential users having a bad experience with TextSecure when denying the SMS fallback.

There is one detailed step by step describing how to do it. Not to mention that we still can not send SMS when online. I would like to help coding a soluction, but I'm rusty and do not even know how to start, for now.

[SanderGit]

The solution from @Azertooth would work for me. I (Alice, online) receive an encrypted SMS from Bob (abroad, offline). I reply, and TS chooses Push. The message is not delivered. I have to switch off my data and wifi (offline now) to force SMS fallback.

If an SMS is received it's for a reason and TS should use that channel within the conversation until a push message is received again.

[d-3-n]

Only thing we need is an option to choose to send an SMS, instead of push. It is stupid that application which asks to be one's default SMS app, cannot send SMS. I know one can deactivate push, but this can cause additional problem, with new keys being generated. Although this (deactivating push, using SMS) is the only, according to my experience also much more reliable option, for me at the moment.

What Azertooth said would be nice. Only difference is that IMO it would be better to be able to set preffered communication channel per conntact. Also when one gets an SMS, why not automatically switching to that? That is a good indicator that another side doesn't have internet connection.

[oiceberg]

I made some tests sending messages for other TS users, either (me) online and offline. Apparently, there is some queue problem when I am offline. Take a look, please:

(Consider that "Teste" is the same than "Test".)

+

How you can see, (i) the 'Tap for SMS fallback' feature didn't appear and (ii) the messages "Test 8 online" and "Test 9 online" were not sent, even being online when it was sent.

So, I was online and restarted TextSecure (reinforcing: online):

+

How you can see, (i) the messages were sent via PUSH channel (blue balloon), except the message "Test 2 offline", which was the first message in the queue of messages sent offline.

One more sequence of tests were sent, from "Test A" to "Test E", take a look:

And now, online, I restarted TextSecure one more time (reinforcing: online):

So, the same strange thing that already had happened with "Test 2 offline", also happened with "Test B offline": it was the first message of the offline queue, and exactly it has not been sent.

The above tests were with my purple friend. Now I included my orange friend in the battery tests.

Between "Test 1 online" and "Test 2 online after tests" (orange friend), I sent some of the messages to my purple friend. So, it was possible to reproduce the same problem here, because instead of the messages "Test 3 offline" and "Test 4 offline" wake the option 'Tap for SMS fallback', it also stayed as PENDING. Strange, no?

So, with all these messages in the queue, and yet no restarting TextSecure, I sent an online message to my red friend, which instead of being sent, it was PENDING:

So, I started a third battery of tests to my purple friend. The first was "Test W online", which despite being online, was PENDING. So I decided to disconnect me and go offline. And then immediately restarted TextSecure. Guess what happened (reinforcing: offline):

Wow! The 'Tap for SMS fallback' woke up for every queue (PENDING) messages, even for the orange friend's queued messages:

Restarting TextSecure offline resulted in 'Tap for SMS fallback' revival and 'Failed to deliver message' notification:

The following screenshots just confirms the logic described above:

Synthesis: the first message of a queue of PENDING messages is not sent, even if TextSecure is restarted, whether online or offline. The 'Tap for SMS fallback' just is activated as a feature if TextSecure is restarted with the mobile offline. If the mobile is restarted online, the messages are sent via PUSH channel automatically.

By the way, the long press option 'Send unencrypted' does not work anyway. As suggested in other issues, it could be modified to 'Send SMS' (encrypted, by the way!).

This report was giant, I know, but it was the best I could do to describe in detail the perceived problem. I wish to contribute to improving the experience of using the TextSecure.

[schlm3]

This issue really is a showstopper. I use short messages if I like to reach someone at time of writing. If the message I write is not supposed to be delivered/read immediately, I rather use EMail. Even if TextSecure is designed to work asynchronously, the mass of people using it use it because they expect some kind of "immediate" delivery. If TextSecure is not able to handle this case (sender online, receiver offline), it's useless for me.

[generalmanager]

@schlm3 there is a merged pull request that will add the ability to manually force an SMS, which you can use as a workaround (after the next version is published) until reception notifications + (semi-)automated resending of messages are supported. https://github.com/WhisperSystems/TextSecure/pull/1116

[rfugger]

I agree with @schlm3. I just want my message to be delivered ASAP, and I don't care how. To that end, I would be happy with either:

• My message is sent by both PUSH and SMS simultaneously, and only displayed once at the recipient.

OR

• My message is tried on one channel, and retried on the other in short order if delivery hasn't succeeded yet on the first channel.

Obviously this would need to be configurable behaviour for people who can't or prefer not to use one channel or another.

[nanocat-net]

+1 to better control over sending channels, please. I want to use this as my instant messaging client, which means I want my messages to get there straight away. Since I have changed my default messaging app to textsecure, I cannot easily revert to using the Messages app.

That means that if I'm online, and my textsecure-using friend is currently offline (but has access to sms), the only way I can currently get them a message is to go offline myself - THEN the client seems to flip to SMS mode.

For some reason, when I sent messages using data, I did not get a "delivery failed" message and an option to revert to SMS - and in fact, I can't seem to discover whether my message has been delivered at all. I see a "Message sent/received" date and time, but this is a bit ambiguous :-)

Could someone point me at an FAQ or a document about why this is so? Is it by design? Is it for security?

[georg-h]

@grooverboy : first see the 4. post in this thread (from @moxie0 ) and 2. check out http://support.whispersystems.org/customer/portal/questions/5987921-how-textsecure-decides-when-to-send-sms-vs-push and http://support.whispersystems.org/customer/portal/articles/1535899-why-don-t-you-add-several-additional-options-to-control-when-sms-fallback-happens- and http://support.whispersystems.org/customer/portal/questions/6421251-suggestion-sms-vs-push-workaround

[nanocat-net]

@georg-h - thanks for your reply! Seems that a lot of thought is going into it. I guess the best thing to do (until an update) for a user who wants encryption and SMS-style "instant" messaging BUT who has no data plan and only connects while on WiFi, is to deregister from Push messaging to have textsecure to use SMS only.

Data leakage inherent with SMS noted.

[d-3-n]

@georg-h - Second and third links are very poor answers IMO, especially if they want to enlarge their user base, and, as strangely stated, they want to stop confusing their users.

They should at least stop offering an option to set Text Secure as a default SMS applicatin, because it is a poor one (for a normal Joe user.).

The scenario where data connection is not available temporarily is too common, happens very often, and users don't want to wait for a connection to come back to be able to deliver a 'send me a shoping list!' like messages, where they really don't care about metadata so much.

They shouldn't use Text Secure then? Well, they won't, and that's my point.

If you care about users you don't won't to confuse, remove 'set as default messaging app' option, and promote it as a secure encrypted chat application.

[SanderGit]

I still value the comment from @Azertooth very attractive: https://github.com/WhisperSystems/TextSecure/issues/678#issuecomment-36778920 Use case: Alice sends a push message to Bob that her plane is leaving. When she arrives at her destination, in a different country, she does not have a data connection so she (automatically) sends an SMS message to Bob that her plane has landed safely. Bob immediately replies, but this goes via push because he does not know he has to switch off his own data connection for the message to reach Alice via SMS. Alice will eventually get the message when she's in the hotel and has connected to the wifi.

There are places in the world when a (data) subscription to a phone carrier is not valid for cities that are 200 miles apart.

[d-3-n]

@SanderGit there are lot of possible scenarios, and in all of them people count on SMS to work reliable (ok, this is country/provider depended.) and per SMS one has ability to get a delivery reports. With push one doesn't receive any kind of feedback. Let's say one sends a message with push on, to a friend, and doesn't get any response. Now he could assume friend read it, but don't have time to answer, or that he is actually on business trip/vacation and that he doesn't use roaming for internet connection. Well, now one could either switch to a different communication method, or send a message from another SMS app to tell the friend he should disable push, or he won't be able to receive messages, including very important / urgent ones.

[oiceberg]

This thing (i) to disconnect the data to be able to send SMS and (ii) not be able to write a message offline and leave it as a pending PUSH to be sent when there is a data connection, I think, play against TextSecure while application to newbies. Only geeks know these pranks.

Although I'm trying to spread the TextSecure in my circles, is too complicated to maintain that it is a great app when these two very basic things are impossible and I have to explain that it is a bug for which there is no provision to be fixed.

[SanderGit]

@leandrosalvador @d-3-n I am afraid this is considered as planned behavior instead of as a bug. I will now need to tell my connections to not use TS. One of them just filed a complaint with his provider that messages sent from NL to DK were not received, not aware of the messages have been sent via Push because there is no 'send as SMS because I received the previous message via SMS?' question. I can no longer explain the behavior to non-geeks.

Using TS only for push is an option, but this introduces another issue: incoming encrypted SMS messages are then received in the wrong app. Also, there is then no easy way to use encrypted SMS - which imho would still be better than unencrypted SMS.

Being always online might be logical in the US but it is not in Europe. Also Europeans traveling to the US will not have their data connection open by default because they are charged $13 per MB.

[peti]

Personally, I've concluded long ago to simply disable the whole PUSH functionality and use only SMS delivery. This way, I can use SMS for messages that I want to reach their recipient as quickly as possible, and I send e-mail for messages where it's okay that they'll reach the recipient only whenever he's online. Without PUSH, TextSecure works really great.

[d-3-n]

@SanderGit I was aware they do not consider this as a bug. Also I myself am almost always online, except when on roaming, out of Austria, but communication includes other people too. And in my case they are also online most of the time. The point is that I don't want connection to work 'most of the time', but 'always'. Always means reliable at least as SMS service, people here are get used to, is. Unfortunately while I can count on sms to be delivered on time, and when not I am at least aware of it, I don't get any feedback from TS. And as you pointed out, most of other people I communicate with have no idea what is going on, or what are their options. Maybe a nice example is my communication with my wife. We both have connection 99% of time, and it is relatively the good one, provided by A1 in Austria /Vienna. Despite that I had to turn off push on her phone, because it simply didn't work reliable enough, plus it was leaving us with no feedback about what is going on. People (most of them IMO.) want they messages to be delivered on time (in next couple of minutes.) not in hour, and especially not in two, or five hours. Despite my complaining here, I must say that I very appreciate the work done by TS team.

[SanderGit]

The reason for my comments is to try to make TS better and discuss the direction where it's going. I also really appreciate the work done by the TS team.

@peti I also disabled Push for now, will encourage my contacts to do the same. Good suggestion.

[moxie0]

We're adding delivery receipts for push. The iOS version of TextSecure won't support encrypted SMS, however, since it's not possible on that platform, so this whole SMS fallback thing might not be in the cards. If anything, I'd like to get rid of encrypted SMS support in the Android client as well. The world is moving towards data-based messaging, and SMS really limits our abilities.

[d-3-n]

I am surprised that people interested in privacy&security use iOS. But why not... There are bunch of people, probably majority, who trust everyone and his black box when these are advertised with silly arrogant salesman's attitude and their buzzwords. And anyway it is not that situation is so great with Android/FF and Linux in geerral, but here I am using TS.

[peti]

@moxie0, how does SMS support limit your abilities?

[bvorak]

I'm really glad to hear about the efforts for delivery receipts for push. This is a must have because at thethe moment one just don't know if a Push massage was actually dilverd. How you are going to achieve it?

[moxie0]

@bvorak Make the send timestamp millis the message id, and when the app receives a message, just send a message back acknowledging receipt.

@peti In a thousand small ways, but mostly in how we have to design the UI. Right now we have the session sync problem totally solved in the push world, but we'll never be able to do that in the SMS world. Not to mention carrier quirks, size restrictions, and the horror that is MMS.

I think what this experience has taught me is that it's almost never worth trying to layer encryption onto an existing transport which you don't control, or which is possible for users to interact with from unparticipating clients. It's definitely useful to leverage an identifier from an existing communication network, but trying to use the actual transport will always result in confusion and a suboptimal UX.

[peti]

@moxie0, there is a need for encrypted SMS and there is a need for delivering short message over the data channel. TextSecure provides very reasonable solutions for both of these problems. However, it was probably a bad idea to try and solve both problems in the same application!

Instead of having one app do both of these (somewhat orthogonal) tasks, there should have been an "SMS encryption" app and a "Secure Push" app. This split would have greatly simplified your user interfaces, and it would have been much easier for users to understand the difference. As it is now, TextSecure is far too complicated. Even experienced users with a good background in crypto and networking cannot easily predict how the app is going to behave under certain circumstances, and this trait is quite undesirable for a program that's supposed to provide privacy and security.

[moxie0]

I actually think it's pretty simple: it tries to send a data message, and if it can't it sends an SMS. If you want, you can configure it not to send an SMS, or to ask you before sending the SMS.

To the extent that this is "complicated," it's that people want it to be complicated: they want it to send an SMS if the other person is not connected to data, or retry, or send an SMS if you've received an SMS within some timeout period. Or know that you're only connected to data on Tuesdays, or whatever. Personally, I'd prefer to remove SMS entirely rather than add more complexity, but those same people still won't be satisfied.

[nanocat-net]

On 25 May 2014, at 00:26, Moxie Marlinspike notifications@github.com wrote:

I actually think it's pretty simple: it tries to send a data message, and if it can't it sends an SMS. If you want, you can configure it not to send an SMS, or to ask you before sending the SMS.

This. Exactly.

To the extent that this is "complicated," it's that people want it to be complicated: they want it to send an SMS if the other person is not connected to data, or retry, or send an SMS if you've received an SMS within some timeout period. Or know that you're only connected to data on Tuesdays, or whatever. Personally, I'd prefer to remove SMS entirely rather than add more complexity, but those same people still won't be satisfied.

Well, point is I don’t want to have to care about whether my message got through.

Apple gets this completely right with iMessage. It always uses Push, unless the Push message doesn’t get acknowledged in a few seconds. There is one single option for this in the iPhone - “Use SMS if Push doesn’t work”, or words to that effect. That way I have control over SMS charges. That’s pretty simple. It’s exactly what you described above.

I understand that TextSecure can’t send SMS on IOS devices, but it can with Androids.

Since one person I communicate with a lot uses an Android phone with no data, just wifi, I want the feature. I can see I’m not alone :)

I think the killer aspect of TextSecure is exactly this - you can use it as a drop in replacement for the SMS app. That is awesome and should be leveraged, IMHO :-)

N

[bungabunga]

@moxie0 yes, the world is moving towards data-based messaging, but (as always) we'll not all get there at the same time. and with getting rid of encrypted SMS i'm affraid many of us that enjoyed the privacy of TextSecure will be left alone bare-naked in front of the gradually increasing surveillence state.

however strongly i'd want it, at the moment there's just no way that most of the people that i have encrypted communication with will be "online" data-wise just as they are SMS-wise. and even if they were, traveling to another country in europe still means data-off.

sadly, SMS communication will remain the most robust way of quickly and surely getting information to people for some time in the future. so, why also not the most private way?

while i know that this SMS/data issue is really giving you grey hair, please just consider the reality that we're living in and the need we have.

[d-3-n]

@moxie0 it is quite normal to have people who are not satisfied, no matter what one does. In this regard 'not satisfied' sometimes means just that people have suggestion, or wishes. I like the app, but I would found amazing if the app could switch to SMS mode, when it is not possible to deliver message via data connection. I'll bi satisfied also if you drop SMS support completelly (just less satisfied : )). I understand also that one has to follow priorities. It is better to have less features, but well done app (Security and reliability in the first place.).

[bungabunga]

@moxie0

"I actually think it's pretty simple: it tries to send a data message, and if it can't it sends an SMS. If you want, you can configure it not to send an SMS, or to ask you before sending the SMS."

i respect TextSecure for being minimallistic and not bloated with features that non-geeks don't understand. but at this very point i think you're wrong. non-geeks would always think SMS fallback means "if she's 'offline' then she'll get it via SMS".

[agrajaghh]

Apple gets this completely right with iMessage. It always uses Push, unless the Push message doesn’t get acknowledged in a few seconds. There is one single option for this in the iPhone - “Use SMS if Push doesn’t work”, or words to that effect. That way I have control over SMS charges. That’s pretty simple. It’s exactly what you described above.

This sounds like a really good solution which would work with TS too, as soon as the delivery receipts are integrated. But I would understand you as well, when you drop SMS support and focus on a reliable data messaging app.