The server still doesn't know whether the sender knows that the server received and acknowledged your message, so you might want an ack from server, but again, the server doesn't know if you received the ack, so you ack the ack, but again ...
Using a server means the problem isn't event the same problem.
The General's Problem (as presented in the comments) is trivially solvable by multiple messengers WHO COME BACK to report the message delivered. Wherein, the messenger is an encrypted messenger and the general has the key (knowing which messengers were sent out).
In an ephemeral message scenario, you have to rely on the same idea, using an encrypted log of messages that both generals have access to (since they are both "on the same team", there is already coordination).
This philosophical exercise isn't practical, from the setup provided. I don't see the point in trying to solve for it without adding a ton of additional constraints, by which you can reach an optimal or no-solution.
Fundamentally this is a Fisher consensus issue. To solve any Fisher consensus issue, all you need to do is create a synchronisation point - which is what the server becomes.
Basically, the server assumes that if the client has ACK'd the message, it can continue sending data. The client assumes that the server has received their ACK if it continues sending data.
If no data is being sent, the connection is closed via timeout eventually.
I am talking about the Two General's problem which I thought original commentator was referring to as the original problem.
In this situation you are describing a server that wants to send a client a message, and both parties need to be sure that they are in agreement when to attack a common enemy they can't deal with alone because the message contains the attack plans and timestamp for attacks.
Wikipedia has a good explanation:
"The first general may start by sending a message "Attack at 0900 on August 4." However, once dispatched, the first general has no idea whether or not the messenger got through. This uncertainty may lead the first general to hesitate to attack due to the risk of being the sole attacker.
To be sure, the second general may send a confirmation back to the first: "I received your message and will attack at 0900 on August 4." However, the messenger carrying the confirmation could face capture and the second general may hesitate, knowing that the first might hold back without the confirmation.
Further confirmations may seem like a solution—let the first general send a second confirmation: "I received your confirmation of the planned attack at 0900 on August 4." However, this new messenger from the first general is liable to be captured, too. Thus it quickly becomes evident that no matter how many rounds of confirmation are made, there is no way to guarantee the second requirement that each general be sure the other has agreed to the attack plan. Both generals will always be left wondering whether their last messenger got through. "
There is no solution, only a decreasingly smaller change of disagreement e.g. by sending many messages or keep acking each other x amount of rounds (there are other strategies).
What if they send a message that general 1 is going to fire a flare at 0900 and if general 2 fires one too then they both attack.
Basically make the confirmation something that you can get without relying on the same method of communication
You are just back to the same problem, you need to trust a server. The server is the valley between the generals, you can't be sure what happens there. Do they get the message, or do they het an altered message, both of which will send blue ticks to indicate it has been read.
The server still doesn't know whether the sender knows that the server received and acknowledged your message, so you might want an ack from server, but again, the server doesn't know if you received the ack, so you ack the ack, but again ...