debdut/uuid-readable

Generate Easy to Remember, Readable UUIDs, that are Shakespearean and Grammatically Correct Sentences 🥳

uuid-readable's Issues

The sentence generated and the UUID does not form a bijection everytime

Hey !

I recently ported the idea of this library to Rust and discovered a few errors in your implementation.
The first is that the UUID and the generated phrase do not always form a bijection and therefore do not guarantee that the phrase is specific to that UUID. Consider the following example:

let uuid = "67604e3d-5059-421e-a955-cc1ba9d4f66a";
let res = ur.generate(uuid);
let rev = ur..inverse(res);
console.log(uuid); // 67604e3d-5059-421e-a955-cc1ba9d4f66a
console.log(rev);   // 67604e3d-5059-421e-a955-cc1ba9d4f62b
console.log(uuid === rev); // This is false

The cause of this problem is that in your lists (data) you have duplicate entries, which defeats the purpose of not losing entropy. Let's take the example of README:

For example, 7 bits for animal means we choose one animal from a list of atleast 2**7 = 128 animals

This is wrong because the maximum value that can be obtained with 7 bits is 127 + 1 (because of the index 0), if we remove the number of duplicates in the first 128 animals of the noun.json, we end up with less than 128 (I have not checked how many, but horses and frogs are duplicated so already 126).

The second is that you have entries in your lists (data) with spaces in them. This is a problem for the inverse method.
In deSentence, you separate words using spaces (' ') but with spaces in the words in your lists, this makes the reverse search invalid.
Take for example:

let uuid = "67604e3d-5059-421e-a955-cc1ba9d4f66c";
let res = idk.generate(uuid);
console.log(res); // Enid Adolph Beller the Builder of Anniston encourages Kettie Dru Karon and 9 thirsty gila monsters
let rev = idk.inverse(res); // This panic with "Not A Valid UUID Readable"

My suggestion to solve these problems is to correct the lists by deleting duplicate entries, deleting spaces in the entries and releasing a new version that will not be compatible with the previously generated UUID in some cases (due to change of index of entries, ...).

Clearer explanation of what it does

Hi. I am quite confused. What are we supposed to do with the sentences? Is that a converter between regular UUIDs and those sentences, like a 1-to-1 match? If someone tells me a sentence, how am I supposed to get back the real UUID? Or are you supposed to store the whole sentence as an ID? I feel like the readme lacks a paragraph to explain what this is about.

uuid v9

Hello,

Thanks for the library. I was wondering if there was any appetite for updating the uuid version to v9? Or having uuid specified as a peer dependency that would support v8 and v9.

UUID Changelog here: https://github.com/uuidjs/uuid/blob/main/CHANGELOG.md

The breaking changes are mainly around dropping support for legacy browsers and node versions so I don't believe upgrading would require any code changes. Would be happy to raise a PR if there are no objections to upgrading?

Error: Not A Valid UUID Readable

I am not able to use id.inverse(readable) with some uuid's.
I tested it with demo readable uuid provided by this library: id.inverse(Cathleen d Dieball the Monolith of Alderson reflects Arly Arnie Keenan and 18 large ants) which failed.

Also id.check doesn't always return true. I tried to see if that is connected in anyway so I used id.inversed only if id.check returns true, but it would fail as well.

False advertising of cryptographic properties

Readme says:

128 Bit Crypto Secure

This is a dubios claim at best. Everything is based on UUIDs, which do indeed have 128 bits. But some of these are version identifiers and parity checks.

Last time I checked random UUIDs had about 122 bits of randomness. Time-based and hash-based UUIDs can be rather predictable, depending on how they are generated in a particular scenario.

That said, these "128 Bit UUID Readable" strings do not alter any cryptographic properties that the underlying UUID may or may not have. So why even mention it?

'Gramatically' should be 'grammatically'

If I'm picky—and I am—there are some issues with the current linguistic state of README.md:

Generate Easy to Remember, Readable UUIDs, that are Shakespearean gramatically correct sentences

There are a few errors in that line; To clarify matters, it could be written like this instead:

• Generate easy-to-remember and readable UUIDs that look like Shakespeare would have written them.

There is no 'Shakespearean grammar'; English has always been a mishmash of different styles and rules and still is, as opposed to languages like French, which is decided by a committee since centuries ago. As such, Shakespeare didn't set any grammar rules, but actually rather broke them. Even if this is the intended meaning in your text, the sentiment is sadly lost due to the altogether poor readability of README.md.

Has a Shakespeare feeling

This is not wrong, but differs in consistency from what you have written elsewhere; You first wrote 'Shakespearean gramatically correct sentences', and line differs from the previous one, which lacks in readability and might vex readers.

There are some [compound-modifier] issues here as well.