Message Routing Design

I thought about something similar before, however since we have a TLS handshake with client auth as part of the connection establishment, that can already be considered as a registration, and the disconnection deregistration.
any other reason you see for an additional explicit registration message?

addressed the above in a update:

  • made the optional fields compulsory
  • simplified the algorithm by removing encapsulation via FWD and instead use the VIA field for source routing

nice. completely removed or only for unicast?

better keep them the same, so I made both unicast and multicast messages use VIA for source routing, so the FWD encapsulation is completely removed now.

need to think about it some more. it’s good for now.

I put more thought into the design and updated the intro with a more precise explanation of the architecture, including the difference between the router and node components, and how these interact.

In other news my NGI0 project is also making progress with two protocol implementations pushed and work continuing towards adding network transport.