So Much P2P

Tue, 03 Nov 2026 00:00:00 GMT

Peer to peer is everywhere, even when we don't really expect it. Video conferencing, many file sharing programs, some games, all P2P! This technology has advanced an enormous amount since Limewire and the old days of using BitTorrent.

But I'm not going to go over the long history of P2P and its use in the world–I just want to focus on the current state of P2P and the tech behind it.

Our first subject: IPFS.

Screenshot from Kubo, a IPFS client.

IPFS (the interplanetary filesystem, and yes, this really is used in-between planets!) is one of the largest P2P networks in known existence. IPFS runs a content-addressed network on millions of devices. Peers publish a list of CIDs (file/content hashes) which they possess and then other peers use this published data to find who has what data. Then any peer that knows the hash of some content, for example a file or website, can acquire that data from any peer on the network who has the content.

That's a bit of a mouthful, but IPFS itself runs on an internal P2P library called LibP2P.

LibP2P is a cross-language modular framework for P2P connections over a variety of transport protocols for a variety of data protocols. LibP2P itself is a collection of standardized data specifications declaring how the devices should communicate, the actual implementations them self only have to conform to the specification to communicate with other devices using LibP2P. Because of this, devices running LibP2P in different languages can still communicate with each other since they're just using the same protocol under the hood.

Maybe I'm a little biased… but LibP2P is probably the best and most comprehensive full P2P framework that exists.

The LibP2P project itself provides many official implementations across varying languages, such as Go, Rust, JavaScript/TypeScript, and even Nim.

Because of the agnosticism of the framework, there's an abundance of applications built in LibP2P

Let's look at some code! Here's a basic example taken from LibP2P go examples.

package main

import (
    "fmt"
    "github.com/libp2p/go-libp2p"
)

func main() {
    // start a libp2p node with default settings
    node, err := libp2p.New()
    if err != nil {
        panic(err)
    }

    // print the node's listening addresses
    fmt.Println("Listen addresses:", node.Addrs())

    // shut the node down
    if err := node.Close(); err != nil {
        panic(err)
    }
}

That's it! Although this example only listens on local addresses and prints them, it shows how simple the framework can be to use. There's far more that can be done, from NAT traversal to a DHT, the list goes on.

Next up, BitTorrent.

Screenshot from Transmission, a torrent client.

If you've not heard of BitTorrent or torrenting, you've probably been living in the woods. It's safe to say BitTorrent is the most famous (for good or bad) P2P protocol ever. BitTorrent is a file sharing P2P protocol that allows peers to download files from other peers (called seeders) at the same time rather than downloading a file from a single source. Peers then share chunks that they already have amongst one-another which results in fast and distributed file sharing.

But the infamy of BitTorrent and torrenting in general does not come from how useful it can be, it comes from pirates. While I'm not going to pass judgment on those who sail the high seas (after all, we've all wanted free movies before…), it's worth noting that since Piracy is illegal torrenting has become quite a hot topic in the media.

There are thousands, likely tens of thousands, of sites hosting torrent files (or magnet links) for pirated content that users can use to download copyrighted content through their favorite BitTorrent client. The most famous of which is The Pirate Bay.

But anyway, this article isn't about piracy, its about P2P.

BitTorrent is generally used for file sharing as it's a single protocol rather than a whole modular framework like LibP2P, however the individual components can still be used for general P2P. For example, the Mainline DHT used for content discovery, can be used by itself rather than exclusively for file-sharing over BitTorrent. Since the specification is public, anyone can write their own implementation and communicate with the BitTorrent DHT (for example, N0's implementation).

BitTorrent is an established and very well-used protocol in the P2P space, and it's not going anywhere. But since it's really only designed for file-sharing it limits the use to be for, well, file-sharing. Additionally, many ISP's or networks block BitTorrent as a whole due to its link to media piracy, even though the protocol itself is innocent and has many legitimate uses.

My final focus in this article, is an up and coming P2P library called Iroh.

Using sendme, an Iroh-based file sharing program.

Iroh runs on a simple principle: "IP addresses break, dial keys instead". Uh… okay? What does this mean? You may ask. Well, the way Iroh works is somewhat different.

