[mds101]

It looks very good for something whipped up in an hour. Did you consider using Redis as a data store for this? Seems like it would be quite easy to just generate a UUID as a key and set it with an expire time in redis. If you did consider Redis, any reason why you didn't end up using it?

[KMag]

If you want privacy and anonymity, be careful about how you're generating your UUID. Some flavors of UUID are just the MAC address, process ID, and timestamp, which makes them trivially guessable (and poorly scalable).

Instead of a UUID, just read 16 bytes from /dev/urandom (getentropy() if you've got it). Base85 or Base64 encode the bytes if you need a string.

[NicoJuicy]

Any resource about this?

Someone mentioned it before and it seems false. UUIDS are made to scale and i think it's mostly about a lack of understanding of UUIDS.

Eg. some versions of UUIDS are meant to be deterministic, some for sortability, ...

https://en.m.wikipedia.org/wiki/Universally_unique_identifie...

[KMag]

It was over 20 years ago now, and I don't remember which library it was, but I ran across a type-1 UUID library that stored the timestamp of the latest UUID it handed out in a static (or maybe thread-local, I forget) variable, and would nanosleep until the system clock next ticked if it had already handed out a UUID with the current timestamp. So, you were limited in your UUID generation rate by the resolution of the system clock.

(I guess the fear was that it was theoretically possible for the process to crash and come back up with the same PID/TID within the same system clock tick, if the machine were really chewing through processes rapidly. It's good, as they aren't called Nearly Unique IDs, and the main use for type-1 UUIDs would be if you're paranoid about RNG collisions, but it does limit you to one ID per system clock tick, even though the timestamp in the type-1 UUID is actually 100-nanos resolution.)

A better solution would have been to query the system clock resolution, at library initialization time check the current system timestamp, and use the low bits of the type-1 UUID timestamp as a counter, being careful to never catch up to the current time. The library wouldn't have been able to hand out any UUIDs during the first system clock tick after library initialization, but after that, it could hand out up to 10 million UUIDs per second per thread. If that's not fast enough, one could also have it check for multiple network cards and use a pool of MAC addresses instead of just the primary interface's MAC address.

[NicoJuicy]

It was only proposed as a standard in 2005. So perhaps the first versions of it were not efficient?

I definitely didn't had issues the last 10 years ( .net )

[KMag]

The UUID RFC is from 2005, but they're also documented in the ISO/IEC 11578:1996 standard.

As I mentioned, a good type-1 implementation uses a counter to simulate a higher resolution system clock to get around the system clock resolution limiting scalability. Also, I'm guessing you're generating type-4 (random) UUIDs instead of type-1 (MAC address and timestamp), right?

My point is that if you're generating UUIDs rapidly, check that you're either generating type-4, or that you're using a high-quality type-1 implementation that simulates a higher resolution clock using a counter.

[jassra]

Love the idea. I ll implement : )

Thanks for visioning better !

[loa_in_]

Redis looks like the perfect tool, with reliable inbuilt expire mechanic.