Yggdrasil P2P mesh E2EE IPv6 network
yggdrasil-network.github.io
yggdrasil-network.github.io
The software is essentially a 'node', doing the routing. Whenever it starts it reads the config file to see if there is a private key in there. If no, it will generate a new one for you and that is your identity on the network.
> Just perhaps with something other than IPsec underneath?
That is correct, it uses standard, but not ipsec, encryption based on public key cryptography. A host that saves its private key will thus forever have the same IP address and if it runs services you connect to them using the encryption to its public key.
A node that is configured to connect to the wider yggdrasil public network will thus be reachable on a single IP with an identity that is based on public key cryptography, even if the machine is moving from network to network or even another continent.
In 2022, 128 bits is the bare minimum, and frankly 192 or 256 are often preferable.
I read the "About" page.
I read project's Github page.
Still - can't figure out what the project does and what would be practical application for it?.
Is it something like Tailscale?
Kind of, in that you can use it to replace Tailscale if you want. Using Yggdrasil as a DIY Tailscale replacement is probably less work than manually configuring WireGuard, because it handles the mesh features of Tailscale for you.
All nodes are publicly routable rather than private, though. If you want to lock everything down to emulate Tailscale, you can just configure your firewall to only allow traffic from a whitelist of your devices' Yggdrasil addresses[1].
[1]: https://yggdrasil-network.github.io/2018/07/15/remote-access...
As long as you don't add a public peer to any of your nodes, your network is private.
My biggest concern with Yggdrasil is that, without careful configuration of every node, anyone can connect to your Yggdrasil network and potentially expose it to the public Yggdrasil network.
I've moved on to experimenting with Nebula (made by Slack). This is made specifically for closed networks and has built in tools to restrict access. I still REALLY like Yggdrasil and will continue to experiment with it; just not for private meshing.
It seems (for some definition of seem lol) that more mindshare these days is around Ygg. CJDNS's author is working on something else at the moment primarily, and while they're still committed to working on CJDNS, their attention is split. Ygg is getting regular changes. Ygg's codebase being in Go also makes it a bit easier to get contributions in. But keep in mind that this may just be biased based on the circles I'm spending time in.
> Do you have a resource comparing CJDNS, Yggdrasil, Zeronet and maybe other similar protocol?
I wish I did. This would be a great thing to put together. Maybe I should spend some time properly comparing the two.
Original cjdns did not have supernodes.
When the author began contributing to cjdns had supernodes been added yet.
1. https://yggdrasil-network.github.io/2019/01/09/history.html
I first learned of cjdns from a video I saw on YouTube in 2012.^2 I was impressed by this person being interviewed. He described the most fundamental problems with the internet in plain English anyone could understand and he actually had a working solution!
The interviewer however did not seem to understand what the author was talking about. :)
Heh, I'm not sure if you realize this and are teasing me, but I'm the interviewer in that video! :-)
(or at least, a version of me that existed 10 years ago; amazing that it's been that long)
I thought it was a reasonably good interview, he was allowed to say what he wanted to say. Thanks for doing that.
I always wondered, was that the first time the project was announced publicly?
It is a computer network, like the internet. As a computer network, the practical application for it is similar to practical application for the internet.^1 One of its advantages over the internet is that users control their own IP addresses, not ISPs, and peer-to-peer connectivity is made easier. There is also no need for the use of TLS and all the third parties that profit as email/web gatekeepers. A peer-to-peer network offers an escape from an internet and web full of self-appointed third party middlemen, e.g., RIRs, ICANN, "tech" companies, certificate authorities, etc., who exploit their position for profit.
1. For example, people can run the same services via yggdrasil as they do via internet: https://yggdrasil-network.github.io/services.html
Yggdrasil is just an overlay over the existing Internet, not a replacement, which removes a lot of its usefulness.
Perhaps this means, in theory, that if you switch between multiple ISPs (e.g. phone + ADSL) or have dynamic IPv4 address, the IPv6 connectivity over Yggdrasil will stay the same.
Personally I've been using it for a while and its indeed living up to its promises, but ymmd.
It is indeed an overlay network by the simple rule of that being something that people can use. Technically the guys require the underlying protocol to keep order (one after another) in the packages for the stuff to work. Which is why building it on top of tcp/ip makes sense. Note that the ordering requirement is likely to be removed in a future iteration, again this is a research project.
Ideas like doing a mesh using antenna's in your city are thus, for now, out of reach. But the core concepts and approaches will likely map very nicely to such a usecase and the lessons learned as an overlay will help such a future design.
The public network is currently around 4000 nodes, which is why "scalable" is indeed meant to be vague. Tests of a million nodes are going to be required, probably in a future protocol iteration, to make clear statements about how scalable it really is. Signs are good, DHT usage is still very low while we saw a doubling of network size in the last 6 months.
In short, I use it daily. It works for me.
#yggdrasil:matrix.org
Clients who won't notice until they want to form a network at wild themself. In addition, average app developers are error prone at cryptography which are potential security holes.
Yggdrasil deals all of them as an all in one solution. Ad-hoc WiFi is enough to form a network. IP address is username, routing address and public key. App built on Yggdrasil is also freed from dealing with encryption and permission control.
> To understand what the value of Yggdrasil is, let's take a look at what we use today for networking.
https://news.ycombinator.com/item?id=27577201 (102 comments)
Would recommend to try it
Found it yesterday when someone posted this on lobste.rs, not sure how much it reflects the current version of the software.
I feel like 128 bits is a lot for address space but not enough for encryption.
Yes, collisions take sqrt(2^128) = 2^64 operations to find on average. Usually 256 bits is chosen to make that 2^128 operations if finding a collision poses problems.
With a centralized server and usage limits and depending on proprietary software. No, thanks.
But even now you don't have to use the project's infra. Private roots are possible if you want to be independent: https://docs.zerotier.com/zerotier/moons/
Also, their approach is to decentralize until it hurts, then centralize until it works. Calling it centralized is a bit of a stretch.
after configuring you need to restart the service.
you can run 'yggdrasilctl getpeers' to see if it actually connected to any peers. Use https://publicpeers.neilalexander.dev/ to find some local ones.
Ygg does not include a DNS, so use IP addresses directly. Notice that in most webbrowsers you need to add square brackets to indicate an IPv6 address.
Also notice that since yggdrasil automatically does end-to-end encryption, a lot of websites don't bother with ssl. So explicitly type http and turn off any plugins that turn your http into https.
The gateway possibility is there, someone needs to do it, is all. There are instructions on the website on how to setup such a gateway on your local router, so you do not need to install the binary on each device to access ygg services.
The main reason why there isn't really anyone really doing this is that this is a research project and most people that use it, use it for their own usecases. Not to offer some websites which aren't already on mainnet.
On the other hand, you would have to run an Internet gateway on one of the nodes, and give that address as a default route. It would work, but with a bit more manual work. IIRC someone ran a public Internet gateway at some point.
The yggdrasil address-space is different from the one used to give public IPv6 addresses.
If you add more than one, you might start routing between those nodes. Probably Ok on desktop, not so much on mobile.
For next steps, it picks one 'main' peer for your outgoing traffic, based on speed. (once an hour).
On a higher level, the system builds a tree out of the peers that are connected and you send data from one node to the other by directions. Think "left at church, right at heardresser". Or in yggdrasil it is "Go to node 10, then from there to node 1, then to node 5, then to node 6".
In short; a tree is built based on the elected root sending out a package and which peer sends it to you first. Indicating that that is the fastest.
You send data the shortest route though the mesh using local directions only.
Actual traffic is encrypted for the destination peer, so other than some headers needed to route, everyone in the middle will just forward an unreadable blob.
Though I must admit I don't yet know how Yggdrasil does routing.
https://www.howtopronounce.com/yggdrasil
How else could it be pronounced?
“Glory to you and your house”
https://github.com/yggdrasil-network/yggdrasil-package-freeb...
There is even a subsequent RFC whose title is, exactly, "RFC 1888 Is Obsolete":
https://datatracker.ietf.org/doc/html/rfc4048
Moreover, RFC1888 never moved beyond "experimental" status. Look at its heading, where it says "Obsoleted by: 4048 Category: Experimental", and its preface which explicitly states that "This memo does not specify an Internet standard of any kind."
What is yours?
I see that they don't use ULA after all, but their approach still spends 7 bits on the prefix.
The Yggdrasil people are very clear that this is a research project. Not to be used in production, to be used at your own risk etc etc etc.
In that light I find it unfair to claim it spends addressspace. Which, I might add, is pretty darn huge and we are not going to run out of addresses any time soon. If ever.
Maybe pedantic, but needed to point out that the 7 in `0200/7` of the usage is the opposite of being spent. The 7 first bits are the mask you need to apply to indicate that it is INSIDE the yggdrasil address-space. Which means that they only 'spend' 1 bit from from the first byte. Not 7.
I agree with you — in the context of IPv6 addressing in general, who cares about 7 bits? Heck, who cares about 64 bits?
Fair enough, I didn't catch that one.
The addresses generated has changed already from 0.3 to 0.4 (which is the series we see today), I expect that something will change again in future to make brute forcing harder.
Notice that in all cases the same IPv6 range was used, reusing the same space as upgrades change the individuals' IP address.
> there's no standard way to specify these interfaces across platforms / number these interfaces intelligently. if there was, we could have set aside a specific interface number for ygg, and then just used link-local addresses, which is technically more correct than using a global address that isn't actually global
[1]: https://matrix.to/#/!vVtVcVdzAdhGFLzFwm:matrix.org/$qpV7j6LY...