Sing-song: a speakable encoding for long numbers and keys
12 points by vrypan
12 points by vrypan
this could be a really pleasant way to convey ipv6 addresses
Oh, sure!
2001:0db8:85a3:0000:0000:8a2e:0370:7334
vs
faba-dagi-sofa-konu-baba-baba-bafa-raso-bavu-bitu-giba
This reminds me of Oren Tirosh's mnemonic encoder scheme, which uses words that were chosen very specifically to be short (4-7 letters), phonetically different from one another, easy to understand over the phone, and also recognizable internationally:
https://web.archive.org/web/20100105040244/http://tothink.com/mnemonic/index.html
Nice. Yes, this is how BIP39 encodes bitcoin private keys (https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki), and there are actually word lists for many languages.
My problem is that after a number of words, it's getting hard to remember them. Personally, I've found that I can more easily remember a silly song that has no meaning, as long as it has a rhythm.
Fun idea. As non-natyive English speaker, I wonder if pronunciation will be easy and consistent enough to not become ambiguous (you mention pronunciation briefly, but give no rules (which would defeat the "no training" goal)), with English as the target language, given that vowels often weaken into schwa sounds, and there is normally little correspondence between individual letters and the sounds they make in different contexts, and that's why spelling bees can exist.
Is sibo sai bow, see bow, or something else? I assume there's diphthongs even though none are spelled out. Maybe it doesn't matter but I think e.g. the English military alphabet did take that into consideration. For me who rarely speaks or listens to English I think some training would be required.
No one knows how to pronounce written English anyways, as a non-native English speaker I find it extremely amusing when native speakers are confronted with a word they know, but have no idea how to pronounce.
That's why the intro states
English is really hard to deal with even for simple syllables, so the result is not as good as I'd want it to be (a string you can read to an other person over the phone and make sure they get it right), but it's not bad either —if everyone spoke Itallian sing-song would be much more valuable :-)
If you want a strict rule, I imagined (but maybe should be included) that using IPA, a->/a/, b->/b/ and so on.
Parsers MUST ignore hyphens:
zilasibotivajuzuandzila-sibo-tiva-juzuare identical.
I wonder if you really mean this. Must parsers accept -zilasib----otivajuz-u? What about ----------zila, with 1 GB of hyphen characters before the letters?
Yes, the parser must ignore hyphens. Now, if your implementation allows a user to pass 1TB of data in an enter-your-pub-key field, it's not up to the spec to set this.
For example, HTML will ignore repeated whitespace chars, it's up to the browser to reject a HTML page with a billion newlines (or just parse them).
I was just thinking of something conceptually similar to this, to use as a human-parseable version of an iroh endpoint ID/public key. It's 32 bits long, or 64 digits of hex. They can be encoded as z-base-32, but that's not super human readable, either.
This encoding scheme is cool, and definitely results in something that is relatively pronounceable. But the number of chunks you get for a long number still produces something that's hard to remember, and likely prone to misspellings for long strings because the individual chunks don't make intuitive sense. Still cool, though.
(For my thing, I thought of breaking the 64 digit key into groups of 4 hex digits (i.e. two bytes each), converting each 4-digit group into a decimal index, and mapping it to a line in /usr/share/dict/words. But the result was still 16 words long (kind of long to just remember, though more memorable and readable than a string of 64 hex digits), and I also once again discovered how many truly odd words there are in /usr/share/dict/words. Maybe I can create my own dictionary.)
Maybe some of the variations covered in my post can fit your needs better. It's not hard to extend the vocabulary to achieve more information density, but then you loose the rhythm of sing-song.
Personally, I find it easier to memorize 22 easily pronounced words, even if they are meaningless, than 64 hex digits. Try "singing" it as a kindergarten song, it can really stick to your mind :-)
Personally, I find it easier to memorize 22 easily pronounced words, even if they are meaningless, than 64 hex digits. Try "singing" it as a kindergarten song, it can really stick to your mind :-)
100% agree. my idea was that real words, like from a dictionary, might be even more memorable for my use case.
That would be ideal. But to get a similar result to sing-song (12 bits per word) you need 4096 words with length 3-5 (?) letters, that are distinguishable, easy to write, sound good, etc.
I could not find this many. If you start removing to/two, by/buy/bye, sea/she, color/colour, center/centre, liter/litre, check/cheque, etc, the list gets nowhere close to 4096 :-(
Also, if you stop having a strict CV or similar pattern, then you need the separators. Not a deal-breaker, but for me, it weakens the result.
Why did you keep the ambiguous letters w and z? They're barely better than c and x.
I wanted to get to 64 combinations (16x4) which make math easier but also allows for faster implementations. I'm aware that there are some combinations that may be easy to hear wrong, etc. Unfortunately, English is really bad for this application, other languages have much clearer rules on how letters and syllables are pronounced.
There are a number of compromises I had to do, and a number or alternative paths I tested, this is what seemed more balanced.
Actually, this may be an encoding visually impaired users may prefer. Anyone with access/knowledge of this community?
Cool idea but I'm foreseeing a pack of luddites with tiki torches under this post. Unless they changed their mind on AI assisted posts and self-promo ratios.