Wrt “redaction & modifying member list” i have a proposal: feat: Don't send system messages to unencrypted groups by iequidoo · Pull Request #6933 · chatmail/core · GitHub. There’s a narrower discussion where you can see also why previous attempts to solve this were rejected. So this is not what we don’t want to support, but what was (temporarily) removed for technical reasons.
Aside from individual avatars, the ability to set a subject in 1:1 chats with non-DC contacts would be important to me. If a non-DC contact sends me a message with a subject, my replies will have the same, even if I don’t copy the old message. This can cause problems if, for example, the subject is “Appointment rescheduling” and I want to wish that person a happy birthday.
The mail would have the subject “Appointment rescheduling”. So far, I’ve always switched to a regular email program to change that.
Actually I only need these two things (avatars, subject in 1:1 chats) to communicate properly with non-DC contacts.
In my experience, groups don’t make much sense, as they quickly become confusing for non-DC users. Even before DC, I rarely sent an email to several people at once. If I did, it was only to share specific information and not to start a discussion. The classic email interface just isn’t suitable for this. To share information with multiple people, the old broadcast lists would be sufficient.
Also encryption isn’t that important to me for non-DC contacts. The main thing is that everyone is reachable. Autocrypt doesn’t work anyway, as I don’t know anyone who encrypts emails outside of DC. Of course, I would never transmit sensitive information that way, but objectively speaking, most of what I write during the day is quite trivial.
Btw, I have an idea how a subject could be implemented in 1:1 chats without UI changes, but I haven’t written a proposal yet, as I had the impression that classic email support was being scaled back, making it pointless.
That’s exactly what convinced me back then. With every new messenger, the question arises: how do I get my contacts to switch as well, or at least install an additional app? If it hadn’t been possible to simply communicate via email, I probably wouldn’t use DC today, since I’ve had almost exclusively non-DC contacts. Therefore, I think it’s important not to abandon traditional email support and not to degrade it.
But if there are plans to gradually reduce this support, it would be better if one would say it openly and drop this feature. So the users, for whom it is important, would not give themselves false hopes.
I now communicate with my non-DC contacts via WhatsApp. ![]()
You can create a “New E-Mail” (technically an unencrypted group without a Group-ID) with a single contact. This is a way to set the subject and start a new email thread that does not reference previous one.
Thanks, I’m aware of that. But if a non-DC contact changes the subject, it appears in the 1:1 chat. Unless the contact has previously only replied and is sending a message with their own subject for the first time. This email will then be displayed in its own chat. Any subsequent changes to the subject made by the contact will only be displayed in that chat.
Furthermore, the chat list becomes quite confusing over time if a separate thread is created for each subject, especially if all these threads have the same avatar.
Sad to hear that the project direction changed and drifts away from the “mail chat”.
I am a newcomer (but a long-time lurker) and I was looking for ways to engage people who only know how to share a photo via Whatsapp or Telegram or Instagram and find sending a picture via email difficult.
Now I know that I should not attempt trying to integrate email workflows with the chat.
I realized that the problem report I have posted Why did I lose encryption to the user in a secondary chat? where I am told that having multiple chats is going to be new normal is probably related to the change of direction being discussed here.
I guess the problems I see are related to the so-called introduction of “key contacts” and frankly I find the way the database schema looks like now is really confusing (key_contacts_map wtf).
I do not see this revolution being explained in the change log or anywhere much else (except for the pull request I have just found writing this).
key_contacts_map is a temporary table used during migration and is not a part of database schema used normally.
key_contacts_mapis a temporary table used during migration and is not a part of database schema used normally.
Thanks. And the rest? Why the same contact is twice in the contacts table? (I thought they are connected via key_contacts_map together).
I found this out the hard way.
I need to figure out why it’s not reading my phone’s address book now, and the experience with regular email isn’t the best. For classic email, I reverted to 1.58.4. I don’t know if I did something wrong, but with classic email, DC is unusable. ![]()
So far I have not been able to use version 2 because there are problems on my pc (fortunately I had done a test by copying DC data otherwise I could not go back to the previous version).
For that reason it’s a little difficult for me to get the point, however reading the changelogs I can’t figure out what happened that was strange, if chatmail accounts can now only work with encripted email I don’t see a problem, chatmail servers were born to have better DC performance and allowing accounts to be registered without prompting as chatmails do would have been abused by those who wanted to use them to spam common email accounts.
So imho the decision seems very appropriate but if someone uses a regular email account, it seems to me that nothing has changed except the email icon? or not?
Because it is precisely that part that ensures the interoperability of DC and on closer inspection also the decentralization.
One has to imagine that as long as I can use any normal email box I can easily evade censorship, but if it is necessary to host me a specific server just for DC then from having thousands of possibilities it reduces to having just a handful that could also be targeted of data supply claiming or shutdown.
If, on the other hand, encryption has been disabled between users who both use DC as their normal email client, this I do not think is a good idea for the same reason as above.
If DC ends up running encrypted only on chatmails, what would be the advantage of using DC over other messaging clients?
At that point it becomes a matter of having to make compromises to support ancient servers system but not being able to take the advantage of being able to use indiscreetly all servers already available
We are under the threat of chatcontrol but let’s not forget that email service providers are also forced to maintain and provide informations about the emals exchanged, and not being able to encrypt them would become a disadvantage.
If DC ends up running encrypted only on chatmails, what would be the advantage of using DC over other messaging clients?
this is not the case, and this is also not planned.
you can use Delta Chat as always with mostly any provider, this has not changed.
what has changed is the displaying and some functionality of unencrypted emails, for good reasons, see above, no need to restart that discussion ![]()
While this is obvious from the overall project goals, the phrasing in the FAQ is ambiguous and may be contributing to confusion.
For clarity, I suggest editing FAQ - Delta Chat like this:
Original
If you instead create a profile using a classic e-mail server, you can send and receive messages without end-to-end encryption. Such messages lacking end-to-end encryption are marked with an e-mail icon
.
Edited (edits marked)
If you instead create a profile using a classic e-mail server, you can send and receive messages with or without end-to-end encryption.
Such mMessages lacking end-to-end encryption are marked with an e-mail icon.
thanks for the suggestion!
i created a PR at make clearer, that non-chatmail is supporting e2ee by r10s · Pull Request #1173 · deltachat/deltachat-pages · GitHub - @y-ZZ-a would that have helped you in case you read the FAQ before?
I had actually read it and that’s exactly why I was saying that it didn’t seem to me that there were any decisive changes for classic emails and I couldn’t understand the motivation for the discussion so I started making wrong assumptions.
really if there are no other implications, it seems like an improvement to me ![]()
I use Delta Chat primarily as a “normal” email client, and I use it for work because no client can beat DC’s immediacy. I’m away every day for work, and DC is incredibly useful for responding to customers in real time or sending communications via Channels (broadcast lists). ![]()
I’m sorry to hear about this dire situation, not that mine is any better; in fact, I’m close to closing my company.
Let’s hope for a better future, adb!