Supporting future UUID formats

[broofa]

For those who haven't seen it yet: https://github.com/uuid6/uuid6-ietf-draft

[marcoscaceres]

Just wondering, does this new RFC have the potential to impact this draft proposal/API?

[bcoe]

does this new RFC have the potential to impact this draft proposal/API?

IMO, I don't think it does. I believe there were already time based UUIDs, and the main advantage of this new UUID is that it's sortable.

v4 still remains the best choice for purely random UUIDs.

Edit: also, our plan to future proof remains sound, which is an option object could eventually be accepted if we wish to allow other types of UUIDs.

---

_Aside: I think the sortable UUIDs are really interesting (similar to Twitter's snowflake). But, supporting them in the browser would open a can of worms about time based device fingerprinting._

[bcoe]

@broofa @ctavan does that agree with your thinking?

[broofa]

@bcoe Yup, agreed. Nothing to worry about as far as this spec goes. It's focused on time-based IDs, and still in the early stages.

That said, there are a bunch of IDs being thrown around that would be "interesting" if they proved popular and people started asking for them to be back-ported. E.g. There's talk of 160-bit ids, JSONB and base32 encoding... that sort of thing.

[marcoscaceres]

tl;dr: how likely is it that we will add new formats in the future?

CC'ing @ctavan, @mathiasbynens, who commented on #25.

I wonder if we need to start future proofing this now with an optional dictionary. Otherwise, in the future, we might have problems:

// An old browser would return a v4 uuid
// and the developer wouldn't know.
const uuid = crypto.randomUUID({ format: "v6" });

// They would need something not amazing like:

if (crypto.randomUUID.length) {
   // but you still don't know what versions are supported
}

If we added something like:

partial interface Crypto {
  [SecureContext] DOMString randomUUID(optional UUIDOptions options = {});
};

dictionary UUIDOptions  {
    UUIDFormat format = "v4"; 
 };

enum UUIDFormat { "v4" };

It also would allow developers to check if a particular format is supported.

try { 
  crypto.randomUUID({ format: "v3000" });
} catch {}

[bakkot]

I would hope that any other UUID versions would be exposed here under different method names, rather than by overloading randomUUID. Unless IETF changes the definition of UUID (rather than just adding new versions), v4 will forever be the unique "make all of the non-version-specifier bits random" UUID version. Any other version would no longer be a random UUID.

If you think you might want to overload this API to return other UUID versions, it should not be named randomUUID.

[marcoscaceres]

Yeah, I agree... we might need to update the potential future work section of the README to not make any API-shape suggestions at this point (currently suggests something similar to the above) - and perhaps just point to here asking folks to join the discussion.

[bcoe]

Yeah, I agree... we might need to update the potential future work section of the README

I agree with @bakkot. There are other interesting UUID formats, but they're not purely random. This makes them much more likely to be used for fingerprinting (version 1 even has a MAC address in it). I'd rather not open this proposal up to these concerns.

[Ginden]

There are other interesting UUID formats, but they're not purely random. This makes them much more likely to be used for fingerprinting (version 1 even has a MAC address in it). I'd rather not open this proposal up to these concerns.

RFC 4122 does allow the MAC address in a version-1 (or 2) UUID to be replaced by a random 48-bit node ID, either because the node does not have a MAC address, or because it is not desirable to expose it.