So it's becoming clear that a lot of people here (and also outside this list)
highly value that DeltaChat can be run in "single-account for chat and classic e-mail" mode.
Be assured that it's not going away over night and not without further consultations.
This anyway was all more about recommendations, what to tell would-be-users.
However, we'd like to suspend the discussion until Xenia and vadym can contribute.
They have done 16 needfinding interviews in Ukraine, and are also preparing two
user-testing sessions later this month in Ukraine. Both are, however, busy
finishing up other projects and thus can not immediately participate right now.
We are going to soon have team-discussions (also with people in Ukraine) about
development directions for the next half-year.
So thanks again everybody for the good feedback! It's great to hear that you are heavily
weighing in when you feel the project might move into the wrong direction.
Please in turn recognize that there are "only" 10-20 people who are working to bring
Android, Desktop and iOS versions to public releases, along with caring for
user-support, translations to many languages, building/packaging on five platforms,
researching and introducing new ways to shield against MITM attacks,
organizing travels and gatherings, writing funding proposals and organizing them,
instigating mailing-list discussions, UX and user-testing sessions ...
... many of them are not directly paid (and others not "adequately" by far if you take the market
rate for the kind of great expertise coming together to evolve the current Delta efforts)
and several of them are doing this on a few hours-per-week basis. There are limits to
what can be achieved even if something is a good idea ... and luckily there is a great overflow
of good ideas with Delta currently ;)
So what we ask for is that when implementation or other concerns are raised please try to take
them as seriously as we try to take everyone's feedback. Part of that is understanding where
the other side is coming from. And part of that is balancing usability, implementation, crypto
and several other concerns and efforts -- none of them always trumps the other.
With this, a good weekend everyone :)
holger and bjoern
Nick Thomas wrote:
> If I set a non-technical friend up with delta, I also don't want to
> have to start the conversation with "just create another account". I
> worry that would harm adoption.
Yep. Can't agree more.
Note that this is a purely product/marketing POV - I appreciate the
Hard to say what's the larger prob - losing users at the top of the
funnel ("can't be bothered to set this up"), or later during heavy use
("ugh, this is so confusing with mail showing up in triplicate"). But
my instincts would always prefer getting maximal adoption initially;
much easier then to get data on why users leave (and do the math from
above without much guesswork).
I'm also on this tiopic's general trend side.
Telling users to create a new mail address for use with DC --IMO--
completely destroys the rationale behind DC at all.
Also, as pointed by a user here, why not try to improve conversation
threading and let advanced users the choice to DC's "Inbox" folder ?
holger krekel wrote:
> last week Bjoern visited for a couple of days and among
> other stuff we discussed "shared" versus "dedicated" accounts.
> Shared accounts are ones which are used by both traditional
> e-mail apps (Thunderbird, Webmail, Outlook etc.) and DeltaChat.
> Whereas dedicated accounts are ones only used by DeltaChat.
> There has been a lot of negative feedback related to "shared accounts" ...
> just the freshest one from today's IRC from a new user dropping in:
> if I send a chat to Joe, he answers, he is on my contact list.
> Then he sends me a normal email, it will show up in Delta chat, which I
> don't expect to, unless it is a reply to the chat.
> This is "expected" from the implementation side: if you accept
> a contact (opening a chat with a contact implicitely accepts the contact)
> then all messages, including new "threads", from/to that contact
> are "owned" by deltachat.
> Then, the logic / implementation which moves messages from
> the INBOX to the DeltaChat folder has issues, which lead
> to messages remaining in INBOX which should be in DeltaChat.
> the current 0.20 Android version is known to have issues with it
> but they haven't been found yet.
> So we have both user expectation mismatch and implementation
> complexity issues here. The Move-to-DeltaChat actions also
> cause extra network requests, on a side note.
> Therefore we think it's better to move towards recommending
> **dedicated e-mail accounts for DeltaChat**. You may still
> use it "shared" but there will be no features or much development
> effort sunk into it.
> One problem with dedicated accounts is that people can't
> easily use their address-book to get into contact with each other.
> There is a potentially nice mitigation for this. Let's presume
> that when you setup DeltaChat with your dedicated account
> you may specify your traditional e-mail address so that
> DeltaChat knows about this address. Then ...
> - if you receive a mail on the traditional e-mail address
> (with any MUA/webmail) you can forward it to your DeltaChat
> account which will automatically open a chat with the
> original poster. You will see the original poster's message
> and can type a chat-reply. The original poster will see messages
> coming from the dedicated chat address.
> If the poster now also fowards the chat-mail to her
> delta-address (if it wasn't already a delta-address!),
> the two delta's would be talking with each other through
> the dedicated addresses only.
> - People with dedicated accounts wouldn't get "surprising"
> e-mail as contact requests. Also there is less chance of
> dropping back to unencrypted communications because we saw
> some non-autocrypt mails from a webmailer/thunderbird etc.
> - DeltaChat could mark contacts/email-addresses if it
> saw >99% DeltaChat messages with it (maybe a small "delta" or so),
> allowing to make a choice if you want to contact someone
> via the delta or their "normal" e-mail address.
> - DeltaChat can make it easy to share things with the "tied"
> normal email address to send attachments/pictures etc.
> DeltaChat would then stop to do the move INBOX -> DeltaChat
> folder thingie. You could still access your DeltaChat account
> with thunderbird/gmail-web interface etc. but you'd see
> the DeltaChat messages in your inbox. Gmail for example
> would condense 30 replies into a single line so maybe
> that's not so bad.
> Note that the question of dedicated versus shared accounts
> does NOT have any effect on DC's ability to contact other e-mail
> addresses with arbitrary non-Delta MUAs -- that's fully continuing
> to work and be supported.
> so much for now ... feedback welcome.
> delta-chat mailing list -- delta(a)codespeak.net
> To unsubscribe send an email to delta-leave(a)codespeak.net
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
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
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
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
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
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
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.
first of all I strongly support the idea of Enrico:
The beautiful idea of Deltachat is that You can use it with your
*existing* mail account and present and use email simply in a new and
easier presentation form for most simple use cases.
There should not be any additional workload (wall!) for users around
to use it, even in collaboration with a standard mail client.
Especially that shared usage is in my eyes the fundamental new approach
and advantage of Deltachat!
From my own user experience I can confirm Enrico very well that most
users I could convince by now to try Deltachat, never would have tried
it if there had been the additional wall around usage with a dedicated
Second, all efforts in development should go in a direction to make
different use cases possible, but simplify (shared) mail account
handling as much as possible.
Maybe one of the most important thoughts not yet verbalized clearly, I
see from all the discussions at github and here:
Deltachat should *not* try to be an email client which tries to handle
and manage any complex folder structure at IMAP server!
This makes development, IMAP communication and sync for multi client
usage more complex than needed!
Current approach tries to support this more or less (polling of many
folders). But is this the right approach? Would it make sense to
simplify this? This would help to use a shared account :-)
Have a good night :)
Am 06.10.2018 um 08:32 schrieb Enrico Bella:
> Hello Holger,
> Il giorno ven, 05/10/2018 alle 12.37 +0200, holger krekel ha scritto:
>> Therefore we think it's better to move towards recommending
>> **dedicated e-mail accounts for DeltaChat**. You may still
>> use it "shared" but there will be no features or much development
>> effort sunk into it.
> I talk as an user, not a developer. It's a bad idea IMHO. An email
> accout is still felt as something personal and "complex" to create. I
> think that a lot of people whom I suggested Delta Chat would never
> tried this app if they needed a new email account. I'm pretty sure
> about that.
> The beautiful of Delta Chat is that you can use it with your *existing*
> email account and start/stop to use the app whenever you want. I'd be
> the first one to have never tried Delta Chat if I needed to register a
> new email account or have to suffer "bugs" if used with my current
> email account. What's the difference between register a new email
> account just for DC and register to Proton Mail that already has
> encryption? Delta Chat IMPROVES something you ALREADY have. Transforms
> something "old" to something "modern". This is the strenghtness of this
> app and why I love it.
> In this way you will force the user to choose between:
> 1 - Register yet another email account (They probably won't do that)
> 2 - Use the current email account knowing that the app has bugs and
> doesn't work as expected (They probably won't do that)
> I'm talking about new low/mid-skilled users as I am. If you want to
> target mid/high-skilled users this choice could be fine.
> I'm sure that you have valid issues that bring you to this decision,
> but I just wanted to show you my doubts about this choice. There is
> really no way to make it work better with an existing account?
> delta-chat mailing list -- delta(a)codespeak.net
> To unsubscribe send an email to delta-leave(a)codespeak.net
End this month there is going to be a gathering of DeltaTeam and friends,
in Kyiv, Ukraine. So far some 15 people committed to travel to Kyiv for
a week ... if you are interested to join don't hesitate to contact
me or Xenia (e-mail or IRC, i put her in CC). We have a few shared
flats and it's still surprisingly (?) cheap to travel to Kyiv ...
Base metadata of the gathering
General Location: Podil Quarter in Kyiv, Ukraine
Overall Timeframe: Sunday, Oct 28 --- Monday, Nov 5th
Base camp: 150qm 2-story flat for hacking/discussion sessions and hanging out with people from different decentralization projects and angles. The terms and spirit of https://autocrypt.org/code_of_conduct.html applies for this weeklong event.
Talk/Unconference: at IZone full Saturday with more public, mixed talks and sessions, carefully advertised within interested circles in Kyiv
Side events: user-testing sessions with journalists/activists, saturday night halloween party and more ...
What is "Decentralization Unchained" about?
Decentralization means more and often something different than what is
happening in the online blockchain worlds. Instead of building
"solutions" in a top-down approach, guided by stereotypes of an "ideal
user in a vacuum", we try a format where especially western hackers meet
users and their not-typically-western mixed environment. The delta.chat
team is planning at least one user-testing half-day to try out some of
their current developments with Ukrainian testers. But also casually
meet with the local Ukrainian IT community, providers, hosters,
developers, people working on mesh or fighting Internet censorship and
surveillance in their country. During the base one-week event, people
will work on their respective projects but also with one another, mostly
driven by informal chat -- getting to know each other and what's
happening. People are attending who work on secure messaging / email /
networking / hosting / crypto and share a love of decentralization (p2p
and/or federation), free software, resilient communications, thinking
beyond tech, off-the-grid, mesh, activism, arts of not being governed,
self-organizing with life, tech and beyond ...
Delta-XI happens in Kyiv, Ukraine, because decentralization is not just
a technical idea but also about social and geographical de-centering.
Ukraine is currently going through a challenging process of political
transformation. Four years after the Revolution, how did people manage
to maintain their infrastructures? How do they work with the internet
and how do they try to defend Internet freedom? What are their needs in
terms of secure communication and how can we help? One of the goals of
this event is to actually meet with people who really need and will use
our technologies: local journalists going to war zones in the East of
Ukraine or to the annexed Crimea; activists facing the right-wing
uprising in big cities like Kyiv or Lviv; and human rights defenders
working everyday with war refugees or other at-risk groups.