tgalal

The server does see the audio during processing (that's how GPU transcription works), but the final stored transcript is encrypted with a key derived from your password that never leaves your browser.

You conveniently omit mentioning that the server also sees the transcript before returning it to the client side browser. Whether it is "immediately" erased, is something the client must trust the server to do. You might as well save yourself the roundtrip by encrypting server side, returning the key, then deleting it, same outcome.

Every time I see the term "Zero knowledge encryption" something dies inside of me, as "Zero Knowledge" is not a property of ciphertexts but proofs. But this has seriously taken things up a notch: the server learns both plaintext audio and and transcripts. So that's literally "full knowledge" encryption.

Just drop encryption altogether, the server is trusted anyway. It adds absolutely no guarantees on anything than without the way encryption is currently performed.

The point is to avoid installing tools or granting LLM access and the "steering wheel" on the server itself. The data you pipe is the same data you'd copy-paste into ChatGPT or similars anyway. There is certainly bit of latency when piping/reading a lot of of data into the context, as everything is tunneled through the local machine, but I'd argue that the context size being limited by the llm itself makes it acceptable for most use cases.

I wanted a "seamless" way for executing llm prompts in my terminal for recurring tasks, and came up with this:

http://github.com/tgalal/promptcmd

The cool thing about it is that it also works over remote ssh shells, so quite handy in managing my homelab.

Hi HN, I’m the author.

I built promptcmd because I thought prompts can be neatly integrated into CLI and look like familiar commands, rather than being run "via a tool" (explicitly).

promptcmd lets you define prompts as files, compose them, and run them like native commands.

Happy to answer questions, especially around design tradeoffs or missing features.

At this point, we could try to review all of curve25519-dalek for implementation flaws, but that would take a long time and make for an excruciatingly dull read

At some point in the future, I should review curve25519-dalek in detail to ascertain its quality.

Not sure if you noticed, signal uses their own fork of curve25519-dalek with "lizard" extension, IIRC primarily for groups: https://github.com/signalapp/curve25519-dalek/tree/main/curv...

I guess the diff makes an easier starting point than the entire library.

Thank you for the always very informative and insightful posts!

I own 3 of the affected repos:

Yowsup https://github.com/tgalal/yowsup MIT License

It is a library that implements WhatsApp's protocol. It is built on community effort of reverse engineering WhatsApp's protocol. I created this in first place to bring WhatsApp on an unsupported platform (Nokia N9/ meego platform)

Wazapp https://github.com/tgalal/wazapp GPLv2 License

This is a UI frontend to Yowsup for Nokia N9. Nokia N9 is the only smartphone produced by Nokia which never got WhatsApp support. I created this client because I wanted to use WhatsApp on my Nokia N9. The code is totally decoupled from Yowsup, and does not use WhatsApp in its name. You can see its icon here http://everythingn9.com/wp-content/uploads/2012/05/wazapp.pn... which for me looks different enough from official client's icon.

OpenWA https://github.com/tgalal/OpenWhatsappBB10 GPLv3 License

This is also a frontend to Yowsup, but for Blackberry 10. It is a little bit similar case as Wazapp. I created this for BB10 when WhatsApp initially said they're not supporting that platform. Again, this is decoupled from Yowsup, has same icon as Wazapp. Its name though on Github is OpenWhatsappB10, as a project name. However, the real app name is OpenWA. Perhaps a rename of the repository would be sufficient ?