Iroh is not exactly a pure P2P framework, as it relies on some centralization. Iroh clients need some sort of peer discovery method (well, not just Iroh, P2P in general), and those methods all need some sort of centralization. Iroh clients connect to some sort of relay (by default N0's public relay) and announce their public key, which is an asymmetric cryptographic key that identifies the peer on the network. Then, other clients can just contact the relay and ask for how they can connect to a given peer's key. In an optimal world, the relay temporarily lets peers send data over itself before a direct P2P connection can be made between the two peers over QUIC (NAT hole punching, IP address discovery, etc.). Then the relay would drop the connection and just let the peers talk with each other directly. However, if this direct connection fails, the relay will continue to… relay the data between the peers. Although Iroh peers can communicate without using a relay (IE, through MDNS or direct public IP's), the core point of Iroh is simple and reliable connections between peers which may or may not be behind a relay.

In theory, this sounds great! You can have P2P connectivity when it's possible, and when its not you can still connect to a device through a relay. And it practice, its also (usually) great. The only downsides on the actual application side is the centralization of peer discovery. Even though alternatives exist, it still is second class (as of now… N0 is adding new experimental transports and peer discovery such as using BitTorrent's Mainline DHT). However, there's another small downside, which is that it's really just a Rust library. While FFI bindings for other languages like Go and JavaScript exist, they're certainly less polished and nice to use than the main Rust implementation. For Rust developers (including myself), this isn't a problem as I use the language anyway. But for many who don't, they're unable to use Iroh except through (currently) shaky FFI bindings and cannot communicate with Iroh devices as opposed to LibP2P which has complete cross-language compatibility.

I certainly don't want to make Iroh sound unmaintained or unusable. It's an extremely useful framework that I've built applications in, such as capsul, a reliable P2P file storage system.

To conclude, there's a LOT of P2P technologies found in the wild, much of it is easier and more accessible than ever to both developers and users. Long gone are the days of extremely complicated, DIY, and broken P2P networks developers have to hand-roll themselves. Instead, they can reach for an already existing framework or library and just start building. There's still a long way to go, but I believe we're in the golden age of P2P.

The Mandelbrot Fractal

Thu, 29 Oct 2026 00:00:00 GMT

The Mandelbrot fractal is an extremely interesting little mathematical wonder. It's a simple formula, defined as:

f_c(z)=z²+c

Where z starts at 0.

Okay, but what does this actually mean in simple words us humans can understand? A number is in the Mandelbrot set if f(0) does not escape to infinity, and if f(f(0)) doesn't, and if f(f(f(0))) doesn't, you get the point. The function can iterate infinite times and the number never escapes to infinity.

How does it not go to infinity though if you iterate infinite times? Well, think of a number like 2. 2 squared is 4. If I keep squaring it the number expands to infinity. Now what about 1? 1 squared is still 1. Okay now what about a number like 0.5 (1/2)? 0.5 squared is 0.25 (1/4). I can square this as many times as I want and it never reaches infinity.

As long as a number remains in the range of [-1,1], it will never reach infinity when squared indefinitely.

However with the '+ c' in the formula this changes things. Now the number escaping depends not only on z but c as well.

Okay, so c is a complex number (re + im). That's ANY number. And, z is part of the function's iteration. The function can be represented pretty simply in code. Here's some pseudocode to demonstrate:

def is_in_mandelbrot_set(c):
    z = 0
    for 0..infinity:
        z = pow(z, 2) + c

        if (z == infinity):
            return False
        else:
            return True

If you've noticed, the 'function' mentions a 'set'. This is what we know as the Mandelbrot fractal. The Mandelbrot set is a set of all complex numbers that don't escape to infinity when passed through this function infinite times.

Okay… so the Mandelbrot set is just a bunch of numbers that don't escape to infinity. But how do we get these incredible visualizations? Well, these renderings are based off of the real and complex portions of all the numbers in the set.

Generally, image renderings show the real part of the complex number on the x axis, and the imaginary part on the y axis. The complex numbers represented by re + im are now mapped to (x,y) coordinates via (re, im).

Then, we calculate if the number is part of the set and color it if it is.

But then if we just plot the image we get a really generic black and white photo… what gives?

Well yeah, but this is all still theoretical. After all our function cannot possibly actually iterate to infinity.

In reality we escape the function after z escapes some arbitrary 'bailout' number we (the programmer/user) get to decide. Then we can use the number of iterations it took to sample colors from a color map.

This spices up rendering quite a bit, and makes it actually possible to render since we're not going all the way to infinity!

Great… now we have colorful renderings of the Mandelbrot fractal! It's worth noting that any value outside the range of Re [-2.5, 1] and Im [-1, 1] all escape to infinity, so for all the visualizations I've shown, the numbers all lie within this range.

Now it gets really interesting . We can 'zoom in' on the fractal on any given point where there's 'activity' and start to see some truly incredible patterns em merge.

Calculating 'activity' and 'zoom' is outside the scope of this blog post, but still worth looking into.

All of my visualizations are made with my own rendering program, mbrot. Go check it out! The code is all open source so feel free to inspect the actual real rendering algorithm

Anyway, as a send off, here's some cool fractals.

Logan's Blog

So Much P2P

The Mandelbrot Fractal