4 ms·
I do have an "invite" prompt on my SMS contacts that don't yet have Signal: "Invite to Signal: Take your conversation with %s to the next level.". Perhaps it's
by qrmn 11y ago
I do have an "invite" prompt on my SMS contacts that don't yet have Signal: "Invite to Signal: Take your conversation with %s to the next level.". Perhaps it's a function in the beta version that isn't in the live version yet?
I haven't seen a message with a double-tick that's been dropped yet, at least not on a recent version. It can sometimes behave poorly with Android battery-saving mode - however, so does plain SMS. Turning off sync is part of the actual point of battery-saving, but conversely, I never want to not get messages. That's arguably Android's problem, not Signal's. Still, it uses GCM, so at least there's hope for the deep sleep (which I haven't tried yet).
- xorcist 11y agoSurely battery saving modes should not drop messages? It could delay them but should never (well, almost never) drop them.
- newjersey 11y agoWith no knowledge of how signal's servers actually implement this, I would like to ask you... how long should the central server hold on to the (encrypted) message that Alice sends to Bob if Bob never becomes available again?
- newman314 11y agoBest effort, deliver at least once? At least that how it seems iMessage seems to work. I have no idea how long iMessage holds on the queue but it seems no more than a few days. Not sure what kind of attack vector a public TTL would constitute.
- xorcist 11y agoI haven't thought about what's reasonable (an hour? a week?) but it still shouldn't be dropped but bounced back to the sender with an undelivered message. At last that's how email solved it some thirty years ago. (But perhaps a new protocol could take the opportunity to improve things further and offer on-line delivery status notifications throughout the process.) No matter what, messages should never be silently dropped.