Permalink
Browse files

experimenting with another round of simplifications on the identity, …

…only public keys on the dht, no relaying
  • Loading branch information...
1 parent 14cecbb commit cfc6378603ec3276506734886913db479a1089e9 @quartzjer committed Aug 30, 2012
Showing with 28 additions and 29 deletions.
  1. +28 −29 org/v2.md
View
@@ -3,17 +3,20 @@ telehash v2 (draft)
## Intro
-The first version was a minimal layer to do just the DHT/NAT and tried to be very generic and extensible, deferring identity and transport to the app. This second version simplifies the base protocol and incorporates the identity and transport elements into the core.
+The first version was a minimal layer to do just the DHT/NAT and tried to be very generic and extensible, deferring identity and transport to the app. This second version drastically simplifies the base protocol and incorporates the identity and transport elements into the core.
## Vocab
* DHT - Distributed Hash Table
* NAT - A device/router that acts as a bridge to internal IPPs (Network Address Translation)
* IPP - IP:Port, 123.45.67.89:10111
-* Switch - An active IPP, making it part of the DHT
-* Packet - A UDP packet less than 1400 bytes sent between any switches
-* Session - When two switches establish a shared secret and a reliable connection between them
-* Thread - Simple request and response packet tracking between any switches
+* Hashname - The sha1(public key) of a RSA keypair
+* Profile - The JSON containing at least `key` being the public key, and other app-specific fields
+* Switch - The software hosting one more more hashname on active IPP, making them part of the DHT
+* Packet - A UDP packet less than 1400 bytes sent between any hashnames
+* Session - When two hashnames verify each other and maintain a reliable connection between them
+* Thread - Simple request and response tracking id within a session
+* Voucher - A JSON object containing `by` being the hashname doing the vouching, `x` an integer of the expiration time of the voucher (in epoch milliseconds), and `v` the signature of a Profile and the included expiration time.
## Parsing
@@ -23,17 +26,19 @@ Every packet must begin with two bytes that are a short unsigned integer represe
The top level keys of the JSON are for switch use only, the presence of different keys trigger different responses:
+### "to", "from" (IDENTITY)
+
+Any packet sent outside of a session must have a `to` and a `from` of the recipient and requesting hashnames.
+
### "tid" (THREADS)
The value is any string, and is the thread id as defined by the sending switch. When received and any response is generated at all, the same tid value must be returned so the sending switch can match up the response to it's request. The value format can be anything and is the domain of the sending switch only.
-### "start" (SESSION SETUP)
-
-This is to initiate a new session with any switch, and can be any arbitrary string value, but should be sufficiently unique and random per use so that it can't be guessed by anyone. Along with start, the `to` and `from` keys should also be set to the IPP of the sending and receiving switches, so that the public IPP can be identified and verified.
+### "sig", "x", and "sid" (SESSION SETUP)
-Upon receiving a `start` to create a session one must be generated to return and create the shared `sid` value, which is calculated as the SHA1 hash of both starts combined in either order. To validate, either side should combined the start values sent and received and compare to the `sid` value.
+This is to initiate a new session with any hashname, the included body must be a voucher. The value of `sig` is the signature of the voucher and the included `x`, the expiration timestamp.
-Once a `sid` is validate, it should be used for all future packets in that session.
+Upon receiving a `sig` one should be returned to create a full session. Any packets sent after the first one should include a `sid` being the sha1 of the initial sig and considered part of the session.
### "seq", "range", and "miss" (SESSION RELIABILITY)
@@ -51,20 +56,6 @@ When any switch is told about another, there may be a NAT between them, so they
The local switch is A, the existing one in the DHT is B, and this happens when B tells A about C, a new switch that A may be interested in. When A goes to contact C it should send the packet directly, as well as send a packet containing a `pop`:"IPP of C" to B. Upon receiving a `pop` with an IPP value that is not itself, it sends a new packet with a `pop` and the same value to the given IPP, as well as setting the `source` value to that of A. When C receives a `pop` value of itself, it sends a packet with `popped`:true to the value of `source`. If the first packet A receives from C is `popped`:true, it should resend the original packet since it was likely dropped due to the NAT, but the path is open now.
-### "recv" and "stop" (LISTENING)
-
-Only valid with a `sid`, the `recv` value is a hash to match against any incoming `send` value. All received values are associated with the active `sid`, so that once the session is over, they are all invalid as well. In order to validate a `recv` was accepted, the matching `send` and a tracking `tid` can be sent too, as any receiving switch should apply the `recv` before processing the rest of the packet, which would then match and be relayed back.
-
-To stop receiving any hash on a session, just send `stop` with the hash.
-
-### "bind" (IDENTITY)
-
-On any packet a `bind` can be sent, this is an object containing keys/values of a base URI and crypto signatures to validate it. The recipient should cache the validated mapping between the contained base uri and the IPP it came from.
-
-A `bind` enables the recipient to verify the sender's id and trust the IPP of that sending id. It can be sent proactively with any `send`, and can also be sent in response to any request to verify the responder.
-
-The contents of the `bind` are TBD.
-
### "req" and "res" (CONTENT TRANSPORT)
Any HTTP request can be performed within a session using the `req` and `res` objects. A `tid` is required and must be unique to each request.
@@ -90,17 +81,25 @@ The binary body is appended to the packet, and when broken across multiple they
The URI in the request doesn't need to be just HTTP either, this pattern can be used for streaming or other content transport patterns, and application specific schemes.
-### "send" and "see" (CONNECTING)
+### "seek" and "see" (CONNECTING)
-To reach any other switch you have to use the DHT to find it or the switches close to the same hash you're both using. You start by contacting any switch closest to the target hash and a `send` with the hash value (and any `bind` and `tid` and body as needed). If that switch knows any closer, it will respond with a `see` array of other switches closer than it. Take the top three closest and repeat the process until nobody responds or you get the `tid` returned with the reciprocating `bind` of the target you were trying to reach, connected to a new session with the sending IPP.
+To reach any other switch you have to use the DHT to find it or the switches close to the same hash you're both using. You start by contacting any switch closest to the target hashname and a `seek` with the hash value (and `tid` as needed). If that switch knows any closer, it will respond with a `see` array of other switches closer than it. Take the top three closest and repeat the process until nobody responds or you contact the target hashname.
-When a `recv` is matched with an incoming `send`, a new packet is sent in the session the `recv` came from copying in the `send`, `tid`, `bind`, and any body data, along with a `source` of the switch it came from.
+## DHT
-### DHT
+This is almost the same as telehash v1 and needs to be re-described here yet...
-This is the same as telehash v1 and needs to be re-described here yet...
+## Hashname state
+At any point the relationship between two hashnames would be in one of the following states:
+* UNKNOWN - no contact
+* SEEKING - one hashname is looking for another on the DHT
+* CONNECTING - was given an IPP for a hashname and sent it a sig
+* CONNECTED - both sent and received a sig
+* VALIDATING - requesting the profile of a hashname to get the public key to verify the sig value
+* VALIDATED - the sig and voucher check out
+* TRUSTED - the hashname or voucher are known and trusted

4 comments on commit cfc6378

In this version how do we listen for application specific seek?(.tap in v1)

Owner

quartzjer replied Aug 31, 2012

At a very high level for apps to be able to trust each other they must have some shared secret (or other more complicated framework, third party, centralization, etc)... so being able to use any hash as discovery requires other magic to make actually safe.

What I'm experimenting with here is absolute trust in any id on the DHT, and apps would have to build up their own p2p distribution mechanism from this, as a solid foundation.

I'm still considering a generic pub-sub method being part of core when the sender/recipient are trusted, but suspect that it might be easier to just run zeromq over telehash, that there's no advantage to it being built-in.

Thanks for the explanation. But another question is, as a new switch whose hashname is X joined the DHT, how does an existing switch Y found its IPP by hashname X? or how switch X could tell others "I'm with hashname X with this IPP"? As the hashname might not simply be the sha1 of IPP.

EDITED: i guess this is handled by newly added "from"

Owner

quartzjer replied Sep 3, 2012

Please sign in to comment.