debdut/uuid-readable

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

uuid-readable

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

• Built on UUID v4
• Optionally pass your UUID to generate a unique sentence
• 128 Bit Crypto Secure
• Grammatically correct sentences
• Easy to remember
• Has a Shakespeare feeling
• Universally Unique Identifier
• Generate Low Entropy 32 Bit Tokens

Example

128 Bit UUID Readable

Loren Chariot Addy the Titbit of Cholame questioned Cele Garth Alda and 16 windy frogs

Drucill Hubert Lewse the Comer of Avera rejoices Fiann Craggy Florie and 5 hard trouts

Jacquette Brandt John the Pectus of Barnsdall doubted Glenn Gay Gregg and 12 noisy stoats

Low Entropy 32 Bit

11 pretty dragonflies regularly sang

2 fat toads happily buzzed

Note

Think of it this way, it's impossible to remember 32 random characters in UUID, but these sentences even though hard can be remembered, and are definitely fun!

Alternatively, generate 32 bit readable small sentences from 128 bit UUID and check later if they match.

API

Thanks to uuid.rocks, we have an API Endpoint

curl https://uuid.rocks/plain?readable
# Joyce Ange Barrett the Orient of Alco killed Marlyn Hewett Lady and 11 strong bulls

Installation

npm install uuid-readable --save

Usage

const id = require('uuid-readable')

console.log( id.generate() )
// Cathleen d Dieball the Monolith of Alderson reflects Arly Arnie Keenan and 18 large ants

Pass your own UUID

console.log( id.generate(uuid) )

Inverse, get UUID back from Readable UUID

const uuid = '1b9d6bcd-bbfd-4b2d-9b5d-ab8dfbbd4bed'
const readable = id.generate(uuid)
const inverse = id.inverse(readable)
 
inverse === uuid // true

Low Entropy 32bit Readable (Use as Readable Hash)

const short = id.short(uuid)
// 5 fat toads happily buzzed

// Check Later
id.check(short, uuid) //true

MongoDB

const id = require('uuid-readable')

readable_id: {
  'type': String,
  'default': id
}

// or use as real id

_id: {
  'type': String,
  'default': id
}

How does it work?

UUID is converted to 128 bits.

• 12 bits for first name
• 11 bits for middle name
• 14 bits for last name
• 13 bits for a personal pronoun
• 13 bits for name of place
• 10 bits for verb
• 12 bits for first name
• 11 bits for middle name
• 14 bits for last name
• 5 bits for number of animals
• 6 bits for animal adjective
• 7 bits for animal

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

Alternatively, the inverse funcation proves that UUID and Readable UUID form a bijection, hence no loss of entropy.

Use Cases

• Customer Support

You can remember parts of the id and that's enough to search it up and communicate throughout a large team. I will be using it as a secret generation for a service, and customer tickets.

Sponsors

Shakespeare Geek

uuid-readable's Issues

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.

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?

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?

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.

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, ...).

'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.