Thank you for the feedback! Some notes: > The obvious feature gap I see is that it should be possible to provide both the encoder and decoder with a common "co

Thank you for the feedback! Some notes: > The obvious feature gap I see is that it should be possible to provide both the encoder and decoder with a common "context" or prompt to preload the LLM with. There's no option for this in the CLI interface, but you can modify the context in `src/textcoder/coding.py` by changing the `_INITIAL_CONVERSATION` variable. Right now it's configured to ask the LLM to output text in the style of a tweet. > You may want to encode the user's data backwards so that it's easier for users to make arbitrary changes to their message to escape bad covertext output. A random 16-byte value is prepended to each message to serve as the KDF salt and the AES-GCM-SIV nonce. This has the additional benefit that every output is always different, even if they encode the same message. So if the covertext is bad, you can just re-run it to get something different. > Might also be fun to offer to use the an LLM as a compressor for the text before encrypting. A similar project, https://github.com/harvardnlp/NeuralSteganography https://github.com/harvardnlp/NeuralSteganography does exactly that and achieves very compact results. However, I was a bit weary about compressing before encrypting given the possible security risks associated with that pattern.