Probe existing email contacts upon installation for easy onboarding

  • A user would install DC
  • On first start, DC would scan for email addresses (along with fingerprints and public keys) in the device address book, the IMAP folder of the DC accounts of the user and possible further “external” IMAP accounts (not otherwise added to DC). If any entry has an email address not known to DC, DC would send a probe email to it.
  • If DC on the other side accepts this contact and proceeds with encrypted communication, extend the device address book entry with the public key and connect it to the contact profile within DC (a separate feature request?)
  • Otherwise mark this contact as ignored
  • Such a scan may be repeated periodically

The following issue asked for something similar, but it was marked as solved without fixing the main request:

1 Like

Further contact list integration, sync, import and export related issues:

1 Like

We had this feature for scanning fro the IMAP folder before, but it was just removed:

There are practically no public keys sent unencrypted in the latest versions of DC, so you will not be able to collect anything other than email addresses this way.

This will just spam all non-DC users with probe emails asking to send back the key. We also normally don’t reply back automatically to anything. During SecureJoin we reply, but only if a known “invite code” from the scanned QR code is sent.

2 Likes

Note that the account of the existing phone and IMAP contacts may support one or more of:

  • WKD
  • Autocrypt
  • HKPS

Autocrypt headers and public key attachments could also be scraped from the IMAP inbox without requiring to send a new ping mail.

A DC user may also have the choice to submit their key to HKPS hosts.

Given how often such requests are raised on the forum (many linked), are you sure dismissing it immediately is the best course of action?

At the same time, the feature of notifying your email contacts who you could not upgrade about you joining DC and telling them how to encrypt your connection could also be useful to some. Many messaging apps and social networking services supported such a feature in the past. The key here is to skip those who you have already contacted about this or have already added. DC should also pop up a list of checkboxes for each proposed person, so the user could confirm echa before sending a ping.

1 Like

I think most of the proposals have outdated assumption about how DeltaChat works, i also just realized it with the closing of WKD topic, that DeltaChat won’t publish the public keys:

So with that, we won’t realize if that contact actually use DeltaChat.

I think at this point, if DeltaChat still support sending email to classic-email (see FAQ - Delta Chat ), we can just auto generate an invite link to chatmail in the footer of the email, so the other party will realize that they can continue the conversation at DeltaChat.

So with that, side-stepping the possible spamming if we just automate the probing.

Note that the WKD topic contained too many off topic messages, and the closing reason mentioned that chatmail is not planned to support WKD right now.

However, the other aspect was not addressed there: adding support for looking up WKD of a new contact (i.e., when the other peer is not on chatmail/DC)!

1 Like