YS001: Yggdrasil Core Specification #1
Conversation
neilalexander
added
draft
| hops from the root node down to a given node. | ||
|
|
||
| The root node sends a switch update message to all directly connected peers, | ||
| containing a timestamp and its own signing key. The switch update message |
There was a problem hiding this comment.
is timestamp in unix epoch seconds? or maybe milliseconds?
does this mean that nodes need to have synchronized times, or this timestamp is not absolute but relative to node key of node which sends it?
There was a problem hiding this comment.
Epoch seconds in practice but I that it just needs to be an increasing number so that an update doesn’t get replayed in the future. This section can definitely be made clearer.
| from the sender's public encryption key in the protocol message headers matches | ||
| the searched target Node ID (after applying a bitmask to account for any | ||
| unknown bits of the Node ID). If it does, the search is considered to be | ||
| completed and the node **should not** send any additional search requests |
There was a problem hiding this comment.
They're cached indefinitely? That doesn't sound too good, there should be limit of how long data is cached.
There was a problem hiding this comment.
Review is outdated - which lines are you referring to exactly?
| 3. Continue through the bytes until the initial length value has been reached | ||
|
|
||
| ### Message types | ||
|
|
There was a problem hiding this comment.
When a socket connection is initialized with a link, a meta message is exchanged.
Format of that message is
bytes['m', 'e', 't', 'a']varu64Major versionvaru64Minor versionbytesEncryption key (32 bytes)bytesSigning key (32 bytes)bytesEncryption key for this connection (32 bytes)
There was a problem hiding this comment.
This is deliberately not in the message types at the moment because it's not really a true protocol message — in our current implementation it is specific to TCP/TLS peerings. I am not sure if it is best to add a section specifically about TCP/TLS, or whether that should really be an extension spec.
| must be specified and known. Byte arrays **must** only be variable-length if | ||
| they are the last field in the message. | ||
|
|
||
| #### Coordinates |
There was a problem hiding this comment.
Maybe this section could briefly mention the purpose of coordinates. I'm not sure how a node's dynamic locator and coordinates are related based on what I've read here.
| The routing scheme is name-independent - that is, that the permanent address of | ||
| a given node is not permanently associated with the location of the node on the | ||
| network. This allows a certain amount of node mobility without relying on | ||
| subnet-based routing. |
There was a problem hiding this comment.
This section brought up two questions for me. I'm not sure if these questions should be answered in this document, but I'll leave them here in case others have an opinion:
- Node mobility is considered (which is awesome), but are there any known limitations in a node's ability to move and change their location within the network?
- How is the locator assignment related to a node's relative location to other nodes?
| Yggdrasil is a greedy routing algorithm. All nodes on the network have the | ||
| capacity to forward traffic on behalf of other nodes so long as doing so brings | ||
| the traffic closer to the intended destination, using only local knowledge. In | ||
| practice, only nodes that are directly connected to more than one peer will | ||
| forward traffic on behalf of other nodes. |
There was a problem hiding this comment.
This section brings up the following questions (feel free to ignore if it isn't relevant):
- Is it possible to merge bandwidth from multiple connected peers in order to have increased bandwidth to some other node?
- How quickly can nodes discover and begin making use of a node connection? Would yggdrasil be suitable for a drone swarm, or an interconnected car network, for example?
| Knowing the destination locator of the traffic in question, and the locators of | ||
| all directly connected peers, a node can work out which egress peering will take | ||
| the traffic closer to the intended destination. |
There was a problem hiding this comment.
If multiple nodes have a closer connection to a destination, then do nodes persist these possible routes to the destination? If so, then how are these routes prioritized, and how long are they persisted?
| Coordinates are an ephemeral identifier which represent the switch's location on | ||
| the network graph, relative to the root node. They are not a fixed value and can | ||
| change at any time depending on the node's own peers, or changing connectivity | ||
| on the path from the node up to the root node. |
There was a problem hiding this comment.
Maybe this definition of coordinates could be moved up to the Coordinates section starting at L177.
| responsibility of an implementation to know the format for a defined message | ||
| type and to be able to determine the end of a given field based on the | ||
| characteristics of that field type. Further details on this are available in the | ||
| base type definitions below. |
There was a problem hiding this comment.
This is not a great design, because it prevents you from defining new packets in a backwards-compatible way.
|
Any news? It would be useful for everyone who wants to implement ygg router. |
This is the initial draft of the YS001 Yggdrasil Core Specification. It is still a work in progress.
Still to do:
... and probably a number of other things!