telehash / tmesh Goto Github PK

I think the basic idea here is sort of a CDMA-meets-Onion routing approach, where you have a certain band(s) for the mesh will use. An epoch in that sense is a seed which pre-determines the time/frequency pattern of knocks and the encryption of their contents. Each mote ends up knowing the epoch(s) and z-index of all the other motes in physical range, [?] because until it does it communicates via a shared "lost mote" epoch on which neighbor information is broadcast.

When a message needs to be sent between any two motes, the source mote will send it to the highest z-index mote it knows (i.e. to its router), by choosing whichever of the epochs it considers most optimal. The packet is encrypted using that epoch as a key, and [?] broadcast at a particular time/channel also determined by the epoch.

Now when the source mote's router receives the packet, it decrypts the contents, revealing its payload — [?] half of which will be the destination hashname. If the destination is the mote itself, done. If the destination is in the mote's neighborhood [could it know this? I thought only the top-level router tracked those associations?] then it repeats the encrypt/knock process to that specific mote. Otherwise the packet goes again to the router.

If the packet makes it all the way to the top-level router without being delivered, the top level router will bounce it back "downwards". How it does this is curious to me — it can send it to lower-level router in the right direction, but it seems unless that router has the target in its immediate neighborhood the packet would end up back at the top-level again. Perhaps this is the clue:

A router … inherits the responsibility to monitor each neighbor's neighborhood for other routers and establish direct or bridged links with them.

So these routers are not just aware of the physical neighborhood sense, but also are serving in the Telehash sense.

In 1.4.2, "if they loose sync" should be "lose"

Every mesh must define and share one or more "lost epochs" that are used to send beacons for synchronization of any lost motes.

I'm thrown off by the "and share" part. I would imagine configuring each device with a lost epoch basically for any/every PHY mode it aims to support (e.g. one particular "rally point" where all the LoRa motes go back to if lost). For a given mesh this/these would all have to be "burned in" via some out-of-band provisioning mechanism, basically the secret password(/passport) of the mesh.

So why does the mesh "share" these epochs? Wouldn't any mote who could receive such a share already know it, sort of by definition?

Each epoch is capable of a max throughput of 120bps, or a total of
16k over the full epoch period (about 18 minutes). Every mote has at
least one receiving epoch and one sending epoch per link to another
mote, and will often have multiple epochs with other motes to
increase the bandwidth available.

I'm not sure what this is saying. From the glossary I sort of expected motes to communicate via knocks during windows. What does it mean that a mote has "at least one receiving epoch"? Should this read "receiving window per epoch" and likewise for sending?

The epoch 16 bytes are used as an AES-128 key, and the current count of total windows since the first sync is used as the IV.

This is kind of ambiguous to me. Do you mean operating in CTR mode directly, or is the count an actual IV for some other mode (GCM perhaps)?

The lost epoch headers are combined with the first 8 bytes of each mote's hashname to derive every mote-specific lost epoch. When lost or seeking a lost mote, a beacon with a minimum/zero length is transmitted during the mesh lost epoch to signal the mote's timing sync and current window (based on the frequency).

Is the implication here, that unless I already know a mote's hashname, I will not be able to communicate with it? (Perhaps this is already a given from a Telehash perspective? Am I remembering right that you need to have done some key-signing-party-type stuff before connecting?)

If so, then a mesh isn't really one big trusted "workgroup" which isn't too surprising, but then leads to the question of what distinguishes meshes from each other vs. just a global/public fabric? The willingness of motes to route only for/within that mesh?

1.4.3 "There is two mechanisms used" should be "are".

Currently a typo: "a unique addressible epoch id" should be "addressable" but this is also a surprising mention. I figured the epoch itself at 16 bytes was something of an identifier. Is the identifier something stable across multiple 18-minute epochs? Is there any policy for choosing one, or related to the hashname of involved motes?

The current spec doesn't seem to actually define when the knocks happen. Seems like it is intended to be some function of the epoch (which is itself a function of PHY parameters, sending hashname, and receiver hashname?) but it's not clear what the mapping actually is.

All payloads are encrypted before transmission regardless of if they are already encrypted.

My understanding is that this is facilitate consistent packet handling, so the requirement makes sense but not sure why its highlighted here. Under what circumstances might you expect an example of doubly-encrypted transmission to happen? Doesn't seem like you'd try forward HTTPS or something over a TMesh link to begin with due to its throughput.