On Sat, Feb 01, 2020 at 11:00:24AM -0800, Brad Peabody wrote: > The issue being that many applications need something like a UUID but can't use > an actual UUID for one reason or another (e.g. sorting properties, > insufficient unguessability, too long, etc.); thus the new proposal. Again, I'd urge you to consider that you should build on *top* of the standard UUID spec, since there are already implementations that will do the right thing as far as time-based and random-based UUID's (the latter will provide all the unguessability you need) and then just create a library which *transforms* the UUID into a convenient encoding form that makes it be convenient for key-indexing, or a more compact text encoding, etc. There are already very good implementations for UUID generation, and if you create something which re-invents the wheel at a spec level, it will cause people to reinvent the wheel (possibly badly) at the implementation level. Cheers, - Ted
