Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove ToxDNS and related stuff from toxcore #42

Closed
3 of 5 tasks
ovalseven8 opened this issue Aug 18, 2016 · 11 comments · Fixed by #650
Closed
3 of 5 tasks

Remove ToxDNS and related stuff from toxcore #42

ovalseven8 opened this issue Aug 18, 2016 · 11 comments · Fixed by #650
Labels
network Network P3 Low priority refactor Refactoring production code, eg. renaming a variable, not affecting semantics
Milestone

Comments

@ovalseven8
Copy link

ovalseven8 commented Aug 18, 2016

I am not sure if I should post issues here now, but I guess it makes sense because it's the only active repository.


There has been the consensus that toxcore should remove ToxDNS at all.

In general, the goal of toxcore is to provide a lighweight, reliable and secure codebase for the clients. The current solution with ToxDNS isn't both secure and decentralized.
Moreover, to use Tox IDs is not such a problem as it probably seems in my opinion. Nonetheless, the clients can of course implement HTTPS lookup services - but that's something that shouldn't be in toxcore.

Here the old issue -> irungentoo#1491


Added by iphy:

  • Antox
  • qTox
  • Ricin
  • Toxic
  • uTox
@iphydf
Copy link
Member

iphydf commented Aug 18, 2016

@tux3 would qTox mind if toxdns were gone?

@ovalseven8
Copy link
Author

qTox is using HTTPS lookup, so it shouldn't be a problem.

@iphydf
Copy link
Member

iphydf commented Aug 18, 2016

I'll remove it when qTox removes its use of the toxdns library.

@tux3
Copy link
Member

tux3 commented Aug 18, 2016

Since qTox supports the HTTPS "toxme" API, we should be able to remove toxdns3 support without problems.
The HTTPS system still suffers from the same centralization and trust issues (it's arguably worse since we don't support key-pinning), I think we'd all be happy to have a secure replacement without sacrificing the convenience.

@iphydf
Copy link
Member

iphydf commented Aug 24, 2016

Specifically, I will remove toxdns when no actively maintained client and library uses it anymore. It has very low maintenance cost, so we can avoid breaking people's code. It would be good if stakeholders were to write in this bug if and when their application stops depending on toxdns, so I know when we can remove it.

@GrayHatter
Copy link

I have no plans to author support for HTTP[S] name lookups in uTox.

That said, I do plan to write a name lookup API into toxcore when possible. And develop uTox concurrently with that feature. Once that is done, I plan to drop DNS name support from uTox.

@ovalseven8
Copy link
Author

No, name lookup shouldn't be handled by toxcore.

@Diadlo
Copy link

Diadlo commented Sep 1, 2016

@GrayHatter Why you think, that toxcore, and not a client should provide lookup feature?

@JFreegman
Copy link
Member

If name lookups can leverage the DHT and be done in a fully distributed way then it's obvious why it would belong in toxcore. However toxcore shouldn't go anywhere near dealing with servers/third party services.

@GrayHatter
Copy link

I'll agree with @ovalseven8 when he says name lookups shouldn't be handled by toxcore. If he also agrees that Messenger shouldn't be handled by toxcore.

First: Messenger as an application needs to be easy to use.
And: ToxIDs aren't easy to use.
Thus: Messenger needs to make them easy.

I think simple name lookup/resolution is a familiar and useful solution.

@geromueller
Copy link

The lookup will be vital for tox when adressing non technical people. To convince more people to use tox, especially on phones, a phone number/book -> tox id solution is required. Otherwise any in my family or any friend will switch.
And leaving that to the clients would end in desaster.

@iphydf iphydf added this to the v0.2.0 milestone Oct 29, 2016
@iphydf iphydf modified the milestones: v0.2.0, v0.0.5 Nov 6, 2016
@iphydf iphydf modified the milestones: v0.0.5, v0.1.1 Nov 20, 2016
@iphydf iphydf modified the milestones: v0.1.1, v0.1.3 Dec 14, 2016
@GrayHatter GrayHatter removed their assignment Dec 15, 2016
@iphydf iphydf added this to the v0.2.0 milestone Dec 17, 2016
@iphydf iphydf removed this from the v0.1.3 milestone Dec 17, 2016
@iphydf iphydf modified the milestone: v0.2.0 Jan 10, 2017
@iphydf iphydf added the P3 Low priority label Jan 12, 2017
iphydf added a commit to iphydf/c-toxcore that referenced this issue Dec 29, 2017
@iphydf iphydf modified the milestones: v0.2.0-RC1, v0.2.0 Jan 14, 2018
@iphydf iphydf added refactor Refactoring production code, eg. renaming a variable, not affecting semantics and removed code cleanup labels May 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
network Network P3 Low priority refactor Refactoring production code, eg. renaming a variable, not affecting semantics
Development

Successfully merging a pull request may close this issue.

8 participants