[jpp]

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!

[texaslonghorn5]

Maybe 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]

But 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]

If 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]

Who 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]

Well 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]

You can send updates or a cancel message after the fact still.

[E4YomzYIN5YEBKe]

Then that would fail if the receiver goes offline.

[yieldcrv]

Sounds like someone recently studied system design interviews, did the compensation bump work out?