7 ms·

Telehash: JSON+UDP+DHT = Freedom

129 points by bkudria 16y ago

cwp 16y ago
Ok, possibly interesting. What's it for? The about page says it's for sending small bits of JSON around. Why would I want to do that?
- mathgladiator 16y ago
  It looks like an alternative for DNS. ? Kind of interesting, but I wonder how it works with security implications.
  - cilantro 16y ago
    My guess would be that it doesn't. A public DHT can ensure that data is not corrupted or changed, but you cannot prevent others from seeing your data.
    - jamii 16y ago
      I think the DHT is just used to address peers and do NAT negotiation. There is no need for every message to go through the DHT.
- lukeschlather 16y ago
  This wiki page seems a little clearer, though anything prefaced with "My Understanding" might be a little suspect. https://github.com/quartzjer/TeleHash/wiki/My-Understanding-of-the-TeleHash-Protocol https://github.com/quartzjer/TeleHash/wiki/My-Understanding-... So my understanding of that is that TeleHash is something of a cross between BitTorrent and Tor. Theoretically it allows for a totally distributed Internet. Though it looks like the implementation is rough, so it's hard to say how well-defined the protocol is.
  - Mizza 16y ago
    Not like Tor, nor like BT, really. It's more like.. Gnutella and JSON?
- jamii 16y ago
  It looks like telehash aims to be a substrate for building p2p apps. It basically solves addressing and NAT for you which are always the first things you have to deal with in a p2p system on the public internet.
