[delta-chat] Recommending dedicated accounts: a follow up analysis

Hello list! This is for add my opinion about the proposed (?) "moving towards recommending dedicated accounts" change with the hope of reflecting a little bit more with the community about the implications of a move which I consider could hinder delta adoption as a communication tool and affect negatively the future of a project which finally brought a bit of fresh air in the exhausted world of so-called instant messaging. Apologize in advance for starting a new thread on the topic and this verbose intro: I came in a little late and started replying there, but I found myself half-way through the process a little bit confused because I was replying to different people, quoting different parts of multiple replies from the same persons while noting a difference in terminology used throughout the whole thread to refer to (I think) the same concepts, with the result of making my written thoughts on the topic a bit sloppy and unfocused. So for the sake of clarity, I am going to set a bit of terminology for the rest of the mail, because this is not an (exclusively) developers forum and as such I'd avoid technical jargon and referring to RFC(s), keeping the same technical level of discussion of the "original" thread. I will then use: 1. the term "chat message" to refer to an email message which carries additional delta-chat meta-data ( think an email tagged as "delta-chat enabled") 2. the term mail to refer to the "good old email messages" (as this one). 3. the term client to refer to any program which is capable of interpreting and acting upon chat messages. 4. the term MUA to refer to any email program able to access IMAP servers and send mails 5. the term contact to refer to a simple email address in the form user(a)domain.com 6. the term roster to refer to a list of contacts which one has "added" to its delta client, i.e. contacts with which there has been already at least one communication intercourse I haven't yet had the opportunity to study the lib-delta API, but as I understand the overall architecture by using the mobile client (the only usable client ATM), there has always been a big *scope* issue with delta project, which can be resumed with the following question: are we building a series of reliable delta clients to enable seemingly instantaneous communication over the good old email infrastructure or instead just a bunch of new fancy MUAs to sugar coat the email experience ? The problem is that delta client is also capable to act as MUA, and doing so while declaring to have a IM scope, is the root of all the recurring problems and relative source of confusion among users. Also, I think the issue is framed incorrectly as "shared" vs "exclusive" account, because we already allow "exclusive" accounts: the topic would be better described as "filtering" vs "non-filtering" the INBOX. Looking the thing from this perspective the problem is quite clear to me: the clients should just act upon chat messages and don't touch anything else! Then mails from somebody in my roster would be simply ignored by delta clients, because who sent that mail expect myself to reply with the standard email timing, is not chatting with me. If he/she wants to chat with me, he can use an desktop/mobile client and use its standard email log-in credentials to start sending chat messages to me. If we should really support the "chat initiated by a contact using a MUA" use case, we could look for an extra well-defined text template in the subject/body added by the MUA user (some MUAs can add custom Headers generally requires some level of expertise from the user) or better, allow an additional field to specify email alias(es) which receive chat messages even from "external" contacts who may want mail messages to be replied with a chat timing. This would reliably support the filtering of chat messages and allow clients to exchange chat messages over the existing infrastructure without getting in the way of the "normal" email relay/store operations. The only minor annoyance which would remain with filtering is the possibility to access the account with a MUA and see a bunch of encrypted chat messages not yet sorted; in this case to ameliorate the user experience we could add some text note in the subject/body to suggest that this is a "temporary" email and to use a delta client to read the content. Now, the proposed solution of stopping polishing the existing filtering capabilities while inviting new users to open another email account to have a reliable experience is a bit like going the other way round to tackle the reported issues and could confuse even more the scope of the project, IMHO. Furthermore I am quite certain this would affect negatively delta adoption pushing forward the impression that there is yet another account to open to use the client, which is the same thing for using a Jabber/XMPP client. The vast majority of people (at least in my country, but looking at facebook/what's app numbers I think it's a global trend) greatly ignore privacy related topics and is sooo lazy that won't mind install another app to stay safe, never-mind open yet another mail account! I have directly experienced this a number of times and the same concerns have been exposed quite effectively by Enrico and Christian <https://lists.codespeak.net/hyperkitty/list/delta@codespeak.net/thread/6YFHHVB5ERA6O63UON>. Last point: I've also read about network/power usage concerns for filtering the INBOX: on paper this is normal as the email protocols weren't meant to accommodate very constrained resources scenarios, but heck IMAP was already rocking at the time of 56k modems and ISDN lines and I doubt delta is the only app running and draining resources on user devices, so in absence of factual data I think we should concentrate on other issues like giving the and then start thinking about solutions like aggressive caching etc.. Hoping to have not annoyed you too much. -- Marco