Tell the Whole Story: Voice Notes are Here!
Now live in version 3.1.0, private voice notes have come to Germ DM! Never skip a juicy detail again. Tell the whole story—just tap record.
With voice notes, we’ve brought private voice communications to the 45M-user AT Protocol ecosystem across Bluesky, Blacksky, Mu.Social and more. We’ve also used this opportunity to extend our architecture around private attachments, leveraging our protocol to protect your privacy and lay the foundation for self-hosting your transport.
Using Voice Notes
Germ DM users can now send private voice notes by pressing the microphone icon at the right side of the message compose bar, visible when nothing is typed in. Transcription occurs automatically using Apple’s on-device language model, protecting your data from ever leaving your device. Voice memos are automatically deleted 5 minutes after listening in order to protect your data storage, but can be retained in the conversation by clicking “Keep.” You can also turn off auto-deletions, and delete individual voice memos, from a new Storage section in your Dashboard.
Updated Technology
Voice notes follow our implementation earlier this month of Quantum-Secure Encryption with continuous rekeying, protecting your text and voice data from being harvested now and decrypted later by a quantum computer. All voice notes are quantum secure, and can only be sent in active quantum-secure conversations.
Voice Notes also sit atop an all-new attachment architecture, detailed by our CTO Mark Xue in this thread.
First, instead of encrypting the whole audio message as a single ciphertext, we’re using segmented encryption. This allows you to play even partial downloads, useful when you’re in poor connectivity. We also use it to encrypt audio at rest, so that we can stream your memos when reading from disk.
Our technical advisor Nick Sullivan authored a CFRG draft that builds on the state of the art in this field. We implemented Random-Access Authenticated Encryption in Swift**,** available on our GitHub here. We export the content encryption key for raAE from MLS using Nick’s mls-attachments draft. We’re grateful to Nick and the many folks whose work underpins standards-based cryptography for expanding access to these tools.
Second, we updated our Authenticated Communicator Protocol (on github here) to accommodate decentralized E2EE attachment relaying.
Under the standard architecture, a sender wraps their attachment in symmetric encryption, upload the ciphertexts to their server, then send the content key over the E2EE channel. In a decentralized environment, however, the sender hosting the ciphertext provides a read receipt when the recipient fetches it, compromising the recipient’s privacy by exposing their behavior.
The assigned mailbox pattern of our AC Protocol lets us improve on your privacy here. On ACP, mailboxes are all assigned to specific recipients. We extended our protocol to assign mailboxes with a corresponding symmetric key, so that attachments from authorized senders are stored on the receiver side, up to a certain maximum storage cap. This also prepares the ground for mailboxes to be hosted by a user's chosen server, much like a PDS is a user's chosen publisher of public data on the AT Protocol that underpins Bluesky.
In the meantime, you know what to do. Press record!
