Four internets: Reticulum, I2P, Yggdrasil and Nostr side by side

Reticulum, I2P, Yggdrasil and Nostr keep getting lined up together — and wrongly so. They are not competitors: they fix different floors of the same building. One replaces radio and routing, the second hides who talks to whom, the third hands out addresses, the fourth takes your account away from the platforms.

500 bytesReticulum's MTU. It lives on a 300 bit/s channel — where TCP/IP will not even start

3 + 3Other people's nodes between a client and a site in I2P: its outbound tunnel plus the site's inbound tunnel

0200::/7The Yggdrasil range. An IPv6 address here is a public key fingerprint

0How much Nostr relays know about each other. The client spreads the copies itself

Each of the four fixes its own breakage

First the shortest version, with a schoolyard analogy. After that each one is taken apart separately, with a diagram showing exactly what happens to a message.

when there is nothing

Reticulum

A complete network stack for bad channels: a walkie-talkie, a wire, LoRa. It needs no IP, no provider and no speed.

Notes are passed hand to hand across the whole yard — and nobody on the way can open the envelope.

when you need to hide

I2P

An anonymous network on top of the ordinary internet. It hides not the content (any TLS does that) but who talks to whom.

The note is passed through six children, and each knows only who gave it and who they handed it to.

when you just need connectivity

Yggdrasil

A self-organising IPv6 network. It gives you an address from your own key — and all ordinary programs run on top of it unchanged.

Everyone got their own name that cannot be forged, and the yard worked out by itself how to reach each of them.

when the platform is the problem

Nostr

Not a network at all but a format for signed messages. Identity is a key, not an account on someone else's server.

The note is signed with your own signature and copies are pinned to three boards. One is torn down — the rest stay up.

They are not competitors — they are on different floors

Comparing Nostr with Reticulum is like comparing Instagram with optical fibre. Here is what each one takes on itself and what it borrows from the existing internet.

How to read it: the wider the band, the more the protocol replaces. Nostr is "full of holes": it takes only identity and message format and leaves delivery entirely to the ordinary internet. That is why Nostr runs inside Yggdrasil or I2P rather than instead of them.

Reticulum

Since 2016 · Python, Reticulum License · by Mark Qvist · rides on LoRa, radio, wire, TCP

A yard with no grown-up in charge. Everyone has their own seal that cannot be forged. A note goes into a sealed envelope and is passed hand to hand. If the recipient has gone home, the envelope waits in somebody's pocket until they come back.

Reticulum is not "yet another messenger" but a complete network stack, written from scratch for channels on which the ordinary internet simply will not start. It does not know what an IP address, a port or DNS is. No central registry: addresses are generated by the nodes themselves, and nobody can either issue them or take them away.

An address (destination) is 16 bytes of truncated SHA-256 of the public key and the application name. To be found, a node throws an announce into the air; transport nodes remember which way to go to reach it, and the path table builds itself. Encryption cannot be switched on — it is already on and cannot be switched off. In detail — in Reticulum up close.

The key point: the storage node holds the sealed envelope but cannot open it. That is why Reticulum works where the recipient appears on air once a day.

What is inside

• address — 16 bytes (128 bits) of truncated SHA-256 of the key and the application name
• crypto — X25519 for key exchange, Ed25519 for signatures, AES-256-CBC + HMAC-SHA256; ephemeral keys on links, i.e. forward secrecy
• MTU — 500 bytes: not an oversight but design, everything must fit into a LoRa frame
• carrier — LoRa (RNode), packet radio / AX.25, serial cable, TCP, UDP — and even I2P
• offline — LXMF and propagation nodes: mail waits for the recipient
• applications — Sideband (messenger), MeshChat, Nomad Network (something like a BBS)

Pros and cons

• ✓ The only one of the four that survives when there is no internet at all
• ✓ Encryption has no off switch — an "open mode" simply does not exist
• ✓ No need to ask anyone for an address: generate a key and you have one
• ✕ Not anonymous: transport nodes see the destination hash, and announces are public anyway
• ✕ Speed is in kilobytes. A photo will get there, video will not
• ✕ Real autonomy needs hardware: an RNode on LoRa
• ✕ The ecosystem is small, a lot has to be done by hand

I2P

Since 2003 · Java router and i2pd in C++ · garlic routing · a network in itself

The note is passed through six children, and each knows only two: who gave it and who to hand it to. And the reply goes an entirely different way. Nobody, even if they peek, can put together the picture "this one wrote to that one".

I2P does not hide the content — any TLS hides the content. It hides the metadata: who with whom, when and how much. It does this with two tricks. The first is layers of encryption: a message is wrapped so that each next node peels only its own layer and sees exactly one address — the next one. The second is unidirectional tunnels: the request goes along one chain and the reply comes back along another, so even someone who sees both ends cannot stitch them together.

I2P is most often confused with Tor. The difference is in the goal: Tor is built to exit to the ordinary web (and has centralised directory authorities for that), while I2P is a self-contained network within itself: .i2p sites, torrents, mail, IRC. Exits to the outside (outproxies) are rare here and not the point. And one more thing: Tor has separate relay nodes, whereas in I2P every participant is a router and carries other people's traffic — so your own gets lost among the transit.

