Machine ID for Distributed Contexts

[CMCDragonkai]

I'm not sure if the spec mentions this, but I thought given that one of the inspirations was the usage of snowflake, I thought at the very least there's a way to provide the machine/node-id.

Unless the expectation is for the user to concatenate the uuid with the machine id, but in that case I might as well use the old uuids versions, I could already do this.

[kripod]

Great idea, thank you for sharing it!

As the spec draft mentions it:

implementations MAY dedicate a portion of the node's most significant random bits to a pseudo-random machineID which helps identify UUIDs created by a given node. This works to add an extra layer of collision avoidance.

The machineID MUST NOT be an IEEE 802 MAC address. The creation and negotiation of the machineID among distributed nodes is out of scope for this specification.

How should we document the generation of machine IDs and how long may they be out of the 62 random bits? (The spec doesn’t seem to mention anything about maximum length.)

[CMCDragonkai]

So only documentation is necessary here? Maybe that part of the spec should be added in. Although I would like an explanation of the most significant random bits. Which part of the uuid is that? Also does that mean the machine ID can only at-most be 62 bits?

On 28 September 2021 7:22:46 pm AEST, "Kristóf Poduszló" ***@***.***> wrote: Great idea, thank you for sharing it! As the spec draft [mentions it](https://www.ietf.org/id/draft-peabody-dispatch-new-uuid-format-01.html#name-distributed-uuid-generation): > implementations MAY dedicate a portion of the node's most significant random bits to a pseudo-random machineID which helps identify UUIDs created by a given node. This works to add an extra layer of collision avoidance. > > The machineID MUST NOT be an IEEE 802 MAC address. The creation and negotiation of the machineID among distributed nodes is out of scope for this specification. How should we document the generation of machine IDs and how long may they be out of the 62 random bits? (The spec doesn’t seem to mention anything about maximum length.) -- > You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #1 (comment)

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[kripod]

The machine ID has to be way less than 62 bits, otherwise there would be no space left for random bits. The most significant random bits are the first bits inside the last 62 bits of a v7 UUID.

There isn’t an implementation yet, but I was curious how we could document this feature clearly.

[CMCDragonkai]

I did some calculations on collision probabilities and found that it's easier if I just concatenate my machine ids at the end instead of trying to fit it into the UUIDs.

[hiimmrdave]

Just browsing issues since I'm interested in using the package. It's probably best to close this as out-of-scope based on the latest UUIDv7 draft.

The text cited above does not exist in the draft-04 text. The relevant issue is handled here: https://datatracker.ietf.org/doc/html/draft-peabody-dispatch-new-uuid-format-04#section-6.3

  With this method, a pseudo-random Node ID value is placed within
  the UUID layout.  This identifier helps ensure the bit-space for a
  given node is unique, resulting in UUIDs that do not conflict with
  any other UUID created by another node with a different node id.
  Implementations that choose to leverage an embedded node id SHOULD
  utilize UUIDv8....

UUIDv8 gives application authors the option of including node ids, different precision of timestamp, or any other data that leaves room for sufficient randomness within 122 bits. For my use, v7 makes UUID quick enough that the generating node can be shoved into metadata if it's needed at all.

[kripod]

@hiimmrdave good point, I’m closing this as suggested. Thanks for your response.