The ethics of how to properly allow users to send both encrypted and unencrypted emails was an issue. Sending encrypted messages and plain text at the same time

The ethics of how to properly allow users to send both encrypted and unencrypted emails was an issue. Sending encrypted messages and plain text at the same time will defeat the idea of security and privacy. if there is a thread with many members that have both unencrypted and encrypted-capable messaging, then the encryption is unnecessary and becomes worthless. Eventually there was an agreement that having unencrypted as default is bad. There had to be a way to increase the amount of users enabling encryption. Implementation was halted as the brainstorming of how to make this feature was sidelined as it was lower priority. 19 years later, users made another push to bring this feature into mainstream. Developers saw that they had enough time to brainstorm this low priority feature. the larger user base allowed this feature to be brainstormed faster. after a year and half of feedback, the main developers were able to have this fully featured. This final implementation will allow users to be encrypting messages more often and not need to disable the encryption. More users will be able to use this client and less frustration from users who are unknowledgeable of technology. If there is a need for only encryption, then it is possible. This "automatic" feature is more desirable than forcing the sending unencrypted to all. There is a chance a thread will only have encrypted-capable members, and accidentally sending an unencrypted message in the thread is a bigger problem to privacy and security. The final consensus is that sending of messages should be the responsibility of the user, not the application. The applications should always try to send encrypted messages. Unencrypted messaging should be the users responsibility as there is now a possible way to discern a thread has encrypted-capable members or not. TLDR: people argued whether it is bad or good feature, this was sidelined as low priority, users 2 years ago made a last push to implement this feature, They came to an agreement that responsibility of encryption is on message thread members and having unencrypted only is a worse option than the application sending encrypted where possible, feedback was collected on how the user experience should be implemented, and lastly the automatic selection feature was implemented. Users should still look into how this was implemented and give feedback on possible security/privacy concerns that may need to be implemented when the automatic feature is enabled. types of toggleable features that should be implemented and may not be is confirmation dialogues, message encryption per recipient/thread, visual indicators of received/sent messages being encrypted/unencrypted, and more. This is up to the developers to implement this to the GUI. I have not explored the new feature in its entirety.