
JSON+UDP+DHT=Freedom - nmcfarl
http://telehash.org/
======
nmcfarl
This wiki page got me much closer to understanding what's really going on
here: [https://github.com/quartzjer/TeleHash/wiki/My-
Understanding-...](https://github.com/quartzjer/TeleHash/wiki/My-
Understanding-of-the-TeleHash-Protocol)

------
keithwinstein
This is very interesting. We looked at storing stuff in BitTorrent's Kademlia
DHT to do roaming NAT-traversal in Mosh, but their performance scared us off.
Before building an application on this I would want to ask:

\- Who runs telehash.org? Will they still be around in five years? Is there a
well-known list of anchor nodes I can hardcode into my app, or how does the
program find the DHT when it first starts?

\- What is the median time to retrieve a key? What will it be in 24 months?

\- What is the percentage of failed requests? Can we guess what that will be
in 24 months?

The "mainline" BitTorrent Kademlia DHT started off great but now the
statistics are apparently abysmal. In one academic study, the median time to
retrieve a key was over a minute, and 20% of retrievals failed. (See
<http://www.cs.rice.edu/~scrosby/tr/BTMeasure-Main.pdf>)

Why won't the same fate befall this Kademlia DHT?

(Edit: is this _A_ DHT, or is the idea that if you build your program to use
Telehash, you are creating your own DHT that is only used by currently-running
instances of the same program?)

~~~
nmcfarl
> (Edit: is this _A_ DHT, or is the idea that if you build your program to use
> Telehash, you are creating your own DHT that is only used by currently-
> running instances of the same program?)

I had assumed the later, but the existence of telecast.org:42424 kind of
points against it. It's possible that we've got both going on.

------
towhans
I am a programmer yet still I don't get what this is. If an app wants to send
JSON to another app why not use HTTP for that. DNS will take care of the
routing. The only thing that seems novel to me is their use of UDP which is
faster then HTTP.

~~~
artumi-richard
Is it to bypass DNS? With all the moves to control the internet around, then
an encrypted peer-to-peer decentralised system that can deal with any kind of
data would allow for DNS-less email / websites etc etc...

Though the main point of DNS is it manages a namespace, and you wouldn't want
clashes, so websites would probably have to have urls like t<http://{some>
64char hash}/

(Where the h stands for telehash...

~~~
medecau
The use of UDP allows for "hole-punching".

User A wants to send and receive messages with user B. Both are identified
only by their IP and Port pair. User B does not know of user As intentions. So
user A send switch C an UDP packet asking for "hole-punching". Switch C has
this service where users behind NAT routers connect and signup to be contacted
when someone wants to "hole-punch" to them. Switch C sends a packet to B with
info about A. B sends A a packet and Bs router is now expecting packets from
A. Has soon has A sends its first packet to B its router is open for packets
from B. Now both A and B can send packets to each other without C.

DNS is not yet entirely out of the loop. The main switch for telehash is
telehash.org:42424

~~~
Cieplak
This is the ideal situation. It only works, however, for a subset of routers.

------
fleitz
This would be a phenomenal way to build something like app.net.

With full decentralization it could really become a true 'protocol'.

~~~
uncoder0
There is nothing about App.net that is decentralized. Why do people think it
is decentralized? It is a walled-garden with a better gate policy.

~~~
macspoofing
>It is a walled-garden with a better gate policy.

...until they need money.

~~~
slig
$50 per user per year ought to be sufficient.

------
sudhirj
I can just glimpse the promise this holds, but I don't really understand one
would implement this. Does anyone have a blog post with example code?

If I've got a server that needs to receive messages, do I register it as an
'end'? And do I then send messages to this 'end' from other clients? How does
it prevent two parties from registering the same 'end' hash?

~~~
medecau
end is a SHA1 of the ip+port of the endpoint so there won't be any collisions
(hopefully)

------
buster
There is some version 2.0 on its way:
[https://github.com/quartzjer/TeleHash/commit/14cecbb2e58dca4...](https://github.com/quartzjer/TeleHash/commit/14cecbb2e58dca42cc648b8add71408ddf0f5ef9)

~~~
lucaspiller
And if you don't like reading HTML:

<http://telehash.org/v2.html>

------
spolu
Why UDP? And Why create one implementation for each language?? Why not a local
server?

~~~
b3tta
To the "Why UDP?" part:

For things like P2P UDP is a much better fit, because TCP sends an ACK
(ACKnowledgement) to the sender for every received packet.

Since UDP is unreliable no such ACKs will be send and it's up to the
programmer to detect packet loss. The latency is therefore with UDP lower (and
hence throughput higher), because the provider can push packets without
waiting for a response.

For instance in P2P the receiver only needs to send a NAK (Negative
AcKnowledgment) if and only if a packet/part is missing and then it will be
resend by the provider.

~~~
icebraining
_TCP sends an ACK (ACKnowledgement) to the sender for every received packet._

Not quite. TCP receivers only need to send ACKs when they have received enough
data to fill the sliding window. That may be every packet, every other packet
(the recommended by the RFC) or more.

------
popee
You could have problems with NAT, but SIP protocol has STUN and ICE which are
responsible for dealing with this. Check that out.

Btw i had idea SIP + JSON/HTML + DHT which would not suffer with "man in the
middle attack" that HTTP has as designed decision. You could connect, for
example, with HTTP/FTP/... protocols to your buddies directly. You just have
to make right SDP packet when calling them ...

------
hdradionet
UDP+DHT+NAT Traversal is very powerful. I implemented a new p2p radio platform
called HD Radio.NET (<http://hdradionet.zapto.org/>) which is completely based
on them. It shows to be very effective. In this news, Jason is a new idea, it
may bring some benefits, for example, running something in browser.

~~~
jsilence
Reminds me of peercast. Which seems to be quite dead, unfortunately.

In you FAQ it says it is cross platform, but there is only Windows software on
the download page.

------
EternalFury
This is a nice mash-up. It would have been nice to preserve Kademlia's
symmetrical distance metrics, though.

------
klibertp
> to discover its __public __IP:PORT

What about switches that want to run from behind a NAT? Could it be that UDP
was chosen with this in mind?
(<http://en.wikipedia.org/wiki/UDP_hole_punching>)

~~~
alberich
I was wondering how this approach deals with systems running behind NAT also.
With IPv6 not happening anytime soon, there will be a large number of systems
without individual public addresses available. Routing this UDP packets may
require tweaking firewall rules, etc.

