Please find (in seperate emails to follow shortly) three proposed patches to address this issue that I and others have raised. All three patches have the use of (some of) the other patches I sent today as a prerequisite.
Patch #1 generates ID's in the form: <1590350694.yJEHqG0ie/TbuynV@settler>, that is, the seconds since epoch, followed by a dot and 96 bits of Base64 encoded randomness. What I like about this patch: It addresses my concerns and still contains a timestamp that is easy for humans to compare against other such timestamps while simplifying the message ID generation. Patch #2 generates ID's in the form: <20200524201957.R5l+GRVFqFbpYezC@settler>, that is, the old way but with 96 bits of Base64 encoded randomness instead of GA12345. What I like about this patch: It addresses my concerns without changing anything else in the message ID. Patch #3 generates ID's in the form: <XsrXb8PS4lfD0uJX@settler>, that is, the seconds since epoch, followed by 64 bits of randomness, all Base64 encoded. What I like about this patch: It addresses my concerns and still contains a timestamp while resulting in short(er) message ID's. I'd be happy if any of these patches is accepted or perhaps used as inspiration for an alternative form that would address the concerns raised. I know opinions on this topic are varied, so this will be my final message on this subject in regards to how (un)desirable this requested change is. Of course, If anyone has any comments or (technical) concerns about the proposed patches, I'd be more than happy to receive those. Stay healthy all, Remco
