7 ms·
I can imagine a number of complications here. How should delayed send work with respect to both end-to-end encryption and with network connectivity loss? Ie I c
by jpp 4y ago
I can imagine a number of complications here. How should delayed send work with respect to both end-to-end encryption and with network connectivity loss? Ie I can see a possible way to build this where the sending user’s device queues and sends it later, but what if that device is out of network coverage area, or battery-dead, at the requested send time? …so then we could think about doing it at the server level, but then to maintain end-to-end encryption, the message would have to be pre-encrypted; how would we handle rekeying a user? Ie if the delay send is for 24 hours from now, but one of the recipient’s keys get rotated (which afaik can happen in a couple of reasonable conditions; but others here will know more)… well, we end up with a solution that also can’t reliably deliver the message.
One thing I really appreciate about Apple Messages is just how well it works, and how little spam ever makes it in. I think the reliability of Messages is almost taken for granted… I wouldn’t want to give that reliability promise up for this sort of feature!
- yieldcrv 4y agoSounds like someone recently studied system design interviews, did the compensation bump work out?
- texaslonghorn5 4y agoMaybe I am missing something obvious/important. Google Messages delay send will not send the message if the phone is off/disconnected. What's wrong with Apple Messages setting up delayed messages just like that? You said reliability. But Google Messages delay has worked 100% of the time for me and I've never had a situation where the phone was off when it needed so maybe I am the wrong person to ask. Is there a way to have the timestamp part be unencrypted and the message be encrypted or does that violate end to end policy? Though I like being able to cancel/edit until the send deadline so from my perspective it's best to keep on the sender device as long as possible and send only at the last possible second.
- MBCook 4y agoBut iMessage is synced between devices. So if I delay a send on my iPhone and lose network, my other Apple devices know enough they could still send it. Should they (I asked to send) or not (‘sending’ device offline)?
- jeroenhd 4y agoIf it's E2EE, why not send the message with a timestamp at which the server should approximately process the message? If it's well encapsulated/encrypted, it shouldn't matter that the message is on the server for a while.
- bobthepanda 4y agoWho said the queue has to be on the sender’s device or the server? Sender sends it encrypted with a flag to not display until X time, phone receives it whenever, and then displays it at X time because it’s just been sitting there.
- texaslonghorn5 4y agoWell I think one benefit of a scheduled send is the ability to cancel or edit after hitting the send button. So I'm not sure if I'd appreciate setting it up like you say here.
- bobthepanda 4y agoYou can send updates or a cancel message after the fact still.
- E4YomzYIN5YEBKe 4y agoThen that would fail if the receiver goes offline.