--- title: Sing-song: a speakable encoding for long numbers and keys description: A new draft spec called Sing-song proposes a reversible, speakable encoding for byte strings, mapping every 6 bits to one of 64 pronounceable consonant-vowel... canonical: https://daily.dev/posts/sing-song-a-speakable-encoding-for-long-numbers-and-keys-s9ebz34pa copyright: © 2026 Daily Dev Ltd. terms: https://daily.dev/tos/ twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Sing-song: a speakable encoding for long numbers and keys | daily.dev og:description: A new draft spec called Sing-song proposes a reversible, speakable encoding for byte strings, mapping every 6 bits to one of 64 pronounceable consonant-vowel... og:url: https://daily.dev/posts/sing-song-a-speakable-encoding-for-long-numbers-and-keys-s9ebz34pa og:image: https://api.daily.dev/og/posts/s9eBz34pa.png og:image:alt: Sing-song: a speakable encoding for long numbers and keys og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Sing-song: a speakable encoding for long numbers and keys **[Lobsters](https://daily.dev/sources/lobsters)** · 11 min read · 1 upvotes · 0 comments ## Summary A new draft spec called Sing-song proposes a reversible, speakable encoding for byte strings, mapping every 6 bits to one of 64 pronounceable consonant-vowel syllables (e.g. hex 51ac0759fc4d becomes kalo-tadu-komu-tigi). It is deterministic, prefix-stable, self-sizing, and self-delimiting, with an optional 16-way variant suffix using SHAKE-256 masking for alternative representations of the same bytes. The post compares Sing-song's density against hex and Base58, walks through rejected alternative designs (curated syllable dictionaries, relaxed CV constraints, consonant clusters), provides test vectors, a full Python reference implementation, and a worked example of using it to generate readable Nostr npub key prefixes as usernames. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How does the Sing-song encoding convert bytes into speakable syllables? Sing-song splits input bytes into 6-bit chunks, most significant bit first, and maps each chunk directly to one of 64 consonant-vowel syllables using 16 consonants (bdfgjklmnprstvwz) for the top 4 bits and 4 vowels (aiou) for the bottom 2 bits. It requires ceil(8L/6) syllables for L input bytes, zero-pads the final chunk, and preserves leading zero bytes for a canonical, reversible representation. _Anyone designing readable key formats can compare encoding tradeoffs like this on daily.dev._ ### How many syllables does Sing-song need to represent a 256-bit key compared to hex or Base58? A complete 256-bit value takes 86 letters (43 syllables) in Sing-song, versus 64 hex characters or 44 Base58 characters. Sing-song trades written density for spoken clarity: it carries only 3 bits per letter and 6 bits per syllable, versus 4 bits per hex character and about 5.9 bits per Base58 character, making it better suited for values people must read aloud or transcribe. _Developers weighing key-encoding formats for usability can track comparisons like this on daily.dev._ ### How can a readable username be derived from a Nostr npub public key without hashing? An application can decode the npub to its 32-byte public key and take the first eight Sing-song syllables, which represent exactly the first six bytes (48 bits) due to Sing-song's prefix-stability property. This yields a readable prefix representation, not a hash-derived fingerprint, so a client can decode the username back to hex and match it against the beginning of known public keys. _Developers building human-readable identity schemes on Nostr can follow encoding designs like this on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 16 comments across lobsters, hackernews (as of 2026-09-14). **TL;DR:** Commenters find the speakable syllable encoding a clever and fun idea for memorizing keys, but several point out that long strings of meaningless syllables are still hard to remember and that English pronunciation ambiguity could cause errors. **Sentiment:** 45% positive · 45% mixed · 10% skeptical **The case for** - The rhythmic, song-like quality of the syllables makes it easier to memorize than raw hex or long word lists. - Seen as a pleasant potential way to represent things like IPv6 addresses. - Could be useful for visually impaired users, according to one suggestion. - The author's willingness to explain design tradeoffs (like hyphen handling and syllable choices) was well received. **The pushback** - Long keys still produce many chunks that are hard to remember and prone to misspelling since chunks lack intuitive meaning. - English pronunciation is inconsistent, so syllables like the examples could be read multiple ways, especially by non-native speakers. - Some ambiguous letters were kept in the syllable set despite being easy to mishear. - Real dictionary words might be more memorable than invented meaningless syllables, though building a large enough clean word list proved difficult. **By community** - lobsters (mixed): Engaged and largely constructive discussion comparing the scheme to alternatives like mnemonic word encodings and BIP39, with genuine praise mixed with practical concerns about memorability and pronunciation. - hackernews (mixed): No substantive comments were available to gauge sentiment. **Hottest debate:** Whether syllable-based encoding or real-word-based encoding (like dictionary words or BIP39-style wordlists) is ultimately more memorable and practical. **Open questions** - Can pronunciation ambiguity for non-native English speakers be resolved without adding training or IPA-based rules? - Is it feasible to build a sufficiently large, clean word list to compete with the syllable approach for memorability? - How would the encoding perform for visually impaired users compared to existing methods? **Highlights** > I was just thinking of something conceptually similar to this, to use as a human-parseable version of an [iroh endpoint ID/public key](https://docs.rs/iroh/latest/iroh/type.EndpointId.html#impl-PublicKey). 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.) > — [lake on lobsters · 1 points, 1 comments](https://lobste.rs/s/wvwqro/sing_song_speakable_encoding_for_long#c_wskmse) > 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. > — [vrypan on lobsters · 1 points](https://lobste.rs/s/wvwqro/sing_song_speakable_encoding_for_long#c_nphjsy) > 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. > — [owl on lobsters · 1 points, 1 comments](https://lobste.rs/s/wvwqro/sing_song_speakable_encoding_for_long#c_yzucol) > 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. > — [vrypan on lobsters · 2 points](https://lobste.rs/s/wvwqro/sing_song_speakable_encoding_for_long#c_ogkb3p) > this could be a really pleasant way to convey ipv6 addresses > — [zem on lobsters · 2 points, 1 comments](https://lobste.rs/s/wvwqro/sing_song_speakable_encoding_for_long#c_lhkspf) **Source threads** - [lobsters](https://lobste.rs/s/wvwqro/sing_song_speakable_encoding_for_long) · 11 points · 16 comments - [hackernews](https://news.ycombinator.com/item?id=49367716) · 1 points · 0 comments ## Similar posts on daily.dev - [Bytes Speak All Languages: Cross-Script Name Retrieval via Contrastive Learning](https://daily.dev/posts/bytes-speak-all-languages-cross-script-name-retrieval-via-contrastive-learning-nexqauuco) · Towards Data Science · 2 upvotes · 0 comments - [Punycode: My New Favorite Algorithm](https://daily.dev/posts/punycode-my-new-favorite-algorithm-oizfhofuk) · Lobsters · 0 upvotes · 0 comments - [My adventure in designing API keys](https://daily.dev/posts/my-adventure-in-designing-api-keys-c8cd0ndgm) · Hacker News · 2 upvotes · 0 comments - [Ink & Switch Introduces Bijou64: Canonical Variable-Length Integer Encoding for Safe Parsing](https://daily.dev/posts/ink-switch-introduces-bijou64-canonical-variable-length-integer-encoding-for-safe-parsing-mgtcxowck) · InfoQ · 0 upvotes · 0 comments - [On programming, statistics, and Java](https://daily.dev/posts/on-programming-statistics-and-java-8d0gstmw0) · Awesome Java Newsletter · 0 upvotes · 0 comments --- Tags: [#python](https://daily.dev/tags/python), [#cryptography](https://daily.dev/tags/cryptography), [#data-structures](https://daily.dev/tags/data-structures) [View this post on daily.dev](https://daily.dev/posts/sing-song-a-speakable-encoding-for-long-numbers-and-keys-s9ebz34pa) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Sing-song: a speakable encoding for long numbers and keys","url":"https://daily.dev/posts/sing-song-a-speakable-encoding-for-long-numbers-and-keys-s9ebz34pa","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/sing-song-a-speakable-encoding-for-long-numbers-and-keys-s9ebz34pa"},"datePublished":"2026-08-19T23:39:28.004Z","dateModified":"2026-09-14T06:06:03.464Z","description":"A new draft spec called Sing-song proposes a reversible, speakable encoding for byte strings, mapping every 6 bits to one of 64 pronounceable consonant-vowel...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/d586e5caba0cfa1d309d5167e6b7882d?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/d586e5caba0cfa1d309d5167e6b7882d?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Lobsters","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Lobsters","logo":"https://media.daily.dev/image/upload/s--tl8v_Fku--/f_auto,t_logo/v1698841318/logos/lobste.jpg","url":"https://daily.dev/sources/lobsters"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/sing-song-a-speakable-encoding-for-long-numbers-and-keys-s9ebz34pa","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"python,cryptography,data-structures","timeRequired":"PT11M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Lobsters","item":"https://daily.dev/sources/lobsters"},{"@type":"ListItem","position":3,"name":"Sing-song: a speakable encoding for long numbers and keys"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/sing-song-a-speakable-encoding-for-long-numbers-and-keys-s9ebz34pa#faq","mainEntity":[{"@type":"Question","name":"How does the Sing-song encoding convert bytes into speakable syllables?","acceptedAnswer":{"@type":"Answer","text":"Sing-song splits input bytes into 6-bit chunks, most significant bit first, and maps each chunk directly to one of 64 consonant-vowel syllables using 16 consonants (bdfgjklmnprstvwz) for the top 4 bits and 4 vowels (aiou) for the bottom 2 bits. It requires ceil(8L/6) syllables for L input bytes, zero-pads the final chunk, and preserves leading zero bytes for a canonical, reversible representation. Anyone designing readable key formats can compare encoding tradeoffs like this on daily.dev."}},{"@type":"Question","name":"How many syllables does Sing-song need to represent a 256-bit key compared to hex or Base58?","acceptedAnswer":{"@type":"Answer","text":"A complete 256-bit value takes 86 letters (43 syllables) in Sing-song, versus 64 hex characters or 44 Base58 characters. Sing-song trades written density for spoken clarity: it carries only 3 bits per letter and 6 bits per syllable, versus 4 bits per hex character and about 5.9 bits per Base58 character, making it better suited for values people must read aloud or transcribe. Developers weighing key-encoding formats for usability can track comparisons like this on daily.dev."}},{"@type":"Question","name":"How can a readable username be derived from a Nostr npub public key without hashing?","acceptedAnswer":{"@type":"Answer","text":"An application can decode the npub to its 32-byte public key and take the first eight Sing-song syllables, which represent exactly the first six bytes (48 bits) due to Sing-song's prefix-stability property. This yields a readable prefix representation, not a hash-derived fingerprint, so a client can decode the username back to hex and match it against the beginning of known public keys. Developers building human-readable identity schemes on Nostr can follow encoding designs like this on daily.dev."}}]} ```