telehash/telehash.github.io

Describe the routing role/flow

quartzjer opened this issue · 12 comments

quartzjer commented

Given that it's a very common pattern, it's not documented very well/clearly.

dvanduzer commented

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?

quartzjer commented

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.

dvanduzer commented

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.

quartzjer commented

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 :)

bachp commented

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?

quartzjer commented

@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).

bachp commented

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 |
                                                                                  |                   |
                                                                                  |                   |
                                                                                  |                   |
                                                                                  +-------------------+
dvanduzer commented

I was hoping to find some nice metaphors around (telehash, hashname) such as:

  • Given a hashname, a router does low-level pathfinding work between two telehashes.
  • A router can broker key-exchange via a 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?

quartzjer commented

@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?

  • Given a hashname, a router can broker key exchange and handshaking via peer requests.
  • After brokering handshakes, a router can cache a mapping of the tokens in those handshakes to the network paths they originated from to provide automatic bridging of encrypted channel packets.
  • A router may also return visible network paths back to the source hashname via 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)?

dvanduzer commented

@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:

  • When you say peer is used to broker both key exchange and handshaking, that sounds like it conflates path-finding.
  • The token mapping that allows bridging of encrypted packets sounds like the most conventionally understood meaning of "routing" for anyone reading these docs.
  • Is path meant to exchange information about a third node or is that unrelated to "routing"?
quartzjer commented

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 :)

  • Yeah I think it can be expressed as path-finding, a pretty strict bootstrapping of it
  • yep, routing!
  • 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 :)