delta

delta@codespeak.net

146 discussions

[delta-chat] postnote / single-account mode for chat and classic-email

by holger krekel

hi all, 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

5 years, 6 months

[delta-chat] Re: moving towards recommending dedicated accounts ...

by Thorsten Behrens

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 technical challenge. 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). Cheers, -- Thorsten

5 years, 6 months

[delta-chat] Re: moving towards recommending dedicated accounts ...

by ji-ef＠nikel.me

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: > hey, > > 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. > > holger > _______________________________________________ > delta-chat mailing list -- delta(a)codespeak.net > To unsubscribe send an email to delta-leave(a)codespeak.net

5 years, 6 months

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

by Marco Vittorini Orgeas

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/6YFH…>. 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

5 years, 6 months

[delta-chat] Re: moving towards recommending dedicated accounts ...

by Christian

Hi All, 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 email account! 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 :) Christian 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? > > Regards, > Enrico > > _______________________________________________ > delta-chat mailing list -- delta(a)codespeak.net > To unsubscribe send an email to delta-leave(a)codespeak.net >

5 years, 6 months

[delta-chat] Delta-XI: decentralization unchained (Kyiv, Ukraine, Oct 2018)

by holger krekel

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 ... Why Kyiv? --------- 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.

5 years, 6 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

delta