Alright this might be a tough one, but I'm going to try to pound on my keyboard until I feel like I'm able to convey what's been on my mind for a while now. I don't know if it's a stupid idea, maybe, but it's worth a shot. So here's the thought experiment: Can the internet work without IP addresses...?
Since starting to work on TollGate we've been in countless conversations around the structure of the internet that we have today. There's a bunch of large ISP's that all cooperate to keep this massive machine that is the internet alive. It's nothing short of a miracle that your vacation food-picture that nobody needs to see is instantly visible to friends and family on the other side of earth.
But this miracle has an issue. The Internet, meaning the substrate on which all our websites, email servers, relays and Nostr servers live, is not fully decentralized. It has had a hierarchy that was there since it's start in the 80's. IP addresses. It has worked amazingly well, but its Achilles heel is quite centralized.
Trees
RIR = Regional Internet Registry (continents) NIR = National Internet Registry (countries)
Anyone that's done some basic networking will know, IP addresses work in ranges. Those ranges are assigned. Assigned by who? Well, it depends. Inside your home network, your home network assigns the 192.168.x.x ranges. But outside of it, your ISP assigns it. And far above them, IANA.
IANA is the top of the world's IP tree, it's the final boss to decide who gets to have an address on the web, who exists, and who doesn't. Of course it's not that black and white, but the point is that they're a big boss. One that can assign and RETRACT IP addresses at will. We don't like that.
Mycelium
When extrapolating TollGate network growth into the future, we kept hitting an issue. Who's going to assign the numbers? We thought up so many examples, but it wouldn't really solve the issue. TollGate networks will likely organically grow together. When they touch, you'd want to automatically start routing traffic through these routes. However, in the current hierarchical system that doesn't happen automatically. ISP's have their ways of achieving this, but it's a 'trust-me-bro' system. We don't like that.
Pac-Man
I recently wrote about Pac-manning the web. A similar thing applies here. I want to be VERY careful about the areas of the stack to touch. Because we're talking about a system from the early 80's. It's a very well-designed system. We can't come in and trash the place just because we've got some new tools.
To give an example. You've probably heard about Retriculum, a protocol designed to replace IP's and use cryptographic identities and native encryption. Also optimizing for use by low-bandwith radio.
I have only scratched the surface of how Reticulum works so please forgive me if I'm not entirely accurate. (And please call out any bullshit). The following is not meant to diminish any of the love and hard work the people behind it have poured into the project.
One thing I've gathered from the docs is that Reticulum touches multiple layers of the (OSI) internet stack. Here, Reticulum describes how to use a program built with Reticulum. These words are important, because it signals to me that software needs to be written specifically to support transport over Reticulum.
It seems to me reticulum (RNS) affects the following layers.
I believe, in order to get any kind of mainstream adoption of a protocol that replaces ip, it MUST leave all the layers above intact.
The incompatibility spiral
I wrote in my recent progress report about an experiment during #SovEng where I attempted replacing IP with Nostr Pubkeys. What I noticed there was that BECAUSE I touched that layer, I now also needed to write my own 'ping' application because the normal 'ping' application doesn't speak pubkey, it would just throw an error if I called it with a pubkey, since it's not a valid IP address.
The same happens with curl, try entering a pubkey, it's not a valid domain-name or IP(v4/v6). Okay, now rewrite curl.
Now think higher up, all the applications we know and use everyday. They ALL just assume IP is there. All the libraries, anything that is built on IP, BOOM! incompatible. No developer is going to throw away their entire tech stack, just because there's a protocol that is better than IP. It either needs to be so mind-blowingly good that everyone, from app devs to isp's to datacenters want to adopt it at the same time. We'd have to do some insane, centralized worldwide cooperation project to pull that off. We don't like that.
Plasma - The backwards compatibility hack
Then now, how would we swap out IP addresses without affecting the whole stack?
I think I found the hack.
Okay so bear with me here. When we make an http request in the browser, what happens? It turns into a TCP session. What does TCP do? It's the coordination layer to handle a session between a client and a server. It decides how to cut up the http request into so-called 'segments'. These segments are then Encapuslated in IP packets, BY the IP layer.
This means that if we find a way to capture those segments. We can instead send them in our own protocol's packets. We don't want to do that for all traffic, because we don't want to break IP. Then how do we decide which traffic goes over FIPS and how do we signal that from the application level.
The hack? DNS!
Travel down with DNS
The trick I think we can employ is to use IPv6 as a means to travel down the stack, with a random identifier that is understood by ALL the layers in between the application layer and IP layer.
What we can do, is similar to #NoDNS. We employ a local DNS server that recognizes the fact we try to reach an npub, gives back a random ipv6 address and makes a note of npubX = fd21:cafe:beef::43. Then:
-
we let the application layer do its thing
-
we let the HTTP layer do its thing
-
we let TCP layer do its thing
And THEN we intercept all trafic for IPv6 address fd21:cafe:beef::43 and instead of letting it become an IP packet, we put it in a FIPS packet and send it off.
The practicality
So this what I just described is still theory. It's based off my recent learnings around NoDNS and the issues I hit during the #SovEng experiment. I still need to test this, but figured I should get down these words on (e)paper and share what I know.
So this will be my next experiment, check wether or not we can properly intercept and divert the TCP segments meant for an npub. If this works, which I deem quite likely, it means we are able to replace JUST ip addresses without breaking the entire stack above it.
What if it works?
If this DOES end up working, we can achieve significant advancements in routing.
For one, we can implement encryption at a lower layer. Meaning we need Zero round-trips to negotiate encryption between sender and receiver, because we can directly encrypt to the destination. Meaning we could ditch TLS and do it natively. Also: reducing the amount of round-trips is an incredibly hard problem to solve within the IP stack, it's one of the reasons behind development of the QUIC protocol.
(TollGate) networks that grow together can instantly start routing traffic, we wouldn't need to coordinate like we would with BGP peerings, which is the way it currently works between ISP's.
Native onion routing. Because every hop has a cryptographic identity, we could encrypt a package to every hop (and even include a cashu ecash reward).
There's a long list of possible shit we could do if it works, I'll just say this:
