> if you have received duplicate messages then by definition you have been delivered that message more than once
Yes. So? If you don't include a mechanism for ensuring exactly-once delivery then you will not be guaranteed exactly-once delivery. But if you do, you will. It doesn't actually require a Ph.D.
To discard the duplicates, you need to update your state based on the first message and consult that state for all subsequent messages. Someone must be delivered those messages for this to happen.
If you say that someone can then pass you messages exactly once over a perfectly reliable channel, well.. sure. But the system still has to deal with duplicate delivery and update its state based on that. (And potentially must durably persist this state. And, then, if your application doesn't have exactly the same persistence/transactional boundaries as what's doing the deduping, you have problems...).
You wrote in the post:
>This post was intended to be about human communication more than distributed systems or network protocols
But resorting to technical minutiae as you have done doesn't seem germane to "human communication". Honestly, seeing such mental gymnastics just to avoid losing face on an internet argument is really disappointing.
>> if you have received duplicate messages then by definition you have been delivered that message more than once
>Yes.
Okay, I'm glad we agree that delivering something multiple times and discarding the duplicates is not exactly-once delivery.