LittleVulpix
commented
9 years ago I recommend https://toxme.se/ :) Lets you assign a short "name@toxme.se" to your identifier, which majority of the clients will allow you to then use instead.
Open srkunze opened 9 years ago
LittleVulpix
commented
9 years ago I recommend https://toxme.se/ :) Lets you assign a short "name@toxme.se" to your identifier, which majority of the clients will allow you to then use instead.
srkunze
commented
9 years ago Thanks for the prompt answer. :) Unfortunately, it looks like the website is down (at least for me).
Generally, I would prefer a decentralized solution to this issue; basically part of the main protocol. That is why I posted here. The downtime of toxme.se again shows me that this key issue should be addressed by a p2p technology like Tox.
Maybe, Tox is the wrong place for this and there should be another p2p solution that solely cares about discovery which Tox clients and other p2p software could then use. However, I guess the fastest and most reliable solution would be baked right into Tox itself (and maybe extracted into its own package after a while).
LittleVulpix
commented
9 years ago The site is working for me :o I even tried refreshing and all is good. Try again? Also, yeah, I know what you mean, but I don't think you can do this in a decentralized way - because then you couldn't easily ensure uniqueness of the "requested" shortname, I think.
srkunze
commented
9 years ago Nope. It does not work. :(
Discovery here does not necessarily mean search and find one and only one result on the first try. Uniqueness is not required here.
Ambiguity can be removed by human interaction easily (e.g. comparing last two digits of ToxID). Maybe, also by introduction of more personal fields like location etc by which can be searched. But I guess the username will be sufficient for a long time.
GrayHatter
commented
9 years ago @srkunze you can use any DNS server you want. Almost every client supports toxdns https://github.com/Tox/Tox-STS/blob/master/STS.md#dns-discovery
dubslow
commented
9 years ago @srkunze What he means is that there are other sites besides toxme.se that offer identical services. I know they exist, but unfortunately I don't know any of them off the top of my head. (Whether or not you trust them is up to you to determine -- this of course also applies to toxme.se)
@stqism ^ toxme.se is down @srkunze Can you please elaborate on what you mean when you say toxme.se doesn't work? You mean your browser simply can't connect to it, as if your computer was offline (even though everything else works)? Any additional information would be quite useful to determine why it doesn't work for you. There are scattered reports that it doesn't work, but all the devs, as well as others like LittleVulpix, can't seem to reproduce. Obviously there is an issue though, so any details you can provide would be excellent.
stqism
commented
9 years ago @dubslow, can't reproduce
zetok
commented
9 years ago @srkunze could you check with different DNS? It was often reported to not work with some DNS services.
Use google's DNS to check it: 8.8.8.8 or 8.8.4.4 if you can, or some other that would be reliable.
ArchangeGabriel
commented
9 years ago Also, you must understand that such things are a trade between privacy and user-friendliness. Personally, I don’t want my ID to be publicly associated with myself.
srkunze
commented
9 years ago @zetok @stqism That is funny. nslookup with my default DNS server tells me: "server can't find toxme.se: NXDOMAIN". nslookup with 8.8.8.8 tells me the IP address of toxme.se: 104.219.184.187 When using that IP address in Chrome and Firefox, they first resolve the IP address to a name AND then tells me again the server cannot be resolved. I know I (as a tech-savvy user) could tweak my settings but from a normal user's point of view that is unacceptable. Tox is meant to be configuration-free even if it is not Tox' fault.
The beauty of Tox and when ToxIDs were exchanged already, is that is just works out of the box (as it is supposed to be from what I can read on its website):
I think you got the idea.
srkunze
commented
9 years ago @GrayHatter Not sure if I understand the document correctly but it seems that I would need to contact a DNS server to include my Tox URI. Again not that simple I think.
srkunze
commented
9 years ago @all Let me tell you what I actually had in mind (also with respect to @ArchangeGabriel's privacy concern): a checkbox in the client which basically allow's Tox to distribute my username via the Tox network.
This is opt-in. So, @ArchangeGabriel would not do that and that is fine.
I would do it as I wish to be discovered by my friends easily. It doesn't need to be unique among all usernames. Final resolution can always be done by human interaction or changing your username.
GrayHatter
commented
9 years ago @srkunze this is actually not a bad idea just incase some GO decides they want to kill off DNS. But how would you suggest tox handle name collisions or impersonations?
ArchangeGabriel
commented
9 years ago Oh, yeah, that was the second point I was talking about. This makes MITM much more easy to do, so MITM must be solved first.
srkunze
commented
9 years ago Nice to see I produced my concern understandably. :)
I imagine that I could simply enter the username (or part of it) in the interface ("Add new friend") and the client gets me a list of ToxIDs that matches their associated usernames (if published at all) with the requested one.
So, verification (at least in the first step of such an implementation) should be left to the user (maybe by telling him explicitly in the client "check with your buddy if the last 3 digits of his ToxID are correct").
When people agree to use Tox together, they already communicated. Thus, they have another channel to check the checksum (last digits of the ID, or whatever you prefer most).
One could also think of an extension where people when exchanging their usernames, not only use their plain username but also use the last digits appended: myusername-134. The client can check if the id matches automatically and add the friend. That is not bullet-proof but usable.
srkunze
commented
9 years ago An additional idea would be to have friends automatically verify if the id of another friend matches. Not bulletproof either but when done in background provides another means of security aka awareness.
If you want to have 100% security (at least when the underlying assumptions of encryption and co are true), use ToxID instead.
However, I guess for the average joe, this system would simplify Tox usage greatly.
GrayHatter
commented
9 years ago I imagine that I could simply enter the username (or part of it) in the interface ("Add new friend") and the client gets me a list of ToxIDs that matches their associated usernames (if published at all) with the requested one.
Where would this database be kept in a distributed network? And if you're only going for partial matches, how many would handle 10s of 1,000s of matches? And how would you avoid network poisoning?
So, verification (at least in the first step of such an implementation) should be left to the user (maybe by telling him explicitly in the client "check with your buddy if the last 3 digits of his ToxID are correct").
One could also think of an extension where people when exchanging their usernames, not only use their plain username but also use the last digits appended: myusername-134. The client can check if the id matches automatically and add the friend. That is not bullet-proof but usable.
This is already what toxdns does; username@somewhere.blerg, That's more user friendly than username-###
An additional idea would be to have friends automatically verify if the id of another friend matches. Not bulletproof either but when done in background provides another means of security aka awareness.
How would this work?
stqism
commented
9 years ago @GrayHatter I stated in IRC earlier the details, but doing it correctly is an engineering problem that doesn't even have a solution. Like, no distributed database designs in existence fit what we need well enough and without creating new issues.
GrayHatter
commented
9 years ago @stqism I'm just trying to tease out the exact workflow requested because when I say this is the perfect thing for a client to handle, I want to be able to provide some guidance on how to submit a better issue to that client.
srkunze
commented
9 years ago Where would this database be kept in a distributed network?
Somewhere in the DHT. I share search data like {'username': 'me'} signed with my key. If you want to store too much data, nodes will refuse to it. At least friends should store the data if short enough. Other nodes can contribute.
It is okay if the data is not always available. Currently, I am out of luck anyway; no need for a 100% reliable system. It will be when Tox gains adoption (by adding features like this ;-)), since some of my friends will be online and share my publicly available search data.
And how would you avoid network poisoning?
Could you be more specific here?
And if you're only going for partial matches, how many would handle 10s of 1,000s of matches?
Just return the first 10 in whatever order they be served. If you call yourself "miller" and 100,000 other guys had the same great idea, the feature will be useless to you. So, you either don't use it or you will change your username.
I might tighten the scope of this issue: of course it would be nice to have a fully fledged social network discovery mechanism to find former colleagues, friends and so on. However, the issue at hand is not supposed to solve that; at least not 100%; maybe only to 10% if at all.
This issue is about solving the problem of a human-readable and human-transferable (e.g. via voice over plain air). I might know the last two digits of my ToxID but not more. Using my username, I am able to help my girlfriend (sitting next to me) getting the Tox app installed, and adding me to her friend list. If there are more than one "me"s, I can use the two digits of my ToxID to tell her: "tap on the second one there" and point my finger on it as well.
This is already what toxdns does; username@somewhere.blerg, That's more user friendly than username-###
Unfortunately, it is not. It requires an additional step for my girlfriend to sign up at somewhere.blerg.
Why? Because adoption stops when I only can persuade my friends to use Tox for chatting with me EXCLUSIVELY. They need to be added by their friends easily as well to create a network effect.
toxdns for user discovery basically defeats the key selling points of Tox (at least to me): easy of use (easy setup, no configuration, no registration) + spy-free (no third-party involvement).
How would this work?
When you try to add a friend, the user can request from his friends a confirmation whether or not the found friend is the same (ToxID) they have in their list. If so, they send "yes". If not, if not in their list or if the do not want to share that piece of data, they send "no". You can take that as a guesstimate whether this "miller" is the one you are looking for or not as you might share some common friends. That is basically part of the more fully fledged social network discovery. Thus, not necessary in the first step.
srkunze
commented
9 years ago I stated in IRC earlier the details, but doing it correctly is an engineering problem that doesn't even have a solution. Like, no distributed database designs in existence fit what we need well enough and without creating new issues.
What are the assumptions?
GrayHatter
commented
9 years ago It is okay if the data is not always available.
You say it needs to be more user friendly, but then say it can just seemingly randoms drop features?
Could you be more specific here?
What's to stop one malicious user from submitting millions of usernames to the DHT?
It would be nice to have a fully fledged social network discovery mechanism to find former colleagues, friends and so on.
Clients may want to support this, but toxcore is just a backbone of a communication system. Social networking is and should remain separate.
This is already what toxdns does; username@somewhere.blerg, That's more user friendly than username-###
Unfortunately, it is not. It requires an additional step for my girlfriend to sign up at somewhere.blerg.
That's what you have to do with skype... Only it's currently cooked into the install process. Maybe that's what you want clients to do? Require users to register with their system?
Why? Because adoption stops when I only can persuade my friends to use Tox for chatting with me EXCLUSIVELY. They need to be added by their friends easily as well to create a network effect.
toxdns for user discovery basically defeats the key selling points of Tox (at least to me): easy of use (easy setup, no configuration, no registration) + spy-free (no third-party involvement).
By submitting a username that traces back to your toxid to public DHT you've already got 3rd party. You have to trust every node to not be malicious, instead of a single site with a signed SSL cert.
When you try to add a friend, the user can request from his friends a confirmation whether or not the found friend is the same (ToxID) they have in their list. If so, they send "yes". If not, if not in their list or if the do not want to share that piece of data, they send "no".
This would allow an attacker to enumerate your friends list, and track you're whole social network.
srkunze
commented
9 years ago You say it needs to be more user friendly, but then say it can just seemingly randoms drop features?
It is okay if the data is not always available. Currently, I am out of luck anyway; no need for a 100% reliable system. It will be when Tox gains adoption (by adding features like this ;-)), since some of my friends will be online and share my publicly available search data.
.
What's to stop one malicious user from submitting millions of usernames to the DHT?
What's to stop one malicous user from submitting millions of ToxIDs to the DHT?
That's what you have to do with skype... Only it's currently cooked into the install process. Maybe that's what you want clients to do? Require users to register with their system?
I wonder how you read and interpret my posts. Again this is what I said about this:
toxdns for user discovery basically defeats the key selling points of Tox (at least to me): easy of use (easy setup, no configuration, no registration) + spy-free (no third-party involvement).
By submitting a username that traces back to your toxid to public DHT you've already got 3rd party. You have to trust every node to not be malicious, instead of a single site with a signed SSL cert.
Single sites that do not work (I know it is the fault of the DNS but why should users care)? Sites that require registration? Sites that hinder adoption because on the road to a successful registration there many things can go wrong?
Point is not that third-parties can associate my ToxID with my username. The issue is User Discovery done easy by allowing the client to distribute my username associated with my ToxID throughout the network.
It is a usability issue. Humans interact by using names not by using freaking long numbers.
This would allow an attacker to enumerate your friends list, and track you're whole social network.
If my friends attack me, I would be worried.
srkunze
commented
9 years ago I would appreciate your thoughts on the implementation as well as you are more involved in Tox. I personally do not care so much about that as what counts to me is the resolution of the issue. I hope you got the point of this issue.
If you feel that Tox is not the right place and discovery will never be address this way, go ahead and close the issue.
If so, however, I predict problems of the adoption by average joe and maria like I described above. I just remember the "like this useless ICQ numbers".
aaannndddyyy
commented
9 years ago @srkunze Re usability: in skype you need a username and a password too, and you can autologin. With DNS you do not need more than that. So I don't think DNS per sé is a big issue, as long as it's working, though a robust dht would make the enrite thing fully p2p and not depend on single points of failure. But as was stated about this raises other issues. If the server is permanently down, a new server should be found, or if it is unreachable then thisn eeds fixing. Tox MUST have an easy, non-toxid way to add friends.
Re third parties: If you publish your username and toxid it is public, no matter if on a server or in DHT. So not a big difference. Of course, this server can sell the accumulated records.
Re authenticating your friends after adding them by user name - no matter if via DNS or DHT : there is a suggested solution on https://github.com/irungentoo/toxcore/issues/1180
GrayHatter
commented
9 years ago @srkunze I don't mean at all to try to steer you away, users become power users, become contributors, become developers. I'm merely trying to figure out exactly the issue you see. That way I can direct you to the correct place to really submit this, where it'll get the attention it deserves. Toxcore really shouldn't be involved in anything relating to sharing data or identities. all it should do is provide the framework for tox clients to communicate. Everything else, especially everything a user might want to do should be something clients worry about.
Why I'm asking so many questions is to figure out what the solution would look like for your issue. Very likely I don't see it the same way you do, so maybe toxcore should handle it. But from what I currently see as your issue, is something that would be better submitted to a client. Identity data isn't really something that the tox network should be responsible for.
I also want to add to what @aaannndddyyy has said, that any user can enumerate DHT records and then sell them too...
srkunze
commented
9 years ago Toxcore really shouldn't be involved in anything relating to sharing data or identities. all it should do is provide the framework for tox clients to communicate. Everything else, especially everything a user might want to do should be something clients worry about.
I understand that. However, one thing I am not so sure about is whether clients ever could solve that problem on their own because toxcore is setting a standard here.
I know that clients could do whatever they want but when it comes to incompatibility issues, users drop out.
So, yes, this could maybe be solved by clients storing searchdata on friends' nodes but they should store the data in the very same way as any other client. So, this would need a common implementation or else incompatibilities will occur, UX will drop, users drop out.
That was my original thought on why this should be part of the core. The core set the standard.
srkunze
commented
9 years ago @aaannndddyyy
Re usability: in skype you need a username and a password too, and you can autologin. With DNS you do not need more than that. So I don't think DNS per sé is a big issue, as long as it's working, though a robust dht would make the enrite thing fully p2p and not depend on single points of failure. But as was stated about this raises other issues.
The first time I started qtox is was impressed how easy it was. No configuration, it just start it up and I am online and I have an id. The guys I forwarded my tox id also were impressed. So, I do not want to destroy that experience.
Up and running. That would be huge selling point over Skype. Everything else just is like Skype. So, why not using Skype? Everybody is there. The network effect counts much.
Re third parties: If you publish your username and toxid it is public, no matter if on a server or in DHT. So not a big difference. Of course, this server can sell the accumulated records.
Not sure why third-parties are to important here and everybody keeps talking about them. 3rd parties should not be able to spy on my communications. I do not care about 3rd parties knowing my ToxID. I want to use Tox because my communication is private.
Also because every 3rd party tries to collect data and I cannot do anything about it. Even friends, colleagues could sell the data they know about you. So, if you have real life, you need to live with that anyway.
srkunze
commented
9 years ago Re authenticating your friends after adding them by user name - no matter if via DNS or DHT : there is a suggested solution on #1180
Thanks for cross-linking. Not sure if his propasal is easy to implement but when I sit to my girl-friend, telling apart two usernames by the last two digits of the toxid suffices (at least) to me.
aaannndddyyy
commented
9 years ago the proposal on #1180 is in order to secure against a malicious server. Implementation would be trivial, it's just about sending two custom messages and hashing. Last two digits offer no security in that case. Last two bytes would really only account for non-malicious users who chose the same name - something that currently cannot occur anyway.
srkunze
commented
9 years ago @aaannndddyyy Sure. That is why I would get rid of the third-party server anyway. Signing your "username + ToxID" with your private key would solve that problem.
aaannndddyyy
commented
9 years ago @srkunze: this would not solve it the security problem.
tttom
commented
9 years ago Hi, I think what @skrunze describes is an essential feature of Skype and I think Tox should have it to be equally user friendly. I am not sure if it really needs to be in toxcore, though I don't see any other way at the moment.
Most people I know don't even know their Skype ID top of their head, anyway, it stays logged in and you can always get the password back by e-mail if needed. So it is great that Skype has this feature to find people based on their name, perhaps selecting the correct one based on the extra info (city,avatar) they provided, and call them. Once you call and hear or see them it is easy to verify who it is. Yes, you can have a man-in-the-middle attach, but the channel can be secured using ZRTP, so that is not a reason for not allowing it. I am more worried about overloading the DHT, though I don't think that should necessarily be a problem either. Right now somebody could generate many ToxIDs to put some load on the DHT. Though, as I understand so far, this is somehow mitigated by the relative short refresh time required. A similar refresh could be required for storing search tokens and the tokens should be signed by the private key of the ToxID it is announcing. Yes, more load on the DHT, though I don't see it as less safe than the current case.
Reading the comments here it seems that not everybody knows the Skype search feature mentioned. Let me explain what I refer to. Basically in Skype you can search in your contacts by typing "an" and it will first show your contacts "Ann Smith (she@email.com)", "Andy MacDonald (he@email.com)", "Nick (nick@antox.org)". In essence any contact that has a part starting with the characters "an", case insensitive. Parts are separated by spaces or punctuation, including - and @. Next, if you click the "Search Skype" button, the list will be expanded by up to 100 people that are not in your contact list and have a part of their name or skype ID that matches exactly "an", e.g. "Ng An", "An Verhagen", ... If you repeat a not very specific search as this one, you will get a different set of people listed. You can make it more specific by adding multiple text strings in the search box. Skype will only return people for which all strings match exactly. Note that this used to work even before microsoft centralized skype, so it appears this is handled by the DHT.
Granted, there are some issues to be solved before this could be part of toxcore, though I believe these can be overcome. One thing that could be done is that clients could mark contacts added without directly specifying the ToxID as unverified until the user does so (e.g. by ZRTP or other channel). This way starting a call is effortless, even if you didn't get the ToxID from a trusted source. Granted, MITM is possible in that case, but it can be eliminated by exchanging ToxIDs or securing the connection with e.g. ZRTP. In my opinion this combined with extending the functionality of the DHT would increase user-friendliness, Skype compatibility, and it would eliminate the vulnerability of using ToxIDs received from a third party (such as DNS records).
Looking forward to your thoughts on this...
ArchangeGabriel
commented
9 years ago I will not comment on the implementation since I’m personally not interested in this feature, but want to raise to concerns once again:
ArchangeGabriel
commented
9 years ago Also, I must add that with the many discussion around security, I’m starting to think that best security isn’t compatible with user-friendliness and any soft that pretend to be very secure on as most point as possible can’t be at the same time targeted toward everyone. Most people don’t really care about security.
Maybe I’m wrong (and would love to), probably that’s not the right place to speak about it, but for me it looks like at some point, we are trading security versus usage comfort, and maybe the devs should make a statement about whether Tox goal is to provide a good messaging app for everyone aiming to replace Skype and avoiding most 3rd parties to listen and that’s all, or is to provide a very secured communication channel protecting you against most attacks, metadata leaking and such, but needing you to understand its principles. If anyone is interested in this concern too, maybe we should start an issue at https://github.com/Tox/Tox-Foundation-Discussion.
tttom
commented
9 years ago I agree @ArchangeGabriel, publishing info should be optional. In regards your second point. Now you already have to exchange ToxID through a safe channel, so nothing new there. But with this proposal, one would be able to chat (without verification) + verify identity when using audio or video.
fcore117
commented
9 years ago i too like current way and i do not want to use any servers. If i want to publish my easy user id then i sign to utox.org or toxme.se
srkunze
commented
9 years ago @fcore117 Normal users need easy user id to find each other. If they need to use a third party for that, what is the difference to using Skype?
srkunze
commented
9 years ago @tttom Good to see that there are also users that would see a benefit for this. You exactly described what I thought about it.
Why is MITM such a big thing here? To me, it looks like a very theoretical attack.
tttom
commented
9 years ago @srkunze: Although I am sure that most people don't think twice about it as you also seem to suggest, MITM is not just a theoretical possibility. Many, including western, government agencies make sure to have access to all network communication and in some cases (US it seems) even private keys to decrypt https traffic. China seems to block any https doesn't have the private keys for. Government agencies cannot even trust their own staff (ask 'em about Snowden), so why should we trust the MITM? Even if we do trust every government employee, would we trust hackers that compromise DNS servers or other parts of the network? I certainly wouldn't. What can be so secret that I don't want anyone to listen into? Many things. Say I am collaborating with employees in a foreign office in a country that happens to lie on the wrong side of the axis of evil. My company makes money by developing technological superior and cheaper products than the competition. As an employee in R&D, I even have the legal obligation to prevent confidential project details from leaking before the contracts/patents are in. The same goes for politicians who don't want foreign intelligence to listen in on their internal communication (recently US-Germany). And of course, as a matter of principle, privacy is a human right, even if it is just to talk to your other half.
Tox eliminates the MITM for the case that you physically exchange a ToxID. As this is not very convenient in most situations, one could use me@toxme.se. I think this is a great idea; a server is only required when adding a new contact. Though it still opens the possibility of MITM, hence I support #1180, and it is not truly distributed, hence I like the point you raised. To be clear, I don't think it should replace the rather elegant DNS system, just compliment it.
srkunze
commented
9 years ago Complementing sounds good. Different users have different needs. :)
Dirius77
commented
9 years ago Perhaps the best option would work something like this, it's a bit of a compromise between the two, in that a user has to be online in order to find them:
User 1, Alice, wants to find Bob. She broadcasts to the network saying she is looking for Bob. Network nodes pass this around. Bob (If he chooses to respond to this request), sends out his name and Tox ID in reply. Alice gets Bob's replies, as well as anyone else who said "Hey my name is Bob, or contains Bob" Using avatars would be useful here for recognizing people, or the last 3 digits of the Tox ID.
Use the methods mentioned in the other issue for verification.
Anti-Poisoning, if someone sends out too many requests, nodes can simply say "Fuck you" and stop responding. If someone says "Hey that's me" too often they can do the same thing.
srkunze
commented
9 years ago @Dirius77 Good suggestion. I could live with that as well. :)
srkunze
commented
9 years ago After talking with my colleagues about Tox, one of them explained an idea realized by "Threema", a Tox equivalent.
They publish the search data not like this "[[username, srkunze], [email, srkunze@github.com]]" but instead, they hash these items (salted of course): "[[username, h4h7l2rt3], [telephone, erh5r399]]". Thus, your search data is obscured for the public but friends (knowing details of you) can still find you.
I am not saying Threema works exactly this way, but I think you get the idea.
Having this, you can contact somebody when you know matching details of that person, say in your telephone book of your smartphone. That of course needs to be part of client. But the hashing and exchange of the search data should be done in a standardized way.
I would appreciate a solution that could work this way as well.
aaannndddyyy
commented
9 years ago @srkunze I proposed this hashing thing before, and I think it's a good thing to have. Tox is meant to be a skype replacement, I know. But that doesn't mean it must not adopt useful features skype might not have (I don't know as I don't use skype). I know one HUGE selling ppoint of whatsapp is that, besides that "everyone has it", you don't need to set up an identity and distribute it among your friends; everyone who has you in his phone book and has whatsapp, will automatically be in your whatsapp too. This is a very big thing, talking about usability.
The issue raised back then was that you'd need a way to check wether someone really owns that number (by calling or sending an sms code). The way whatsapp confirms it. Since this would cost money, and because it would again create a (central) point that know too much data in my opinion by requiring numbers NOT to be hashed but in the clear, this is not a good idea. So I still prefer the hashing thing. It must, nonetheless, be OPTIONAL. But how do you handle fake entries? Steve, who stalks you and knows your number, can also create a tox account with your number, as there is no verification. Unsolvable problem? No. If I search for Maria's number and Maria has (auto)registered with her number, and so has Steve, then I'll get both, Maria's and Steve's records back. That's not a very nice. But it's not a big issue either, if we have #1180, i.e. an easy and secure method of telling them apart.
srkunze
commented
9 years ago Thanks @aaannndddyyy. I see now that we could have an almost complete solution to our initial problem.
1) Discovery of Users: an additional protocol part (e.g. an additional layer on top of Tox) to find each other out of thousands of strangers as described above with optional, public or hashed data properties. Clients may use your phonebook for easier discovery.
2) Confirming contacts as described in your post by associating secrets with public key. That would also require an additional protocol extension (additional on top of Tox of course), that clients could handle.
All of these parts should be provided by a single library, as otherwise I really fear client incompatibilities.
tttom
commented
9 years ago Funny, a couple of hours back I actually asked my colleagues why the hell they all use whatsapp when it demands payment and there are plenty of free of charge, secure, and open source apps that do the same or more. The conclusion was what @aaannndddyyy just mentioned, no need to exchange contact info, it is already in your phone. I agree that Tox can become as easy to use, without trading in security or anonymity for those that wish. This would boost the number of Toxers online, a must to make it truly useful.
Note that Threema suggests users to verify the connection by scanning a QR code of their contacts ID. Once that is done that contact is marked as verified by a green indicator. Tox clients could distinguish verified connections in a similar way. One of the solutions mentioned in #1180 would furthermore allow verification without a physical meeting.
srkunze
commented
9 years ago @aaannndddyyy From what I gather, public hashed search data only differs from the hashed confirmation secrets by being public whereas the confirmation secrets are one-time usage.
aaannndddyyy
commented
9 years ago the hashed numbers are public to all who know your number (they all can hahs it, also the stalker if he knows it) and would be available in the lookup service. The secret is something only you and your friend know. and it is not stored anywhere, in order to defeat brute force atacks. it is only sent encrypted and only upon request.
tttom
commented
9 years ago Could this be implemented as follows:
When a node receives an 'announce' request it checks if it has seen the same key frequently. If yes, it drops the request. If not frequent, it stores or refreshes the key-value pair for a certain period of time and forwards the announce request to any node closer to the key it knows of.
When a node receives a search query, it returns all ToxIDs it has for the query key. If not many could be returned, the request is forwarded to a DHT node closer to the key.
If the query matches a Tox DNS name, try to retrieve it from DNS, otherwise a search query could be parsed as follows:
Queries should be sent from most unique to least unique: e-mail, phone number, N key words, N-1 keywords, ... until at least one ToxID is returned.
To help filter duplicates, each returned ToxID could be used to request the full directory listing from the potential contacts. Users can start talking though Tox clients should mark such connections as unverified until the ToxIDs are checked either by meeting in person or by a method such as ZRTP.
Potential issues:
Alternatives for optional directory listing/checking:
Neither of these is truly distributed though both must be easier to set up and will take less network traffic.
I could not find anything useful on this topic, thus this thread.
Recently, I introduced Tox to my girlfriend and sent her my ToxID. She try it out on her tablet. She was even more surprised regarding the long identifier as she discovered that she even need to scroll to the right to see it fully.
Long story short, she liked the encryption, group, voice and video features, but those IDs... she compared them to "useless ICQ numbers". I know technically that is not quite the same, but from what I know Tox aims to be as user-friendly as it can be.
User discovery is an important part here as well. Is there a way to query after user names? I know they are not unique but it would be a start and if there are two users with the same username, e.g. the last two digits of the ToxID can be used (and interchanged manually) in order to distinguish the buddy from other guys.