meshnet-lab

Most of the mobility testing has been performed either in the meshnet-lab[1] or the pineconesim[2]. As the original author of that documentation, it's quite entertaining to have it quoted back to me. :-) In any case the routing "prefers" links labelled as the internet when there is a tiebreak between two peerings between the same pair of nodes, i.e. you are connected to some other device via Wi-Fi and Bluetooth simultaneously. And while it is true that Pinecone cannot necessarily always make the best routing decision based on public keys alone, aggressive queue management attempts to provide the best QoS for all flows and it scales very well because nodes maintain only a small amount of state about their position in the spanning tree and their position in the SNEK. Importantly, shortcuts can and often are taken when Pinecone switches to t

Lots of interesting stuff there - thanks :) We're using https://github.com/mwarning/meshnet-lab rather than imunes.net for network simulation currently, but will take a look. Power usage is looking pretty positive so far; as long as we route the Matrix traffic over the routing topology rather than going full-mesh it should minimise radio usage (the main battery suck, other than screen). For store-and-forward, honestly using P2P Nodes as intermediaries is an okay approach other than exposing metadata to them. Our plan in the longer term is to switch to loopix-style mixnets to obfuscate the store and forwarding, a la nym. In terms of joining the network by deriving a private key from a passphrase... yup, that could be cute, although slightly terrifying in terms of the risk of weak passphrases :) We're hoping to get the P2P network stable