[qrmn]

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]

Surely battery saving modes should not drop messages? It could delay them but should never (well, almost never) drop them.

[newjersey]

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

[xorcist]

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

[newman314]

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