Improvement: would it be possible to allow it to be "seeded"?

[paralleldrive]

Improvement: would it be possible to allow it to be "seeded"?

[ericelliott]

It doesn't make any sense to me at all.

First of all, why would you want to do that? What is the end goal you're trying to accomplish?

Second, how do you know the UUID is "completely random"? Have you run rigorous cross-node collision tests like we have with cuid?

Would you want the seed to only effect the random portion of the cuid, or would you want it to have a larger impact on the cuid structure? Please explain your thinking.

[rfink]

To answer your first point, it would give the ability to generate a cuid string (which in and of itself is nice, because it has the consistency of the timestamp prefix) from a known random value (for example, generating a cuid string based on a uuid v4 session id). Not unlike re-hashing an already hashed value.

The second point, I would be generating it using uuid v4, but it could be stated that someone who supplied the seed value would be responsible for ensuring it was truly random.

The last point, yes, I think it would only affect the random portion of the cuid.

[ericelliott]

it would give the ability to generate a cuid string (which in and of itself is nice, because it has the consistency of the timestamp prefix) from a known random value (for example, generating a cuid string based on a uuid v4 session id). Not unlike re-hashing an already hashed value.

OK, I think I have a good idea of the mechanism you'd be after, and an idea of how it could be easily implemented. Now I just need to understand WHY you'd want to do that. What is the benefit? What value would you get from it?

I'm not going to make a change that could potentially hinder cuid's ability to avoid collisions without some really solid justification. =)

[rfink]

I completely understand. My particular use case is:

We are using cuid in a project to generate a unique id for every session and every page view, as well a unique visitor id, and several other internal-use ids. The problem with the session id is that we allow an "external session id" to be provided to the server which will force a new session (so we can synchronize sessions between 3rd party systems: it's a bit complicated). By allowing a supplied external session id, we wouldn't have control over the format, but we would like to keep the session id as a cuid, which we could (theoretically) seed with the external session id. I know that's a bit of a long winded answer, but let me know if that gives good clarification.

[ericelliott]

Wait. What?

You allow an external session id to be provided to the server which will force a new session. Good. With you so far. I think.

By allowing a supplied external session id, we wouldn't have control over the format

Lost me here. Why don't you "have control over the format"? and why can't this be a regular cuid, instead of a seeded one?

but we would like to keep the session id as a cuid, which we could (theoretically) seed with the external session id.

What would you accomplish by "seeding" the cuid with the external (uuid v4?) session id? The cuid is still pretty much a random jumble of characters, unless you plan to yank the random part off the end and use that to look up your sessions in third party systems using a uuid v4?

If I understand you correctly, it's a bad idea. It's basically akin to storing state in the ID. This was done at a large company I worked for once. It caused all kinds of bugs and chaos.

Ids should be used strictly as keys, not as data containers. Instead of trying to stuff data into your cuids, use something like Redis or Mongo to associate your cuids with corresponding v4 uuids, and note that you might get some uuid v4 collisions, because as we already know, you can't trust the uniqueness of v4 uuids.

Good luck.

[rfink]

Yeah a few moments after I finished my last response, I realized what I was trying to do wasn't going to work. I think we are either going to have to go with a combination of prefixing the internal/external combo with a timestamp or just hashing the internal/external combo and not worry about having a time-based id. At any rate, thanks for your time, great module.

[ericelliott]

I wouldn't try to mix the two id types into a single id using any method, including hashing and concatenation. As I mentioned before, that's essentially like trying to use the id itself as a data container. I've seen that attempted many times, and every time it turned out to be a big mistake.

Instead, you'll want to store both ids in a key/value store so that you can associate one with the other easily. Using something like Redis or Memcached, this can be done in a highly performant, in-memory fashion with lightning fast lookups.