Possible alternative access API

[Garbee]

In the discourse discussion it was asked "Is v4 all we need?". I believe this more hits at an underlying API design issue rather than simply trying to understand if V4 is enough.

Providing this under such a generic name as randomUUID is oddly limiting in the future. What should happen if UUIDv8 comes around and applies some trick/alteration to allow for more byte packing? Then apps are coded to look for and possibly validate V4's and changing the underlying product to v8 would break. Or in the future some use-cases come around to warrant including other types into the Crypto API?

I think a prudent course may be an API such as crypto.uuid.v4(). This gives uuid it's own namespace of operation under Crypto. Which then allows for any required expansion of UUID availability in the future, without creating confusion.

crypto.uuid.random() could then be a proxy to v4 currently, but be marked as a method open to change in the future should something better come around in the UUID specifications. Regardless, UUIDs are a fairly recognized occurrence these days. I'm not sure what the benefit of calling it "random" alone is rather than what it is, "v4".

[domenic]

FWIW, I really like the current name, as it doesn't burden web developers with needing to know UUID-spec esoterica such as "v4".

Additionally, on the web platform we generally don't want to add namespaces with only a single member. If we eventually needed more UUID functions, we could add them under crypto directly, or if there were somehow like 6 of them, then we could create a namespace and alias crypto.randomUUID() to crypto.uuid.random().

Finally, I'll mention that there are other extensibility mechanisms to allow changing the format without breaking existing code, e.g. crypto.randomUUID({ extraBytePacking: true }).

[Garbee]

Yea, aliasing down later is a very good point. I didn't consider that approach should a more methods be needed later.

Optional config also very good for not breaking later should new things come around.

On naming, yea I'm totally down with keeping that level of detail minimal. That part was more of a straw point to try and get the intent across.

I think this is perfectly reasonable then. Perhaps a "Future Consideration" section could mention these points so it is clear to any readers of the explainer that it doesn't limit future iteration in any way?

[ctavan]

@Garbee have you seen the in-depth analysis and the original discussion on how we settled on the name?

That is not to say we shouldn't perhaps revisit that decision, I just want to make sure we don't have to repeat all arguments that have already been exchanged in the past before opening this discussion up again.

[Garbee]

No I hadn't. Now I'm officially confused by the TC39/WICG crossover...

Thanks for the links, much appreciated.

[ctavan]

We initially started this effort in TC39, but in the course of the process we concluded that W3C is the more appropriate place.

[ljharb]

It seems like a good idea to give TC39 an update about that venue change; not everyone might agree that W3C is the more appropriate place, and those concerns deserve a chance to be aired.

[Garbee]

Yea, seems odd to me "the W3C is more appropriate" for this. It is clearly a pure-JS function. I'm not sure why it wouldn't clearly be in the TC39's purview.

[bcoe]

Yea, aliasing down later is a very good point. I didn't consider that approach should a more methods be needed later.

@Garbee the fact that we can introduce options later (combined with the fact that UUID v4 maximizes entropy, making the need for a different default UUID algorithm relatively unlikely) has me pretty strongly in support of the randomUUID method name. I like that, as @domenic points out, it shields users from needing to understand the nitty-gritty implementation details.

No I hadn't. Now I'm officially confused by the TC39/WICG crossover... Yea, seems odd to me "the W3C is more appropriate" for this. It is clearly a pure-JS function. I'm not sure why it wouldn't clearly be in the TC39's purview.

I've created #19 for this discussion.