aston 16y ago
Jeremie Miller is the guy behind XMPP, so this is coming from somebody who really knows what he's doing when it comes to protocols. This type of thing would be cool as a federation mechanism for something like Google Wave or Diaspora. I think it could also be used as an alternative to XMPP itself...
- bkudria 16y ago
  I agree with you, but I can see how some might strenuously object - XMPP is not universally loved. (Luckily Telehash uses JSON)
  - jerf 16y ago
    That's how you learn, though. XMPP is much better than most people realize, anyhow. Most people do not realize how much of the messiness comes from the problem and not the protocol. IM's easy, right? Just message here, message there? Yeah, sure, the first iteration of IM in the mid-1990s was. File transfers are easy, right? Yes, when both clients and the server are on the same LAN they're trivial. On the real Internet? No, actually they're quite hard. Conferences are no sweat, right? If you're hacking together a Node.js demo that simply shovels out messages to everyone in the conference with no further features, sure. If you want like features and stuff in some sort of standard way, it gets harder. And so on. I'm not saying it's perfect in every way, in particular the oldest parts of the protocol are a bit crufty (like the overloading of the presence tag to mean too many things), but there's a lot of people who rag on it for really misguided reasons, or who failed to read the core standard and got tripped up on the connection process. (In fact, there's a lot of people who don't even spend enough time on it to realize that the standard is modularized and you don't have to take every piece for every purpose.) If I were designing it from scratch today, yes it would be a JSON datagram protocol. But XMPP is many years older than JSON as a distinct thing.
    - moe 16y ago
      XMPP is much better than most people realize, anyhow. No, it is actually worse than most people realize. You only begin to realize the magnitude of the failure once you try to implement a client, and most people don't do that. XMPP is a trainwreck. It has never seen serious adoption because nobody wants to touch it - and for good reasons. XMPP is what I cite when I try to explain the "XML mindset". It leads to bad things. It leads to ridiculous overengineering through layered complexity. It leads to a client/server ecosystem where each implementation speaks a different dialect because it's nearly impossible to get the protocol right. There was a time when my roster would get screwed up in new, random, interesting ways whenever I launched a different client. Some clients would even manage to unsubscribe existing contacts for inexplicable reasons. And don't get me started on "Transports". However, instant messaging is not rocket science. Neither is semi-decentralized instant messaging. XMPP makes it seem like a much harder problem than it really is, but only because XMPP is broken beyond repair. Most people do not realize how much of the messiness comes from the problem and not the protocol. Wrong. Take a lesson from IRC, a group-chat protocol that, despite its age, works and scales amazingly well. A protocol that, despite an immense range of features, can easily be typed by a human on a telnet prompt, in real time. It wouldn't take much fix the warts on IRC and extend it to cover everything that XMPP tries to do. This is what the XMPP author should have done in first place.
phuff 16y ago
Telehash is being proposed and bootstrapped by Jeremie Miller the guy who originally did XMPP. I think it has some good potential to allow better decentralized communication between things like mobile devices, etc.
Deejahll 16y ago
"TeleHash is the culmination of years of discussions with many people, and is being primarily bootstrapped by Jeremie Miller." This is the same Jeremie Miller who invented the Jabber (XMPP) protocol.
mey 16y ago
Why couldn't this be done over TCP instead of UDP?
- mburns 16y ago
  No reason it couldn't, it is a matter of minimizing overhead.
- zacharypinter 16y ago
  Might be for NAT traversal, ala something like: http://en.wikipedia.org/wiki/UDP_hole_punching http://en.wikipedia.org/wiki/UDP_hole_punching One of the wiki pages (https://github.com/quartzjer/TeleHash/wiki/My-Understanding-of-the-TeleHash-Protocol https://github.com/quartzjer/TeleHash/wiki/My-Understanding-...) specifically talks about working with NAT: "Packets can continue to pass through NAT network devices like home routers"
y0ghur7_xxx 16y ago
This could be combined with http://www.unhosted.org/ http://www.unhosted.org/ to deliver completely distributed applications.
jeremie 16y ago
It's a little on the young side yet, and I have to prove out some of the apps/demos of it at scale, but it's coming along very nicely and shows a lot of promise. Ultimately it's a public DHT that enables apps to punch through the NATs (to go direct device-to-device) and talk JSON to each other. It doesn't solve all the problems you face being distributed, but it's a good start :)
- pohl 16y ago
  Reminds me of JXTA with its Pipe abstraction, which works in environment where the only thing allowed is outgoing http. Are you familiar with it? It has the burden of XML though. I like the JSON approach.
- jamii 16y ago
  Are you aware of http://libswift.org/ http://libswift.org/ ? The goals are different (swift is targeted more at bittorrent/multicast) but I think there is a lot of potential for crossover between the two projects.
bobf 16y ago
It would be interesting to see this used in a non-public fashion, like for maintaining a distributed MongoDB-like system.
Groxx 16y ago
".see" as a property seems it could get a little annoying in many languages, given that period - you can't map keys directly. Why "." and not some other character? I'd think common unary characters should be avoided, as they may not be unambiguous in language-X, but why periods? And since there are periods and plusses, why not go hog-wild, and allow "^supercommand", "$(&@^!boom", and others?
- dochtman 16y ago
  Might be cleaner to separate headers and contents. I.e. {"h": {"ring": 43723}, "c": {"see": ["5.6.7.8:23456","11.22.33.44:11223"]}}. Get h for headers, c for commands, s for signals and d for data. Gets you a clean separation, no faux namespacing.
scrame 16y ago
UDP does not guarantee connections. I wonder why it was done with this instead of a reliable multicast protocol (0mq comes to mind).
- brandon 16y ago
  ØMQ came to mind when I read the doc, too, but: * UDP could be useful for hole-punching firewalls * In most networks, multicast traffic will be filtered at the WAN boundary * The nodes in most big DHTs aren't reliable anyway The eventing would be nice, though... and the notion of an internet-wide ØMQ network is neat.
- dochtman 16y ago
  Seems like an interesting idea. I also wonder why the max contents of a JSON object is 1400 bytes, that seems kind of limiting. UDP can do 65,507b of content...
  - agazso 16y ago
    The bigger an UDP packet the less the probability it arrives. 1400 is probably chosen because it is less than the usual MTU of ethernet which is 1500.
- dedward 16y ago
  0mq is a library to make network programming easier, not a new protocol itself. UDP is being used because this is based on setting up a DHT which requires small messages that may or may not get through by nature to begin with - not bulk data transfer - presumably you deal with that at higher layers.
  - scrame 16y ago
    0mq is an extension of the standard socket library and does support a reliable multicast protocol. It adds to sockets, its not just an api to make working with the existing standards easier. http://manpages.ubuntu.com/manpages/maverick/man7/zmq_pgm.7.html http://manpages.ubuntu.com/manpages/maverick/man7/zmq_pgm.7.... Though, it looks like it might need more permissions than just using standard sockets.
senthil_rajasek 16y ago
This uses UDP with a non-standard port. Personally, I would be wary of poking a hole in my firewall to make this work.
- brandon 16y ago
  Why, exactly? To your point, it uses UDP on a non-standard port; forwarding the traffic won't expose any of your existing behind-the-firewall services. Anyhow, one of the draws of UDP for this stuff is that it's possible to do clever hole punching so that you don't have to open the port. http://en.wikipedia.org/wiki/UDP_hole_punching http://en.wikipedia.org/wiki/UDP_hole_punching
brandon 16y ago
I'd love to see a DHT network with some level of attention to durability. Having played a lot with Kademlia, the biggest bummer was that in practice, stored resources had a lifetime of about 4 hours max, and that was when the requester was able to find the node holding your resource. This necessitated spamming your important resources pretty frequently to a redundant set of deterministic keys.
jaimzob 16y ago
Looks very cool but are there particular advantages over, say, Scribe over FreePastry (http://www.freepastry.org/SCRIBE/default.htm http://www.freepastry.org/SCRIBE/default.htm)? How does routing efficiency compare?
zemanel 16y ago
first thing i thought when reading this was "distributed twitter"
pbrumm 16y ago
I like the idea. Having the data be encrypted would be cool too. A time-to-live would be nice so that it doesn't grow forever. Although it sounds like an easy place for virus writers to store plans of attack. And hard to take down without taking down the whole system which by design would be very difficult.

129 points by bkudria 16y ago

cwp 16y ago

Ok, possibly interesting. What's it for? The about page says it's for sending small bits of JSON around. Why would I want to do that?

mathgladiator 16y ago
It looks like an alternative for DNS. ? Kind of interesting, but I wonder how it works with security implications.
- cilantro 16y ago
  My guess would be that it doesn't. A public DHT can ensure that data is not corrupted or changed, but you cannot prevent others from seeing your data.
  - jamii 16y ago
    I think the DHT is just used to address peers and do NAT negotiation. There is no need for every message to go through the DHT.
lukeschlather 16y ago
This wiki page seems a little clearer, though anything prefaced with "My Understanding" might be a little suspect. https://github.com/quartzjer/TeleHash/wiki/My-Understanding-of-the-TeleHash-Protocol https://github.com/quartzjer/TeleHash/wiki/My-Understanding-... So my understanding of that is that TeleHash is something of a cross between BitTorrent and Tor. Theoretically it allows for a totally distributed Internet. Though it looks like the implementation is rough, so it's hard to say how well-defined the protocol is.
- Mizza 16y ago
  Not like Tor, nor like BT, really. It's more like.. Gnutella and JSON?
jamii 16y ago
It looks like telehash aims to be a substrate for building p2p apps. It basically solves addressing and NAT for you which are always the first things you have to deal with in a p2p system on the public internet.

aston 16y ago

Jeremie Miller is the guy behind XMPP, so this is coming from somebody who really knows what he's doing when it comes to protocols. This type of thing would be cool as a federation mechanism for something like Google Wave or Diaspora. I think it could also be used as an alternative to XMPP itself...

bkudria 16y ago
I agree with you, but I can see how some might strenuously object - XMPP is not universally loved. (Luckily Telehash uses JSON)
- jerf 16y ago
  That's how you learn, though. XMPP is much better than most people realize, anyhow. Most people do not realize how much of the messiness comes from the problem and not the protocol. IM's easy, right? Just message here, message there? Yeah, sure, the first iteration of IM in the mid-1990s was. File transfers are easy, right? Yes, when both clients and the server are on the same LAN they're trivial. On the real Internet? No, actually they're quite hard. Conferences are no sweat, right? If you're hacking together a Node.js demo that simply shovels out messages to everyone in the conference with no further features, sure. If you want like features and stuff in some sort of standard way, it gets harder. And so on. I'm not saying it's perfect in every way, in particular the oldest parts of the protocol are a bit crufty (like the overloading of the presence tag to mean too many things), but there's a lot of people who rag on it for really misguided reasons, or who failed to read the core standard and got tripped up on the connection process. (In fact, there's a lot of people who don't even spend enough time on it to realize that the standard is modularized and you don't have to take every piece for every purpose.) If I were designing it from scratch today, yes it would be a JSON datagram protocol. But XMPP is many years older than JSON as a distinct thing.
  - moe 16y ago
    XMPP is much better than most people realize, anyhow. No, it is actually worse than most people realize. You only begin to realize the magnitude of the failure once you try to implement a client, and most people don't do that. XMPP is a trainwreck. It has never seen serious adoption because nobody wants to touch it - and for good reasons. XMPP is what I cite when I try to explain the "XML mindset". It leads to bad things. It leads to ridiculous overengineering through layered complexity. It leads to a client/server ecosystem where each implementation speaks a different dialect because it's nearly impossible to get the protocol right. There was a time when my roster would get screwed up in new, random, interesting ways whenever I launched a different client. Some clients would even manage to unsubscribe existing contacts for inexplicable reasons. And don't get me started on "Transports". However, instant messaging is not rocket science. Neither is semi-decentralized instant messaging. XMPP makes it seem like a much harder problem than it really is, but only because XMPP is broken beyond repair. Most people do not realize how much of the messiness comes from the problem and not the protocol. Wrong. Take a lesson from IRC, a group-chat protocol that, despite its age, works and scales amazingly well. A protocol that, despite an immense range of features, can easily be typed by a human on a telnet prompt, in real time. It wouldn't take much fix the warts on IRC and extend it to cover everything that XMPP tries to do. This is what the XMPP author should have done in first place.

phuff 16y ago

Telehash is being proposed and bootstrapped by Jeremie Miller the guy who originally did XMPP. I think it has some good potential to allow better decentralized communication between things like mobile devices, etc.

Deejahll 16y ago

"TeleHash is the culmination of years of discussions with many people, and is being primarily bootstrapped by Jeremie Miller." This is the same Jeremie Miller who invented the Jabber (XMPP) protocol.

mey 16y ago

Why couldn't this be done over TCP instead of UDP?

mburns 16y ago
No reason it couldn't, it is a matter of minimizing overhead.
zacharypinter 16y ago
Might be for NAT traversal, ala something like: http://en.wikipedia.org/wiki/UDP_hole_punching http://en.wikipedia.org/wiki/UDP_hole_punching One of the wiki pages (https://github.com/quartzjer/TeleHash/wiki/My-Understanding-of-the-TeleHash-Protocol https://github.com/quartzjer/TeleHash/wiki/My-Understanding-...) specifically talks about working with NAT: "Packets can continue to pass through NAT network devices like home routers"

y0ghur7_xxx 16y ago

This could be combined with http://www.unhosted.org/ http://www.unhosted.org/ to deliver completely distributed applications.

jeremie 16y ago

It's a little on the young side yet, and I have to prove out some of the apps/demos of it at scale, but it's coming along very nicely and shows a lot of promise. Ultimately it's a public DHT that enables apps to punch through the NATs (to go direct device-to-device) and talk JSON to each other. It doesn't solve all the problems you face being distributed, but it's a good start :)

pohl 16y ago
Reminds me of JXTA with its Pipe abstraction, which works in environment where the only thing allowed is outgoing http. Are you familiar with it? It has the burden of XML though. I like the JSON approach.
jamii 16y ago
Are you aware of http://libswift.org/ http://libswift.org/ ? The goals are different (swift is targeted more at bittorrent/multicast) but I think there is a lot of potential for crossover between the two projects.

bobf 16y ago

It would be interesting to see this used in a non-public fashion, like for maintaining a distributed MongoDB-like system.

Groxx 16y ago

".see" as a property seems it could get a little annoying in many languages, given that period - you can't map keys directly. Why "." and not some other character? I'd think common unary characters should be avoided, as they may not be unambiguous in language-X, but why periods? And since there are periods and plusses, why not go hog-wild, and allow "^supercommand", "$(&@^!boom", and others?

dochtman 16y ago
Might be cleaner to separate headers and contents. I.e. {"h": {"ring": 43723}, "c": {"see": ["5.6.7.8:23456","11.22.33.44:11223"]}}. Get h for headers, c for commands, s for signals and d for data. Gets you a clean separation, no faux namespacing.

scrame 16y ago

UDP does not guarantee connections. I wonder why it was done with this instead of a reliable multicast protocol (0mq comes to mind).

brandon 16y ago
ØMQ came to mind when I read the doc, too, but: * UDP could be useful for hole-punching firewalls * In most networks, multicast traffic will be filtered at the WAN boundary * The nodes in most big DHTs aren't reliable anyway The eventing would be nice, though... and the notion of an internet-wide ØMQ network is neat.
dochtman 16y ago
Seems like an interesting idea. I also wonder why the max contents of a JSON object is 1400 bytes, that seems kind of limiting. UDP can do 65,507b of content...
- agazso 16y ago
  The bigger an UDP packet the less the probability it arrives. 1400 is probably chosen because it is less than the usual MTU of ethernet which is 1500.
dedward 16y ago
0mq is a library to make network programming easier, not a new protocol itself. UDP is being used because this is based on setting up a DHT which requires small messages that may or may not get through by nature to begin with - not bulk data transfer - presumably you deal with that at higher layers.
- scrame 16y ago
  0mq is an extension of the standard socket library and does support a reliable multicast protocol. It adds to sockets, its not just an api to make working with the existing standards easier. http://manpages.ubuntu.com/manpages/maverick/man7/zmq_pgm.7.html http://manpages.ubuntu.com/manpages/maverick/man7/zmq_pgm.7.... Though, it looks like it might need more permissions than just using standard sockets.

senthil_rajasek 16y ago

This uses UDP with a non-standard port. Personally, I would be wary of poking a hole in my firewall to make this work.

brandon 16y ago
Why, exactly? To your point, it uses UDP on a non-standard port; forwarding the traffic won't expose any of your existing behind-the-firewall services. Anyhow, one of the draws of UDP for this stuff is that it's possible to do clever hole punching so that you don't have to open the port. http://en.wikipedia.org/wiki/UDP_hole_punching http://en.wikipedia.org/wiki/UDP_hole_punching

brandon 16y ago

I'd love to see a DHT network with some level of attention to durability. Having played a lot with Kademlia, the biggest bummer was that in practice, stored resources had a lifetime of about 4 hours max, and that was when the requester was able to find the node holding your resource. This necessitated spamming your important resources pretty frequently to a redundant set of deterministic keys.

jaimzob 16y ago

Looks very cool but are there particular advantages over, say, Scribe over FreePastry (http://www.freepastry.org/SCRIBE/default.htm http://www.freepastry.org/SCRIBE/default.htm)? How does routing efficiency compare?

zemanel 16y ago

first thing i thought when reading this was "distributed twitter"

pbrumm 16y ago

I like the idea. Having the data be encrypted would be cool too. A time-to-live would be nice so that it doesn't grow forever. Although it sounds like an easy place for virus writers to store plans of attack. And hard to take down without taking down the whole system which by design would be very difficult.