[ThatPlayer]

I think any wireless mesh like this runs into issues with scaling because you cannot efficiently route messages between a bunch of moving nodes as the network topology is always changing. You have to use a flood network, which is also what Meshtastic does [0]. Flood networking wastes bandwidth with every node repeating itself, and it gets even worse with wireless that's a shared spectrum.

All these mesh networks have a max hop limit, to prevent messages from bouncing around the network repeatably, but also not guaranteeing messages reach their destination. Meshtastic defaults to 3. Gotenna I believe is also Lora and is also 3. Bridgefy is bluetooth and has a 250 max hop limit, but also a 7d TTL, basically not close to real-time.

It could be made better by having statically position nodes that keep track of the nodes it can reach. And then having all these statically positioned nodes communicate with each other on a different wireless spectrum so you don't interfere with regular nodes. Since that topology isn't changing, you can efficiently route message between them. Now that's basically just regular wifi mesh.

[0] https://meshtastic.org/docs/overview/mesh-algo

[neilalexander]

There are more state-of-the-art routing protocols working to solve this problem for mesh networks. A couple examples of projects I have been involved in:

https://yggdrasil-network.github.io/ https://github.com/matrix-org/pinecone

[ThatPlayer]

I don't know if I consider those the same thing as they're not fully wireless meshes. They'll use the internet when possible, so it wouldn't be an off-grid network. And without internet, it won't scale.

So if you're using internet anyways, at high-density locations like a college campus, just deploy more wireless APs in the area instead of building an inefficient wireless mesh network. The wireless mesh part of those protocols is only useful for areas with no internet, but somehow enough people to build a chain to an internet connected device.

Reading Pinecone's documentation: "The only requirements for a peering today are that it is stream-oriented and reliable" [0]. I don't think a phone that's constantly moving around and battery operated (so you want to power-save by transmitting less) is considered reliable.

Pinecone's offline protocol also will not route to devices that haven't been seen in the last 10 seconds [1]. Basically preventing phones from sleeping or going into a low power state. That's also the kind of protocol that only works for small wireless mesh networks. A huge wireless mesh network would quickly be filled with "I'm here" broadcasts if a device is expected to do it every 10 seconds and it has to be repeated for everyone else on the mesh.

[0] https://matrix-org.github.io/pinecone/introduction

[1] https://matrix-org.github.io/pinecone/virtual_snake/maintena...

[neilalexander]

To be clear, neither Yggdrasil nor Pinecone have any concept of “the Internet”. A peering over the Internet is fundamentally the same as a local peering taking place over something like Wi-Fi or Bluetooth and they are not treated preferentially or handled differently.

Both protocols are also designed with mobility events in mind and measure far better than many other routing protocols on route convergence in highly mobile environments.

Also interpret “stream-oriented and reliable” as link-layer characteristics, i.e. a peering over TCP even if it is link-local satisfies these requirements. Not “reliable” as in “never goes away”.

[ThatPlayer]

Do you have any examples of their mobility event handling? I'm reading the documentation for Pinecone and don't see much. Even Pinecone says Yggdrasil's spanning tree isn't good enough: "However, the spanning tree topology alone is not a suitable routing scheme for highly dynamic networks." [0]

I'm reading that as why Pinecone has the virtual snake topology. But they define that as a public key-based routing, which doesn't take into account optimal routing in the network. Nodes are ordered by public key [1]. It's good for P2P mesh, not wireless offgrid meshes.

And their SNEK routing does prefer the internet over Bluetooth [2]:

> we can further refine the path to use either the faster or lower latency link type to route to that peer:

> If the Best candidate has a slower peer connection type (Multicast > Remote > Bluetooth) than the connected peer

[0] https://github.com/matrix-org/pinecone#does-pinecone-work-on...

[1] https://matrix-org.github.io/pinecone/snake

[2] https://matrix-org.github.io/pinecone/virtual_snake/nexthop

[neilalexander]

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 [2] https://pinecone.matrix.org or https://github.com/matrix-org/pinecone/tree/main/cmd/pinecon...

[ThatPlayer]

Thanks, looks interesting for sure, I hope to be proven wrong!