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!