meshnet-lab VS firmware

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 tree-based routing as the geometric distance to the destination on the tree is evaluated at each hop. Routing "by the SNEK" is used primarily to find the remote node and as a fallback in case the tree routing fails.

[1] https://github.com/mwarning/meshnet-lab

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 in the coming year (although we were also aiming for this year originally :P)

This is a fantastic idea, thanks for sharing. I feel like LoRaWAN and LoRAMESH are the perfect solution for shuffling messaging around for home and property sensors, easily traversing a couple miles in poor conditions.

Prior to seeing this I was thinking about how to use the Meshtastic [0] project to fundamentally provide simple UDP services for message brokering over LoRa. There are so many sensors that could easily hook or connect to devices acting as network routers that could bridge other protocols across long distances very easily.

Have you looked at doing something similar with ZWave at all?

[0] https://meshtastic.org/

Truly independent peer-to-peer internet when?

Seriously, I think more and more about building a LoRa network with friends. https://meshtastic.org/

Agreed-- at least relaxing the restriction for UHF/SHF signals on a "secondary usage" basis (traffic must yield to plaintext). Potentially with with reduced power (say 100w) or minimum directionality, but I think a 'secondary usage' would be sufficient. Without doing so virtually all experimentation will continue to be deflected onto the ISM bands and we will lose our allocations through disuse.

So long as identification is still decodable, spectrum usage can be managed.

It's sufficient to prohibit commercial usage you don't need plaintext to do so. The old threat of tow trucks and cab services moving onto ham-bands had long since been mooted by ubiquitous cellular, but even if it weren't any significant commercial usage will eventually have a whistleblower. Usage that is obscure enough to not be vulnerable to whistleblowers could also be hidden just as well in "plaintext" traffic that was really uncrackable steganography.

As it stands you can't even lawfully log into your own personal systems over amateur radio even if you take the unreasonable steps of using specially modified software to authenticate-but-not-encrypt because inevitably some third party will send a message to you via the internet that contains some naughty words that aren't permitted over the radio.

Without relaxing the encryption rules, innovative radio usage like meshtastic (https://meshtastic.org/) will continue to be pushed onto ISM bands where (1) they're still technically unlawful because the homebrew hardware is not type-accepted (amateur bands are the ONLY place where homebrew intentional radiators are allowed!) and (2) where the band choices, power limit, and EIRP limits are detrimental to full exploration of the possibilities.

Besides, the FCC has long allowed proprietary, license fee bearing, patent encumbered digital modes. These are very close to encryption in terms of their ability to lock others out of ham comms, and have frequently been used by amateur radio groups to establish "lid free" communications channels. (Because most of the more irritating people aren't technically sophisticated enough to adopt some new mode without help, and people won't help them...).

The rules as they stand punish honest people who follow the intent and spirit of the rule in favor of people willing to just ignore the rules (including operating unlawful devices in ISM bands), willing to use stego, or willing to use obscure protocols to achieve the same ends that they'd otherwise achieve with encryption. It blocks modern networking by disallowing standard internet-grade software use with radio since all of it has integral encryption which generally can't be disabled to prevent downgrading and cross domain attacks in contexts where the encryption is needed -- or because in some cases the protocols are designed in such a way that authentication without encypherment isn't possible.

Meh.... very very low range.

For ~$20 you can get a LoRa dongle and https://meshtastic.org/, and with some luck (someone putting a node on a hgh building or a hill), you can reach quite impressive distances.

Meshtastic (version 30109): An inexpensive open-source GPS mesh radio for hiking, skiing, flying, marching.