The way I understand Yggdrasil (someone can correct me if I'm wrong) is that you won't DDoS other nodes as long as the other nodes that you are peered with have enough capacity:

> When deciding if to connect to another node, you should only connect to the ones that are “good enough” to be worth the effort. Here, “good enough” means that they have as much (approximately) at least as much bandwidth as your own. A fast node shouldn’t decide to connect to a slow node, instead the slow node should decide if it wants to connect to the fast one.

http://[319:3cf0:dd1d:47b9:20c:29ff:fe2c:39be]/2019/03/25/peering.html#rules-of-thumb

https://yggdrasil-network.github.io/2019/03/25/peering.html#rules-of-thumb

Matrix over Yggdrasil

Neil Alexander:

> Timothée has been working on a university project to integrate the Yggdrasil library into the CoAP proxy, which allows Matrix homeservers to federate over a pure Yggdrasil connection instead of using IP. The Yggdrasil portion gives full reachability and traffic forwarding between nodes in the mesh even in complicated topologies, and end-to-end encryption as an additional benefit

As a reminder,

> Yggdrasil is a proof-of-concept mesh network that is designed to avoid the scaling issues that we've seen in the past with existing mesh systems. It uses a spanning tree-based topology and aims to make all nodes in the mesh fully routable, even at massive scale

If you'd like to know more, come chat to the folk in #yggdrasil:matrix.org, and read https://yggdrasil-network.github.io

So we have the ability to target different architectures (e.g. ARM, MIPS) so a lot of this will depend on what the target platform is. I imagine it'll be easy enough to get a single Yggdrasil binary to run and that'll be the first task - it's possible the Linux ARM/MIPS binaries may even run already. After that, as I remember it, buildroot has documentation on how to create packages afterwards.