That advertisement would be interpreted as Node C’s advertisement.

The plan is to treat public keys as node’s identity and trust mechanism similar to OpenPGP (e.g. include any node key signed by a master key as a cluster member)

Right now, none of the encryption part is done and it is not a priority right now. I need to first implement transitive node detection, actually forward packets between nodes, some way to store and manage routes, and then trust and encryption mechanisms before I’d dare to test this stuff on a real network.

The UI is desktop only for now, I’ll make the mobile UI some day.

Awesome, reminds me of --> operator: https://stackoverflow.com/questions/1642028/what-is-the-operator-in-c-c

Gosh, if I ever get into the business of writing software for spacecraft with long duration missions, I have to test for such cases.

I would have wanted to be called out for not constructing URLs correctly.

You might have overlooked that we do not start out as experts. It is simply impossible. There is no way to guarantee that we know how to do things 100% correctly before writing correct code. Even if we were experts, we’re still humans, we’ll screw something up. This is just one of the reasons why we write proper tests and automate them.

The code had not been unit tested before

Because the smoke test procedure on our staging environment is currently a completely manual process without any automation.

Why do we have to keep learning to test and automate our tests as hard lessons?

Why do software engineering lectures not teach us about testing? If I were asked to teach software engineering (which TBH I shouldn’t be qualified to do just yet) I’d start with testing.

Seems like data: T or data: &'a mut T should work for you. Your function should be accepting mut self or &mut self.