https://news.ycombinator.com/item?id=40828774

https://en.wikipedia.org/wiki/Yggdrasil

Just like many might pick cool and important names from Greek mythology for example, like Poseidon.

https://en.wikipedia.org/wiki/Poseidon

Right. You join the network by generating a random IPv6 address and telling someone about it. So anyone can generate vast numbers of dummy node addresses, which everybody has to track. Now you need spam filtering.

It seems to me that the main goal of the project is automatic routing that promises that in any peer graph any peer can reach any other at least somehow, which is fine for many use cases. Only in case of moving big data or very different cost of links you might want to check the node hierarchy and set manual peering from X to Y and Y to Z to make traffic flow the way you want.

Public network is a volunteer-run test ground for real life usage, and a way to connect systems that can't connect directly because of NAT. Internal speed test that is 8 hops away on the other side of the world gives me 30 Mbps, closer one, in 5 hops, reaches 90 Mbps (and the local interface is 100 Mbps), so it has some throughput for casual users.

As far as I can understand, current latency-based routing selection is just the most simple way chosen to optimise the network across the whole world, and prevent random 200 ms hops back and forth to intermediate nodes. If traffic from nodes in one half of the tree not having direct connections to the other half goes through the central nodes, it seems that at the moment it's enough for owners of central nodes to peer with each other, and have enough bandwidth. In the future they might need to take the proportions of available channels into account.

- [0] https://reticulum.network/manual/interfaces.html#listeners

I think what they really need is cheap solar nodes that have external WiFi antennas, so they can mesh over point to point directional links.

LoRa meshing seems like it's eventually going to be a dead end in any kind of dense environments, WiFi just gets you so much more bandwidth, and the edge nodes only need ~2mA of power.

AFAIK only Reticulum and Meshtastic have software support for that ATM.

I have a proof of concept almost working using OpenDHT as a global routing backend for Meshtastic, but Meshtastic still has some security issues (No authentication on a lot of important stuff), and global routing is really only currently easy to do for unicast traffic.

But if they got rid of the channel hash thing, and instead they gave each channel a special receive address(like IPv6 multicast groups) with their own keypair, global routing would probably work fairly seamlessly.

I think ideally they'd change those node/channel IDs to rolling codes so you can't traffic analyze the global routing.

With MeshCore, it doesn't seem like there's documentation on what info the packets actually give you, so I'm not sure how that would work.

And then with Reticulum, there's no C++ implementation of LXML yet, no standalone devices, or anything like that, so I'm not sure if it can replace Meshtastic/MeshCore until that exists.

Meshtastic is also lacking some applications layer stuff, they have the same issue most IoT protocols have, tons of predefined packets for specific sensors, but no modbus-esque generic telemetry packets, no way to just say "Register 59 is 37.6, look up what that means in the register layout file with UUID Jfjeiuehbdhd"

I think Reticulum is closer to having that, with the "fields" thing.

I'm not sure how the global routing works on reticulum though, I get the impression every node needs to know about every other node with some kind of gossip protocol, but I could be completely wrong.

Reticulum also used Kivy for their mobile app, which doesn't feel as polished as Meshtastic, and it's licensed under some non-commercial creative commons thing that causes issues including it in distro repos and such, or so I've heard.

Meshtastic doesn't exist as a convenient Arduino library or Pip installable package or anything like that, it's not exactly very elegantly embeddable in existing apps, and even if it was, it doesn't have the generic abstractions to actually do custom stuff in a way the app understands.

It almost seems like we either need a heavily redesigned Meshtastic 3.0, or something completely new.

They're all amazing projects, but they're all missing something.

the process would be run again and again during configuration generation until a key that fit this criteria was found. one could up the difficulty of this process considerably.. though not in a protocol backwards-compatible way.

you also needed to find a peer.

but yeah that's a gnarly hole.