Sing-song: A Speakable Encoding for Converting Long Numbers and Keys into Pronounceable Syllables

Solving the Challenge of Long Numerical

Representations Through Pronunciation

Accurately conveying long byte sequences, such as cryptographic keys or Nostr npub keys, over the phone is difficult. Hexadecimal notation is compact but hard to pronounce, while Base58 improves readability but remains unsuitable for oral transmission. To address this, the blog site blog.vrypan.net by vrypan published an experimental method on August 19, 2026, called Sing-song. It is a draft (v0.1.0) of an encoding standard that reversibly converts arbitrary byte sequences into syllable sequences with a regular pronunciation grammar.

Design of the 64-Syllable Alphabet

The core of Sing-song is a 64-syllable alphabet that directly maps 6-bit values to individual syllables. It assigns 16 consonants (odd positions)—b, d, f, g, j, k, l, m, n, p, r, s, t, v, w, z—and 4 vowels (even positions)—a, i, o, u. By strictly alternating consonants and vowels, it generates open CV (Consonant-Vowel) syllables. There are no consonant clusters or codas (final consonants), resulting in a regular pronunciation pattern.

The letters h, y, and e are excluded because their pronunciation is relatively unstable. The article on Lobsters (referencing blog.vrypan.net by vrypan) also notes, “If everyone spoke Italian, Sing-song would be even more useful.” It suggests high affinity with open-syllable-dominant languages like Italian, and indicates practical accuracy even in English contexts.

Algorithm and Self-Containment

The input byte sequence is treated as a bitstream, divided into 6-bit chunks starting from the most significant bit. Each 6-bit segment determines a consonant index (0–15) using the upper 4 bits and a vowel index (0–3) using the lower 2 bits, converting it into one syllable. For an input of L bytes, ceil(8×L÷6) syllables are generated. If the final segment is less than 6 bits, the lower bits are zero-padded.

A crucial design decision is that the complete encoding is self-contained (self-sizing). The original byte length L can be reverse-calculated from the syllable count n as floor(6×n÷8), eliminating the need for external length metadata. Leading zero bytes are preserved as-is. The decoder rejects non-normalized syllable counts or non-zero padding, strictly ensuring regularity.

Grouping and Prefix Stability

For visual and auditory convenience, syllables are grouped into pairs separated by decorative hyphens. For example, it displays as “zila-sibo-tiva-juzu.” Since the parser ignores hyphens, it treats “zilasibotivajuzu” as the same string.

Another feature is its prefix-stable design. Two inputs sharing the same input prefix will produce identical syllable prefixes. This ensures high affinity with trie structures and prefix-based search indexes, enabling prefix matching of keys without computation.

Variants and Reproducibility

A “variant” function is also proposed, generating multiple normalized syllable sequences for the same byte sequence. All variants are reversibly restorable to the original byte sequence, with style differences but no loss or addition of information.

Practical Context:

Generating “Usernames” for Nostr Keys

The origin of this research was the deterministic generation of “usernames” for Nostr npub keys. The underlying need is for a shortened representation of cryptographic keys that is more human-recognizable than hexadecimal notation and can be accurately reproduced with equal precision. Sing-song indicates the potential to simultaneously satisfy cryptographic completeness and ergonomic affinity for this need.

Current Status and Future Challenges

Currently, it is a v0.1.0 draft, with practical challenges remaining for use in English environments. The complexity of English consonant clusters and liaison may conflict with strict CV alternation rules. However, the trade-off of extending the length to approximately 2.7 times that of hexadecimal notation can be considered reasonable compared to the benefit of improved readability in specific use cases like transmitting keys over phone or voice chat.

Editorial Opinion

In the short term, Sing-song could provide a new option for cryptographic key handoff methods. Key sharing via phone calls or voice messages holds practical value in offline scenarios where QR codes or clipboard sharing is impossible. As prefix-based displays become common among Nostr users, the visual identifiability of keys is expected to improve.

In the long term, standardization of human-readable encoding schemes will lower the barrier to handling cryptographic keys at the level of daily life. As cryptographic applications expand to general users, the demand for “speakable” representations alternative to hexadecimal or Base58 will increase. The variant function’s design demonstrates flexibility in enabling personalization while avoiding key plaintext exposure, offering insights for key management UI design.

However, for this approach to be widely adopted, implementation libraries for multiple programming languages and security audits are indispensable. The risk of misauthentication during voice transmission is greater than with hexadecimal notation due to vowel ambiguity. Verification mechanisms against malicious syllable insertion or mishearing during silent listening should be addressed in future standardization processes.

References

• “Sing-song: a speakable encoding for long numbers and keys”, by blog.vrypan.net by vrypan — Lobsters, 2026-08-19T20:28:07.000Z (ARR)
• Source URL: https://blog.vrypan.net/2026/08/19/260819-sing-song/