The key point: one request uses six other people's nodes, and each tunnel lives just 10 minutes before it is rebuilt. That is what the latency pays for.

What is inside

• address — a Destination (387+ bytes, 516 characters in base64), shown outside as a short base32 hash: ukeu3k5o…q3a.b32.i2p. There is no DNS; human-readable names come from subscription address books
• tunnel — unidirectional, 3 hops by default, rebuilt every 10 minutes
• directory — netDb, a Kademlia-like DHT: RouterInfo (where the routers are) and LeaseSet (where the destination's inbound tunnels are right now)
• transport — NTCP2 (TCP) and SSU2 (UDP), both encrypted and obfuscated
• garlic — several messages ("cloves") are packed into one encrypted garlic envelope
• applications — eepsites, i2psnark (torrents), mail, IRC — all inside the network

Pros and cons

• ✓ The strongest of the four at hiding metadata: who with whom and when
• ✓ No centralised directories — the whole network holds the directory together
• ✓ Everyone carries other people's traffic, so your own does not stand out
• ✕ Slow: hundreds of milliseconds of latency, modest bandwidth
• ✕ For the first 10–20 minutes after start the router "warms up" and carries almost nothing
• ✕ Anonymity is easy to break yourself: just log in to your ordinary account
• ✕ Needs the ordinary internet — it will not run on bare radio

Yggdrasil

Since 2017 · Go · a world tree of IPv6 · ordinary programs work unchanged

Everyone got their own name that cannot be forged — it grew straight out of a key. And the yard, with no teacher, agreed by itself how to reach everyone: it drew a tree of paths and keeps it in its head.

Yggdrasil solves the most boring and most important question: how to find each other when there is no provider, NAT, public IPs or administrator handing out addresses. The answer: the address is the key. An Ed25519 key is run through a transformation and yields an IPv6 address in the 0200::/7 range. Nobody issued it and nobody can take it away.

Then the network builds a tree (spanning tree) out of all the participants and can find a way to any address, and since version 0.5 it also looks for shorter direct paths instead of sending everything through the root. Neighbours are found automatically via multicast on the local network or configured by hand — public nodes over TCP, TLS, QUIC.

The main practical value: a network interface simply appears in the system. ssh, http, Syncthing, a home NAS — all of it works over Yggdrasil without any changes, as if every device had a public IP. But this is not anonymity: neighbours see both your real IP and your public key.

The key point: the address is tied neither to a provider nor to a place. A device moves from Wi-Fi to mobile data — same address, the connection lives on.

What is inside

• address — IPv6 from 0200::/7, computed from the Ed25519 key; a /64 from 0300::/8 is given for a subnet
• routing — a global tree (spanning tree) plus path lookup; since v0.5 — direct routes bypassing the root
• neighbours — multicast autodiscovery on the local network or manual peering: TCP, TLS, QUIC, WebSocket
• encryption — end-to-end between the endpoint keys; a transit node carries but does not read
• interface — an ordinary tun in the system: every program just sees IPv6
• control — yggdrasilctl getSelf, getPeers

Pros and cons

• ✓ Nothing has to be rewritten: all existing programs work straight away
• ✓ The address is permanent and your own — neither NAT nor a change of provider moves it
• ✓ The easiest way to "stitch" your devices and your friends' into one network
• ✕ Not anonymous at all: neighbours see IP and key
• ✕ Traffic goes through other people's volunteer nodes — speed depends on them
• ✕ You need at least one neighbour with connectivity; on its own a node gets nowhere
• ✕ The network is still young; routing at large scale is an open question

Nostr

Since 2020 · "Notes and Other Stuff Transmitted by Relays" · by fiatjaf · WebSocket and JSON

The note is signed with your own signature, which cannot be forged, and copies are pinned to three notice boards. One board is taken down — the note hangs on the other two, and everyone who knows the signature will find it.

Nostr is the simplest of the four and the only one that is not a network at all. It rides on the ordinary internet, over ordinary WebSocket. All it invented is two rules. First: an identity is a secp256k1 key pair, not a row in someone's database. Second: a message (an "event") is JSON with kind, content and tags fields, signed with that key; its id is the SHA-256 of the event itself.

Relays are deliberately dumb servers: accept, store, return by filter. They do not talk to each other — the client itself spreads copies across several relays. That is where all the magic comes from: if a relay bans you, you take another, and your followers do not go anywhere, because they follow a key, not an account on a server.

There is a price for this too. A relay sees your IP and all your events — anonymity here is zero (unless over Tor). Spam is held back only by relay policy, paid relays and a web of trust. And losing the private nsec key is irreversible: there is nobody to "restore access".

The key point: there is not a single line between the relays — and that is not a simplification of the diagram, it is the protocol itself. That is why you cannot ban a person on Nostr: you can only ban their copy on your own server.

What is inside

• keys — secp256k1; the public one is npub1…, the private one nsec1… (bech32 encoding, NIP-19)
• event — {id, pubkey, created_at, kind, tags, content, sig}; id is the SHA-256 of the canonical form, the signature is Schnorr (BIP-340)
• kinds — 0 profile, 1 note, 3 follows, 7 reaction, 30023 long-form
• relay — a WebSocket server with three main commands: EVENT, REQ, CLOSE
• private — old DMs (kind 4) leak metadata; modern ones use NIP-17 on top of NIP-44 encryption
• money — zaps via Lightning (NIP-57): tips right in the feed

Pros and cons

• ✓ Identity does not belong to a platform: followers are tied to the key
• ✓ A relay is up in five minutes, there are dozens of clients
• ✓ Fast and familiar — it is just WebSocket over the ordinary internet
• ✕ Zero anonymity: a relay sees your IP and everything you write
• ✕ Lose your nsec — lose your identity for good, there is nobody to restore it
• ✕ Spam is held back only by relay policy, paid relays and a web of trust
• ✕ When the internet dies, Nostr dies too: it has no transport of its own

The same questions — four different answers

question	Reticulum	I2P	Yggdrasil	Nostr
What it is, in essence	A complete network stack from scratch	An anonymous overlay on top of the internet	An overlay IPv6 network	A format for signed messages
Address: where it comes from	16 bytes of hash of a key	…q3a.b32.i2p — a hash of the Destination	IPv6 from 0200::/7, computed from a key	npub1… — the public key
Transport: what it rides on	LoRa, radio, wire, TCP, UDP	NTCP2 / SSU2 over the internet	TCP, TLS, QUIC, WS and multicast on the local network	WebSocket over ordinary HTTPS
Without the internet: the "everything is down" scenario	yes — radio is self-sufficient	no	only on the local network	no
Hides who talks to whom: metadata	partly — transit sees hashes	yes, that is the whole point	no — neighbours see IP and key	no — the relay sees everything
Encryption: is there an off switch	Always, no off switch	In layers, on every hop	End-to-end between endpoint keys	Signature always; encryption only in private messages
Offline delivery: recipient not on the network	yes — a propagation node holds it	no	no	yes — the relay holds the event
Ordinary programs: ssh, http, rsync	no — must be written for RNS	via tunnels and proxies	yes — it is just IPv6	no — its own clients
Speed: what to expect	Kilobytes. Text and small files	Hundreds of ms latency, modest bandwidth	Almost like the ordinary internet	Like ordinary WebSocket
The main headache: what you pay	Needs hardware, few applications	Slow, the router warms up for 10–20 min	The participant is visible; speed depends on others' nodes	Lose the key — lose the identity
When it is the choice	Mountains, villages, emergencies, amateur radio	Nobody must know who talked to whom	Stitch your own and friends' devices into one network	Take your audience back from the platforms

Nobody wins on all three axes — and that is no accident

Anonymity is bought with latency, autonomy with speed, convenience with dependence on someone else's infrastructure. Each of the four consciously chose how to pay.

The ratings are qualitative, not measured: they show the direction of the trade-off, not a benchmark. The most interesting thing here is that no dot sits on the right of all three scales.

They stack inside one another

Since each occupies its own floor, there is no need to choose "either-or". Here are three combinations that really work, and one that will not.

Reticulum → over I2P

Among Reticulum's carriers there is an I2P interface. So the radio stack can be run through an anonymous tunnel while the internet is still there: you get both independent addressing and hidden metadata. And when the internet goes, the same stack switches to radio — and the address stays the same.

A Nostr relay → inside Yggdrasil or I2P

A relay needs no public IP, domain or certificate: it lives on a Yggdrasil address or as a .b32.i2p. There is simply nothing to block — no IP and no DNS record to put on a list.

Yggdrasil → over anything

Yggdrasil does not care what wire it took to reach a neighbour: TCP, TLS, QUIC, WebSocket — and therefore also through Tor or I2P. The network only sees "there is a link to a neighbour", and what lies under it is none of its business.

And this will not work

IPv6 (that is, Yggdrasil) over Reticulum. The IPv6 standard requires an MTU of at least 1280 bytes, while Reticulum's is 500. It is not a matter of settings but of different worlds: one counts bytes, the other assumes frames are large.

Each can be tried in an evening

Reticulum

# the stack itself
pip install rns
rnsd

# messenger: Sideband
# (Android / iOS / desktop)
# radio needs an RNode

A detailed walkthrough is in Reticulum up close.

I2P

apt install i2pd
# i2pd console: http://127.0.0.1:7070
# Java router: http://127.0.0.1:7657
# give it 15 minutes to warm up

Yggdrasil

# package from the project's repository;
# the config appears by itself: /etc/yggdrasil.conf
apt install yggdrasil

# add a public peer to Peers, then:
systemctl restart yggdrasil
yggdrasilctl getSelf   # your own IPv6 is here

Nostr

# nothing to install:
# Damus — iOS
# Amethyst — Android
# snort.social — web

# nsec1… — straight into a password manager

The "up close" series

• LoRa up close — the physical layer: chirps, spreading factor, time on air, range
• Meshtastic up close — a ready-made chat on "raw" LoRa: managed flooding, channels, node roles
• Reticulum up close — a network stack where the address is a key and LoRa is just one of the carriers