Open link2xt opened 9 months ago
yes, maybe that's better, not sure. cc @Hocuri @hpk42 ?
it could worsen ux, as the existing and described patterns to create "green checkmarked" groups do no longer work unconditionally. not sure if that is a good tradeoff.
if we want to go for that, we need to do the same on desktop/ios and probably do that post-1.42
but maybe also wait a bit if that really becomes an issue?
On Mon, Nov 20, 2023 at 07:02 -0800, link2xt wrote:
Especially if user disabled encryption preference and creates a group only with self, creating it as verified group and encrypting anyway looks wrong.
maybe remove the setting completely? Autocrypt does not mandate that we offer the setting.
I think we wanted to keep the setting, but turn it into "disable encryption" and not even send Autocrypt header in this case.
On Mon, Dec 04, 2023 at 06:38 -0800, link2xt wrote:
I think we wanted to keep the setting, but turn it into "disable encryption" and not even send Autocrypt header in this case.
well, but then we could rename it to "disable encryption" without any autocrypt-reference other than to say neither autocrypt nor guaranteed end-to-end encryption will not work anymore.
What about this:
there has been requests from the past to allow to completely disable encryption, now with the encryption "guarantee" for some it means a sticky guarantee annoyance, the option as it currently is was always useless and not fitting users expectations, it is not about to remove it tho, but to make it do what people need it to do, "disable encryption"
What's the use case for a disable-encryption-setting, and how often does it occur?
Personally, I sometimes needed an option to force-once-unencrypted when sending messages because I wanted the recipient to be able to read the message in webmail. I never needed a disable-encryption-setting.
Note that the costs to this setting are quite high:
In general, we may need to make sure that we're not supporting too many use cases "a bit" at the cost of making things work smoothly.
What's the use case for a disable-encryption-setting, and how often does it occur?
in the past it was the main reason for DeltaLab to exist, at the time called "Delta Chat Lite" because it disabled forcefully encryption not sending encrypted messages or autocrypt header saving a lot of data plan etc.
also in the forum you can find information about people requesting this:
some advantages of disabling encryption:
That said I agree with the new "guaranteed e2e" things got more complicated for adding a "disable encryption" option what is easy to agree upon is that the current "not prefer encryption" option is pointless and everyone things it means "disable encryption" because otherwise it doesn't make any sense, so we can remove it and hope we can add a "disable encryption" option at some point if problems/reports pop up about the sticky encryption
shall I create a PR removing the setting from android? cc @r10s
Especially if user disabled encryption preference and creates a group only with self, creating it as verified group and encrypting anyway looks wrong.
about the main topic/issue of this post, what I did in DeltaLab was that if the group has only self as member then I show the dialog asking if you want to create a greencheckmarked chat
shall I create a PR removing the setting from android? cc @r10s
i just moved this issue from "android" to "interface" - let's first see what we really want. if it is about "disable encryption", it does not make sense to remove the setting from android - but we would also need some changes in core probably
Especially if user disabled encryption preference and creates a group only with self, creating it as verified group and encrypting anyway looks wrong.