Daniil Katsura

TrueLock and VeilType now approach the same encrypted-capsule workflow from two sides.

VeilType protects text, voice, photos, video and files before they enter the messenger. TrueLock focuses on protected capsules and controlled opening after content has been shared.

The integration question is not whether both products can encrypt. It is whether a person can create a capsule on Android, send it through an ordinary channel, and open it predictably on another device without a proprietary cloud or account.

We are choosing the next compatibility run:

VeilType launches today, and I m looking for people willing to test it critically, not just glance at the page.

The workflow is: type or attach content -> encrypt locally in the Android keyboard -> send through an existing messenger -> open offline with a password or recipient key.

Please try to break one part of that flow: text, voice, photo, video, file transfer, or offline opening. Tell me where it becomes confusing, what trust evidence is missing, and which Android device or messenger you used.

Launch page: https://www.producthunt.com/prod...

What would make you trust an Android keyboard that claims to encrypt your typing before it reaches the chat app? I m testing a different UX: encryption at the keyboard layer, before plaintext reaches the chat app.

The difficult problem is not adding an Encrypt button. It is trust. A keyboard can see sensitive input, so enabling a third-party keyboard should require unusually strong evidence.

If you were evaluating this idea, which signal would matter first?

A. A two-device demo: type encrypt send open offline