> Maybe the story of Yggdrasil gave you a deep sense of clarity in your life path. I don't know, I haven't read it. But I don't need to read it to tell you that it's a diabolical name for a shell command.

Oh no no no no no...

• Evaluating riot.im client for matrix.org.
• Planning on looking at Yggdrasil as an overlay network.
• I have a few small GIT repos to off-load.
• Others mentioned keys.pub as identity services.

> Something like tunneling, or maybe a VPN somehow.

Check these out:

• CJDNS
• Yggdrasil
• /r/darknetplan

The nice thing about CJDNS and Yggdrasil is that

• encryption is built into the protocol (ALL traffic is encrypted)
• the IPv6 addresses are derived from the public key, so there is no need for certificate authorities.
• It works both on layer 2 (e.g. Ethernet, WiFi ...) and layer 4 networks (with UDP),
• It's decentralized*, so if your ISP is annoying (or if there isn't an ISP providing service at all), you can just connect with anyone else who is willing to share bandwidth.

^(* I'm aware meshnets tend to have horrible latencies, but a decentralized network can still use the (fast) backbones of ISPs. The main advantage is that it becomes a lot harder for ISPs to be a monopoly.)

So there are absolutely benefits to GNUnet. Let me give the devil's advocate position:

Yggdrasil doesn't require application-level changes. It has local multicast node discovery, automatic routing, and fantastic performance. It is super-simple solution to a lot of problems that darknetters and non-darknetters alike experience.

I don't think that there is one answer.

Skip the article about 'it'; go to the source:

Yggdrasil Network | End-to-end encrypted IPv6 networking to connect worlds

>Yggdrasil is an implementation of a new name-independent routing scheme and functions as an end-to-end encrypted IPv6 network.
>
>It is lightweight, easy to configure, supported on multiple platforms, and allows pretty much any IPv6-capable application to communicate securely with other Yggdrasil nodes. You do not need to have IPv6 Internet connectivity from your ISP — it also works just fine over IPv4.

https://yggdrasil-network.github.io/

[Users like you provide all of the content and decide, through voting, what's good and what's junk.]

https://prosody.im is a XMPP server that's light enough to run on a Raspberry Pi.

https://movim.eu is a social network platform built on top of XMPP.

Given you don't want people to deal with port forwarding, you'll probably need something like https://yggdrasil-network.github.io/ for an overlay network.

Enjoy!

ssh. It's accessible over internet on port 22 as I disabled password login. I usually access it over yggdrasil though (to bypass eventual firewall restrictions). Inter-server administration is done over VPN Though (wireguard), such as DNS transfert or backups over ssh (as root with ssh key).

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

Well that sucks. You might be able to use the Tor network and create a hidden service to make a device in your network accessible via ssh or something, but this will introduce quite some latency and be less accessible if you provide services for friends and family. Instead of Tor you could also try Yggdrasil, which should be much faster than tor (on some basic tests it's basically the same speed as my normal internet), but it's still quite young and has the same accessibility problems as tor. I think it could work quite well for a VPN though

One way to get an accessible IPv6 address on a host which only has IPv4 is to use Yggdrasil.

Every host on the Yggdrasil network gets assigned a unique IPv6 address that other Yggdrasil nodes can route to.

> Simply put, we have no idea how to handle global routing of IPv6 addresses. (Actually, some people do have ideas on how to do this, but as of yet their ideas haven’t gotten traction among the people who have control over how such things are done.)

Well, there's https://yggdrasil-network.github.io/ which is based on https://github.com/yggdrasil-network/yggdrasil-go/blob/master/doc/Whitepaper.md which fortunately doesn't require any specific blessings from people who control how things are being done but can be done by developers and end users on an embedded resource footprint, while remaining compatible with IPv6 Internet at lage.

Assuming you're looking for the sorts of marketplaces on Tor and the like to buy drugs and other Naughties--no, this is the wrong sub, plz to go elsewhere.

Assuming you're actually looking at resilient meshnet tech and alternate network topologies in the event of an Internet crash or physical censorship/blocking (which IS what this sub is about)--there's nothing that's a 100% turnkey solution, largely because a lot of the underlying tech for meshnets is under development and kind of experimental. You CAN buy hardware that will work as a physical layer of a meshnet, you'll need to generally implement the network stack and other OSI layers yourself (though this is actually not as horrible as it sounds; here's some examples with Yggdrasil, a popular meshnet solution on this sub, and a Ubiquiti EdgeRouter with an install of vyatta-yggdrasil or an install of Yggdrasil on an OpenWRT-capable consumer or small business router is about as close as you come to "turnkey").

Whatever autopeers on the local loop (Yggdrasil uses multicast https://yggdrasil-network.github.io/faq.html see https://yggdrasil-network.github.io/blog.html for some background, for a deep dive see https://github.com/yggdrasil-network/yggdrasil-go/blob/master/doc/Whitepaper.md ) is automatically end to end encrypted.

The network will remain private as long as there is no node which is explicitly configured to peer with some external one. If you peer with any node that is part of the Yggdrasil network (some ~600 currently) it will become reachable within the Yggdrasil network.

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

https://yggdrasil-network.github.io/about.html

Yggdrasil is a proof-of-concept to explore a wholly different approach to network routing. Whereas current computer networks depend heavily on very centralised design and configuration, Yggdrasil breaks this mould by making use of a global spanning tree to form a scalable IPv6 encrypted mesh network.

The following table illustrates high-level differences between traditional networks like the internet, and the Yggdrasil network: Traditional Yggdrasil End-to-end encryption for all traffic across the network No Yes
Decentralised routing information shared using a DHT No Yes
Cryptographically-bound IPv6 addresses No Yes
Node is aware of its relative location to other nodes No Yes
IPv6 address remains with the device even if moved No Yes
Topology extends gracefully across different mediums, i.e. mesh No Yes

...

Forthcoming EdgeRouter-12p with lots of PoE ports and two SFP slots looks like a great /r/wisp box for /r/yggdrasil type of mesh and overlay networks, using the vyatta-yddrasil package https://yggdrasil-network.github.io/platform-edgerouter.html

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.

Awesome. Notice there are Vyatta EdgeRouter packages, so you could run Yggdrasil directly on your edge firewall/router

https://yggdrasil-network.github.io/platform-edgerouter.html

Platforms like ER-X SFP paired with a cheap WLAN AP could be a good deployment infrastructure for a community mesh network, since the Yggdrasil instance runs on the ER-X while the APs are in bridge mode, powered by the ER-X and allow free placement, including directional outdoor ones.

I guess I should elaborate a little, just to note that Yggdrasil does a little more than what the OP asked for, but there's a good reason for every (non-optional) thing that it does. In particular:

1. It also handles address assignment. Routing and addressing are necessarily related to each other: a name-dependent routing scheme (one where identifiers, e.g. IP addresses, change when the network state changes) are easier to design and harder to use than name-independent ones. Yggdrasil uses a name-independent routing scheme. Since we need to assign addresses somehow, we derive them from public crypto keys (much like cjdns).
2. There's end-to-end crypto. This is as much for authentication as it is for privacy. If you don't encrypt or sign packets, then packet spoofing is trivial, which makes it much easier to do DDoS attacks. We don't want DDoS attacks, and of the two options, authenticated encryption is clearly better than just signing things (since it's faster than checking signatures and also keeps the plaintext of your traffic private).
3. Routing updates include a signature chain that prevents spoofing. This is sort-of similar to how S-BGP is supposed to work. Scaling doesn't do you any good if a single bad actor can announce fake routes and hijack your traffic.
4. A bunch of stuff related to congestion control. Relying on the end points of a connection to do this made sense when TCP/IP was running over wired links, where most random packet losses were caused by congestion. I don't think it makes sense to do that in a multi-hop wireless environment, where bad luck and interference from unrelated sources can cause random packet losses at any link.

I don't entirely understand what you're trying to do.

cjdns can autopeer on the LAN, so you you could run cjdns on the AP itself (not sure what the OpenWRT package situation is) and also on a small server (not a friend of raspies, prefer somewhat fatter servers).

You can run also cjdns directly on the EdgeRouter https://github.com/neilalexander/vyatta-cjdns (and also Yggdrasil https://yggdrasil-network.github.io/platform-edgerouter.html ) which can take care of handling e.g. stack Ubiquiti APs and leaves you to route traffic to Hyperboria at will.

I think we'll have the first smoke test when there's a full js-ipfs node capability present in each browser, which would scale to many millions of instances, most of them ephemeral. I would think at this stage we'll see the need to track node reputation, and penalize new nodes.

Unrelated to ipfs, we have definitely DHT-related cjdns routing scaling issues, though these are potentially addressed in the experimental mesh overlay network Yggdrasil https://yggdrasil-network.github.io/

> Sure - cases where the amount of sent data is smaller will of course incur more overheads, but given that the entire peering is carried over TCP, those small packets will be inlined within a stream along with anything else. In the event that congestion happens on the link, the LIFO queue will force a little bit of reordering perhaps earlier on than usual which will cause the inner TCP connection to be throttled down earlier to cope, which helps to reduce the net amplification effect.

I can see the argument, I'll be interested to see how it works out. I've considered doing the same thing with our WireGuard connection nesting, but I'm mostly concerned that the Wireless radios will flip out about packet loss (they have their own retry layer in the hardware and it needs to be babied a lot, maybe I should just find hardware that expects me to know what I'm doing)

Also our use of in kernel forwarding does not lend it self to coalessing packets like you seem to be, I assume your application handles forwarding more directly and gets the chance to pack and unpack data?

I guess you avoid the userspace/kernel divide during this packing and unpacking but I'm not sure it saves much work total. I should run the numbers.

> A new post was just put up about this a few hours ago which you might find interesting: https://yggdrasil-network.github.io/2018/07/17/world-tree.html

Ok that's 100% cool, I'll have to grok the paper then get back to you.

> Interesting design choice. I'll poke at your methodology a bit. Sure TCP over TCP is fine in the best case, where packets are normally full to the size of the MTU. But what happens in situations where this is not the case? > For example a low latency voice chat application that may want to send very small packets infrequently. Or even the majority of webtraffic. If you sample a pretty normal browsing/work session you'll find an average packet size around 400-500 bytes.

Sure - cases where the amount of sent data is smaller will of course incur more overheads, but given that the entire peering is carried over TCP, those small packets will be inlined within a stream along with anything else. In the event that congestion happens on the link, the LIFO queue will force a little bit of reordering perhaps earlier on than usual which will cause the inner TCP connection to be throttled down earlier to cope, which helps to reduce the net amplification effect.

> I'd really appreciate a blog post on the routing design, I'm not even sure if it's distance vector, link state, or dht based right now and it's possible there are design priorities that put things like low latency voice traffic out of scope.

A new post was just put up about this a few hours ago which you might find interesting: https://yggdrasil-network.github.io/2018/07/17/world-tree.html