I have seen the same. Seems that the envelope icon is given when non-encrypted chats (in the past) are found within the group, even the current group members are members with encryption keys.
Group chats are converted to unencrypted group chats when one of the members does not have a key or in a “reset” Autocrypt state which happens when you receive an unencrypted message from such contact. In this case most recent messages sent to the group are usually unencrypted.
This does not depend on the message history, only on the Autocrypt state of upgrade.
It is not possible to turn unencrypted group into an encrypted group. Unencrypted groups have email addresses as the members and encrypted groups have essentially OpenPGP keys as the members. So even if you clone the group after upgrade and remove some members, the cloned memberlist consists of email addresses without the keys.
If someone upgraded at a different point when the group was encrypted, they can send an encrypted message to the group and you will receive this message in a new group, but the history will remain in the unencrypted group. If the group was not encrypted for everyone, then the simplest solution is likely to create a new encrypted group. At least with 2.x this will never turn unencrypted.
Thanks - would it make a chat group encrypted when we archive our current, non encrypted one, then create a new one with the same participants? (With each of them I have a one-to-one encrypted chat additionally.)
Once you create encrypted group in v2, it stays encrypted. Old unencrypted group with grey avatar you can archive if you want, but it does not matter what you do with it. Archiving is local to your devices.
I don’t think that your client knows that the unencrypted and encrypted contacts are the same person, even if they are named the same. In theory you could link them, and automatically create a new upgraded group that is an encryption-added version of the old one, but this does not exist and is probably not worth the trouble.
So you have to manually add a new group, then add your encrypted contacts to it. I do not know of a way to export or port a chat history, so I think you would lose the history.
Key-contacts still have an email address, this is where the messages are sent. For each email address there is always a single address-contact. But you cannot convert an address to key-contact because there may be multiple key-contacts with the same address. In v2 encrypted chat memberlists consist of key-contacts, so we don’t have to convert addresses to keys all the time using Autocrypt states.
Getting rid of tracking of address relation to keys is the main reason for v2 changes. Maintaining bindings of addresses to keys and treating addresses as the primary identity (rather than keys) is a huge source of complexity. E.g. in Proton Mail contacts have addresses and addresses have keys, so you can verify address relation to keys, but nothing verifies relation of contacts to addresses afaik. They also implemented key transparency scheme that matches addresses to keys: https://transparency.dev/pdfs/summit2024/Key%20Transparency%20Proton.pdf By not having to match addresses to keys we also don’t need to have such key transparency as contacts are directly identified by keys.
But fundamentally I care about the relation of keys (or whatev) to people. Is there a person-based identity that can have multiple keys? Or how does key rotation work?
Key-contact represents a primary key. If primary key changes, you get a new contact. If someone has two primary keys, they are represented as two key-contacts.
Key rotation usually means rotation of encryption subkey. This does not change primary key, so the contact will still be recognized as the same. There is currently no key rotation in Delta Chat, as in, it does not generate new encryption subkeys. There is more discussion of this in
As for replacing primary (identity) key, there is a draft draft-ietf-openpgp-replacementkey-04 - OpenPGP Key Replacement but otherwise I am not aware of anyone doing identity key replacement in OpenPGP or other messengers yet. Main reason for this OpenPGP draft is making a way to eventually migrate to OpenPGP v6 and post-quantum primary keys.
Thank you for the links. This is clearly very complicated and in the process of being standardized, which I hope will abstract some of the detail.
Device keys sound a bit closer to a personal identity; a person may not be specific to a device, but the device (or user account) is usually specific to a person.
And I suppose manually arranging key rotation with other humans is still an option.
Okay, after all it seems that you can’t simply make an old group encrypted but starting over with a new group of the same participants would do so automatically. Thanks.