Contact-Lookup Service

hi testbird,

concerning email adresses being quite easy to guess: I guess they are IF there is a rainbow table for them. Adding a salt would render currently known rainbow tables useless . . . anyway . . . that point about privacy was just a side issue that I clearly hadn’t thought through. More work/reviews needed.

Your idea (if I understand it correctly) would basically boil down to nagging my friends and colleagues to respond to my message through a channel that I impose on to them. That is in no way what I want to do. I don’t want to convert anybody.
When I start to chat to somebody, my decision on what channel to use is based upon the options that the other side is apparently using (the options that my phone book is presenting me). I want DeltaChat to be one of those options.

Or in other words:
I have one single (in numbers: 1) contact that I am currently sending DeltaChat messages to. I know that he uses it, because I myself told him about it (he is interested in that kind of stuff). Maybe there are 3 or 5 others in my phone book that use DeltaChat. But I wouldn’t know it. Because I am not comfortable “spamming” all my other 300 contacts with query messages :wink:

I understand and appreciate that DeltaChat is built upon the idea of decentralization. But looking up and finding other parties that use the same technology is something that (to my understanding) is best done centralized.

Maybe it would be best to give a quick example of what the service I envision would look like:

you could query the service through a REST interface sending a JSON payload that looks like this:

    { id: contactId1,
      hashes: [mailHash1, mailHash2]
    { id: contactId2,
      hashes: [mailHash3]

note: the contactIds are just some internal IDs of the client. They don’t really provide any information about the really contact. Let’s just assume the mailHashes are not easily guessable :wink:

The server would respond with something like this:

    { id: contactId1,
      hashes: [mailHash2]

basically saying “I know that second email hash of the contactId1. But the others are not registered” without anybody exchanging address books.

To register, one would send the email address to the server. The server would store the hash along with a validation-secret, send a validation link (consisting of the hash and the secret) to the email address and then immediately “forget” the plain email address.

Unregistering would work the same.

To be clear on that:
If anybody has your email address, he could find out whether you are using DeltaChat. That is what you sign up for when registering your email address.
But no external party can say “give all email addresses” or find out if A is in the address book of B. The service itself could in theory store the addresses and keep track on who requested what email address. But it won’t. Because it’s open source, written by good people :wink:

Intresting topic… I can understand both sides I’ll come back to this later and add some arguments.

It is understandable, I even opened that other thread, but hashes do identify personal data. If deltachat would upload hashes of all entries of the users’ address book (through making queries), there might be a requirement to accept a GDPR statement, the user having to ask every one of its contacts for permission, keeping track of them, organisations having to compile and confirm privacy statements before allowing the use of deltachat…

That is why whatsup users have to accept with the usage terms to defend the company in court for whatever their app does after grabbing the contact data of all of the user’s “friends”, even if they are not using the app and not consenting.

Concerning your implementation idea, why would you add another datapoint (id: contactId1)? Don’t see how it is necessary.

Concerning the invitiations (Let's switch to a new messenger?), it’s a tool to use selectively where appropirate, I think how it comes across depends on the personal relation, talk, and personal message you send with the “invite link”.

One could also just ask for the email, and have a better 2-way QR scanning: Release the basic QR-Code "contact scanning" feature independently

I really don’t think that GDPR is an issue here.

  • The only data stored on that server (at least as long as we don’t keep pending unverified hashes forever) is the data of people who actively registered it there. And there is clear way how to get it deleted again. Queried hashes are nevery stored. Only verfied by the response.
  • the data is AT LEAST pseudonymous. And I am still arguing that if done right it is actually anonymous.
  • the data clearly fits the big loophole in the GDPR: it is needed for the service to work

The proposal is very clearly GDPR compliant. But actually a good point: the user should be informed by the respective client that his email will be stored pseudo- or anonymously.

You said it yourself: WhatsApp is taking my whole phone book . . . in plain text . . . and keeps it. That’s a completely different case.

Concerning the id in my implementation idea: of course it’s correct that the server could just accept a list of hashes and return a subset of that list. To structure it by an id chosen by the client just makes it easier for the client to map the confirmed mail hashes to the actual contacts. Not a must.

That’s the idea behind DC.
You can use it and your contact have not to install a special software he/she can still there already installed mail client or even the web interface of the mail provider.

So IMHO there is no need to know if somone uses DC or not.
You only need to know his/her mail address :grinning:

1 Like

And another point.

Hopefully in the (near) future there will come up more compatible clients based on the rock solid, distributed email infrastructure .
E.G. OX COI ( will reach production state in autum or winter in this year.

So I think it’s not the best idea to create a new centralised part which have also to maintained and all developers have to support this new (not standardised) part of the infrastructure.

Isn’t it?

Of course you’ve got a good point here.

On the other hand if there wasn’t a clear distinction between an email conversation and a more informal realtime communicaiton (aka “a chat”) you wonderful people wouldn’t have written DeltaChat in the first place, right? :wink:
So if I explicitly want to chat (which is about 90% of all cases) and the other side uses Signal/Telegram/Threema I am not going to send a DeltaChat message, knowing that in the vast majority I’ll end up with an (possibly awkward) email conversation.

I hope you see my point too :wink:

That part about the other similar projects is a VERY good reason not to implement such a server.
Or maybe it could be a chance to build a sort of defacto standard?
Or maybe one should reach out to those other projects for a joint effort?

Absolutely :+1:

Right, if we assume broader adaption and email addresses becoming even more known again, just sending a deltachat note could work in many cases (short email with a footer hint to deltachat, quick read receipt to be expected, if deltachat is installed already).

There is also the vcard standard to share contact data including email. Would it make sense to add a “supports email-chat property”?

If you’d want you could reach out to collaborate on the quicksyserver.

See that its approach seems collecting more data, though, not only to verify email-chat support for a known email address, but to return the XMPP addresses for phone numbers (hashes?), and maybe also return email, and email-chat support values.

Anyway, it would be a central service, and there might be other things still more important to fix.
([Wiki] Use-cases, chat rules and configuration options)

Of course, since uploading an ID datum associated to one of the user’s contacts to a central service is not needed for deltachat to work.

The ID is like a photo, it allows to recognize the person when the person or a photo is seen.

The user that has to be asked as well is the one being identified by the ID, i.e. not only the local one. It’s a link in the “social graph”, very clearly if the local, querying user is logged in, and likely also for some web-analytics IDs associated to your current IP.

And is the third point at for data controllers (organizations) met?

I think there only is no need for a separate confirmation for sharing ones own ID data, if a user has already explicitly signed up for the ID publishing service.

My Opinion:

A Social (Rethinking) Solution

First of all, you already see all accounts that have an email address and you can suggest them in your email signature to get deltaChat if they haven’t already.

(optional) Integration in DeltaChat

At first It looks promising, but unless you find a secure, privacy-friendly and decentralized way to do it, I’m against it.

  1. We advertise that we don’t upload the contacts anywhere in any form.
  2. So even when its optional and turned off per default its still confusing/provocrative if we ask the user if they wanna upload it somewhere.

What we could do is suggest some opensource phonebook apps to do the job.

About adding the Handler to the native Contacts App

DC can do that, either on all contacts with email addresses or just on those it has keys to.
Also after we add an deltachat scheme we could theoretically add it to vCards so a contact gets shareable with its public key. If that fits in the verified contacts concept is another topic, though.


OK. So I see the idea isn’t gaining too much traction :wink:

Actually when writing the proposal I didn’t realize how much “we don’t run ANY server” was part of the mission statement. So of course it was naive/ignorant to propose it in the first place.

I still insist that the proposed design is extremely privacy friendly and secure (and no: there is no “social graph” in a flat list of hashes).
But it is centralized and I don’t see any decentralized solution that would remotely do what I want. So that finishes it.


Before completely closing down the topic, @Simon’s suggestion to integrate DC as an handler in native Contact apps (one of your initial points, @agschaid), still makes a lot of sense.

The way I see it:

  • all contacts with an email address see a DC handler
  • contacts that are already known to DC (eg previously chatted with) appear with a different colour

or, alternatively, we distinguish between contacts for which we only have an email address, and contacts for which we have encryption keys (ie, secure chat)

Seems there is at least another implementation of a name service you could check out, GNU Jami is said to be p2p and has one, but I have no idea how it is realized.

Thank you @testbird for the hint. I think I have tried Jami when it was still called “Ring”.

I haven’t dug to deep but I am afraid they do share my point of view :wink:

As much as we like to say that Jami is completely without server, sometimes it is not exactly right as we have seen.


In the settings there is a bunch of server URLs for various peer discovery techniques. I haven’t found too much about their contact discovery but there is at least one issue that hints a central service.

From my point of view (as somebody who wants to use DeltaChat as a chat and not alternative mail client) I’d be strongly in favor of giving contacts with a DeltaChat history a different color.