Browsing your phone book would essentially upload your contacts when the contacts are looked up. (Only uploading the hashes first, but email addresses are quite public, often easy to guess or capture, and calculating the hashes from known addresses will reveal your contacts.)
But a decentral method could maybe work based on “uploading” your email address, and “querying” other’s email address directly, by contacting the contacts through other means.
Sending SMS/WhatchUp/Sifnal etc. based messages (depending on the contact details found) may then really resemble “contact requests”. They could contain a link that opens in deltachat in an accept or deny fashion (if deltachat is installed), and also provide a “download and install” link in case deltachat is not installed.
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
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.
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
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
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”.
@testbird
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
Hopefully in the (near) future there will come up more compatible clients based on the rock solid, distributed email infrastructure .
E.G. OX COI (https://github.com/open-xchange/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.
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?
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.
ok
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?
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.
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.
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.
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.
We advertise that we don’t upload the contacts anywhere in any form.
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
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.
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.
