Closed quartzjer closed 9 years ago
minor kibitzing: the very nature of telehash plays with the difference between DNS-like resolution and BGP-like pathfinding. were you thinking mainly of one, or the other, or both?
It is definitely both, in that the router returns zero information about the state of the destination (so the router does not provide resolution back), but does provide a forward path to deliver the request and a potential reverse path for any answers, so more BGP like from the router's perspective, and DNS like overall since the recipient can answer all the way back with more data about their hashname.
I'll just leave these tuples here for a bit:
(telephone, telephone number, switch) ~ (telehash, hashname, router)
It's clear that a telephone is a physical object, and that an app is not a device. I haven't figured out how to resolve this possible term/category mismatch.
While the analogy does apply fairly well, I'm sensitive to promoting a router-designed architecture. They're important in dealing with real network topography, but the protocol is careful to ensure that every node can be equally capable in providing routing utility, there doesn't always need to be a "switch" for the telephones to work and any telephone can provide switching for it's peers :)
I would be especially interested in how routing relates to the underlying protocol. For example with 802.15.4 based transports like ZigBee or Atmel Lightwight Mes that already provide mesh routing between nodes. Is telehash more a layer on top of that or can it completely replace these protocols and work directly in top of 802.15.4?
@bachp it is a layer above that, all of the routing in telehash happens within the encryption and separate from the transport so it can't very easily serve or replace medium-level routing. It's logical routing above any physical routing.
One of the design goals though is to enable seamless bridging from a device on one of those physical networks to the internet or other networks, where any one of the local network nodes can act as the telehash router and provide transparent bridging when it is connected to multiple networks (it would see and relay hashnames from both networks).
I add a small diagram that might serve as an example use case:
+----------+
| |
| Device B +------+
| | | +--------------+ XXXX
+----------+ | +----------+ | | XXX XXXX
| | | 802.15.4 | | TCP XXXX XXXXX
+---------+ Device A +------------+ Access Point +---------------+XX Cloud XX
+----------+ | | | | | XXX XX
| | | +----------+ | | XXXXXXXXXXXXXXXX
| Device C +------+ +--------------+ +
| | 802.15.4 |
+----------+ | HTTPS
|
|
+---------+---------+
| |
| Client Webbrowser |
| |
| |
| |
+-------------------+
I was hoping to find some nice metaphors around (telehash, hashname) such as:
peer
request when a telehash has zero information other than a remote hashname.The direct comparison to BGP/DNS is probably too high level to be useful?
@dvanduzer I've been trying to use the term endpoint
to refer to any generic instance, and hashname
just as the address of an endpoint
, does that jive with what you're saying?
peer
requests.path
requests.Is that more clear?
Also, since issues aren't multithreaded I'll just ask here, @bachp in your diagram could you clarify if the AP is part of the mesh or is just a network transit provider (and Device A has an IP)?
@quartzjer I'm trying to start using "telehash" the way you're using "endpoint" here. I think I have opinions about global formatting of keyword versus JSON field
, but I'll leave that for another day. New comments:
peer
is used to broker both key exchange and handshaking, that sounds like it conflates path-finding.path
meant to exchange information about a third node or is that unrelated to "routing"?I'd love to get keyword vs JSON highlighting consistent, I love the experience of the bitcoin dev guide with the mouseovers/hypertext, but it's beyond my frontendablity :)
path
is just between two endpoints, nothing to do with routing except that usually a "router" is the best one to inform you of your current public udp4 path :)
Given that it's a very common pattern, it's not documented very well/clearly.