gistfile1.txt

FROM: DI0f0c644fd3ccb51c2cedbd47fcb6f312646c993c05a0SQ

TO:

Proposal 1: DI0f0c644f:d3ccb51c2cedbd47fcb6f312646c993c:05a0SQ (two ":" added)
Proposal 2: DId3ccb51c2cedbd47fcb6f312646c993c0f0c644f05a0SQ (Node and Message ID inverted)
Proposal 3: D[d3ccb51c2cedbd47fcb6f312646c993c]0f0c644f05a0Q (D and Q only for validity check, [] around Message ID)

I would prefer Proposal 1. The ":" in between makes the best readability of the 4 IDs.

Colons for me as well since I tend to namespace my Redis keys like this.

Isn't this a counter argument? Colons are popular for namespacing redis keys, so to avoid (very minor but) potential confusion use option 1 but with dashes (like in uuids) instead of colons.

With dashes it looks like DI-0f0c644f-d3ccb51c2cedbd47fcb6f312646c993c-05a0-SQ.

TBH, the SQ at the end decreases readability even with separators between the individual parts. Reception of the format is very subjective and there are lots of pros and cons for each format. The ordering of nodeId, messageId, TTL makes absolutely sense for me since it follows a top-to-down detail level approach.

Shifting the SQ to front would result in DISQ-0f0c644f-d3ccb51c2cedbd47fcb6f312646c993c-05a0

Here some id's in a list:

DISQ-0f0c644f-d3ccb51c2cedbd47fcb6f312646c993c-05a0
DISQ-ff010e8a-6c47a7213787936cd5d6b1a57a698fa4-000a
DISQ-ff010e8a-c31294bb2e3ec3678d6c0301412012c3-05a0

I would opt for mp911de's proposal. Otherwise, if only the three proposals mentioned by antirez are valid options to choose, I would go for (1)

Thanks for your help, we have a winner based on @mp311de proposal with changes to make it shorter and more future proof. So this is the new ID:

D-dcb833cf-axzAwPMGBuogYEg6Omgrq090-05a1A$

Remarks:

1. The node part is at the same offset as it used to be in the past.
2. Random part is in base64, so now there is room for 144 bits of entropy.
3. After the TTL there is a reserved byte for future uses "A". It is set to "A" since it's the logical zero in the base64 encoding.
4. There is an ID terminator "$"
5. The ID is just 42 bytes long. Shorter than the original IDs.

Looks like a good compromise among the things we needed. Code is available in the newid branches. I'll merge soon. Thank you for your help.