For the last several years I’ve been doing a lot of thinking on the general progression of the internet and where things may or may not have gone wrong. It’s sort of a trope at this point, so at the risk of sounding like the old man yelling at the sky, I won’t rehash the full argument.
Suffice it to say, I do despise the massive funnel that has been pushing people towards large centralized services for years now. Surveillance capitalism has seemingly experienced unbounded growth as a consequence. Invasion of privacy, intentional silencing, the rise of doxxing — all more or less able to be attributed to this funnel.
Now, I’m not here to say that we should just tear it all down and start over. There are a few legitimately good things that get lost in the process. What frustrates me is there seems to be very few alternatives that people can turn to. If grandma wants to look at pictures of her grandchildren on Facebook, who am I to stop her? But there is a growing group of disenfranchised, marginalized outcasts that are getting the short end of the stick.
So, as I’ve been working on DNTLS the last few months, I’ve started playing with the idea of a “new internet” that, to me at least, resembles what I thought it was going to turn into as a young adult. I would like to cast that vision in this article.
The concept of peer-to-peer networks has been around for a long time. It’s what many people harken as the “OG” internet. Whether it’s a mix of nostalgia or just a backlash to having centralization shoved down our throats, I do think it has some merit. The idea that I can host whatever I want on my computer and share it, securely and privately, with my friends is something that I think a lot of people have been yearning for.
This last weekend, I was able to demo what that “OG” internet might look like today. The substrate itself consists of a few systems, all of them built on DNTLS over a peer-to-peer network, so to avoid overwhelming the reader, I will try to break them down individually and then put them together in the end.
As a quick recap, DNTLS is a protocol I’ve been working on with my co-founder, Steven, for a number of months now. The premise is a “decentralized root of trust.” Meaning, rather than placing trust in a centralized system, like a certificate authority, we instead build out a decentralized system that performs much of the same functionality.
DNTLS is based around human readable names. If Bob registers bob.dntls and Alice registers alice.dntls then Bob may ask Alice to prove she owns that name and she can do it over a trustless connection. Because names are backed by cryptographic keys, Bob can sign arbitrary data that Alice can then prove was Bob by querying the decentralized root of trust.
The root of trust in this exchange is the DNTLS decentralized trust root. Bob and Alice don’t simply believe each other because they claimed to be bob.dntls and alice.dntls respectively. They both query the trust root to verify that the cryptographic proof signature each is presenting is actually valid.
Mutual TLS (mTLS) has been around for decades now. It’s used quite frequently in enterprise settings, especially those trying to achieve zero trust networking. Perhaps the most common enterprise example would be SPIRE (an implementation of SPIFFE).
Yet, despite its lengthy history, it has yet to see mainstream adoption in the open internet. Most of the internet operates one way: I connect to a website, it proves it’s the website I’m expecting by presenting a signed certificate, and then we establish an encrypted connection. Very rarely, if ever, are people expected to present certificates when connecting to a website. There’s a lot of reasons for this, but one of the more obvious ones is that it’s simply difficult to extend the CA model of millions of websites to billions of people.
A natural property of DNTLS is that it enables trivial mTLS. When Bob wants to securely connect to Alice, both of them can generate short-lived x509 certificates, sign it with their name key, and then exchange them. Alice can verify Bob’s signature against the decentralized trust root and Bob can do the same for Alice. The actual lifespan of the certificates can be seconds in this model. Bob can use this same process to securely connect to John, Sally, or anyone else with a registered DNTLS name.
The decentralized trust root carries with it arbitrary metadata for each registered name. The metadata is a mix of standardized and non-standardized fields with arbitrary payloads. The DNTLS protocol is intentionally open-ended here; it doesn’t enforce a specific structure. Rather, it encourages common fields for standardization purposes but leaves the rest open for implementers to make use of.
As an example, let’s say Bob hosts a website somewhere and he wants people to be able to find it by querying this metadata. Bob can publish an “http” field that simply contains a list of objects, each with four subfields: protocol (IPv4/IPv6), address, port, and priority. Alice can then query bob.dntls in the decentralized trust root, find this field, and use it to connect to Bob’s website at whatever IP/port he advertised.
Of course, HTTP is one of hundreds of protocols capable of being represented here. Not only that, but we’re not limited to protocols, it can carry any arbitrary data: a proof of personhood token, a blockchain wallet address, a list of AI agents that Bob runs, etc.
For simplicity sake, let’s assume Bob and Alice are close friends and they want to securely work together over the internet with each other. They will be the main characters to show how I propose the “new internet” might look.
In the above diagram we have Bob hosting a static website (via NGINX) on his local computer and Alice accessing it from Chrome running on her local computer. The process looks something like this:
Alice types
https://bob.dntlsinto her browserAlice’s “Local Trust Resolver” is configured to intercept DNS queries to this TLD
The resolver returns something on 127.0.0.0/8 and a random port to the browser
The browser establishes a TLS connection to the resolver which presents a CA Alice’s computer already trusts (configured at install time, never used anywhere else)
The resolver uses SNI and finds the browser is asking for
bob.dntlswhich it promptly performs a lookup for, seeing if Bob advertises anyhttprecordsBob had already published that record and pointed it at the IPv6 address of his computer. Additionally, Bob configured his own resolver to listen on port 1234 and direct incoming traffic to his running NGINX container.
Alice’s resolver attempts to connect to Bob’s resolver which promptly presents a certificate signed by Bob’s name. Alice’s resolver performs a lookup and verifies the signature is valid.
Likewise, Bob has configured his resolver to reject all incoming connections except for ones coming from Alice. So Bob’s resolver checks the certificate being presented by Alice and verifies it’s valid for
alice.dntls.The two resolvers establish a UDP tunnel over QUIC and then open a new stream to allow Bob’s NGINX container to stream data directly back to Alice’s computer.
Alice’s browser shows Bob’s website
The result of this dance is that Alice is able to form a direct P2P connection to Bob and view the website he’s running on his computer. Not only that, but the connection is E2E encrypted and validated from both sides: sally.dntls can attempt the same connection and fail because Bob’s resolver is configured to only allow Alice.
But wait a minute, Bob is using a home internet connection and is behind NAT. Bob fixes this by deploying a relay to a cheap VPS and advertising the relay’s public IP address instead of his own address. His resolver reserves a connection on it.
When Alice connects to Bob’s resolver, there’s two potential outcomes:
The resolver attempts a hole punching dance establishing the same QUIC tunnel between the two computers on a punched NAT port
The resolver proxies the tunnel directly from Alice’s computer to Bob’s computer over the reserved connection
Bob may choose either when deploying the relay. To break his NAT, he might just prefer hole punching. For maximal privacy and to avoid his home address from being leaked at all, he may choose to force everything through the relay.
The key thing to note here is that this QUIC tunnel is capable of streaming any logical protocol over UDP. It’s not just limited to FTP. If Bob and Alice want to share files, they can tunnel an FTP exchange over that same tunnel. Bob doesn’t even need to advertise what protocols he offers. Alice’s resolver can connect to Bob’s and ask, “Do you have FTP?” Bob’s resolver can respond yes and they can negotiate a new FTP stream going between a client on Alice’s computer and a server on Bob’s computer.
Bob can then configure his resolver to accept multiple different protocols over various ports all pointing to local services running on his computer. He can arbitrarily choose who to allow access to those services. Maybe he tells his resolver to allow anyone with a registered DNTLS name to access his website but only allows Alice to establish an FTP connection.
Protocol’s don’t even need to formally exist. Perhaps a later protocol comes along and Alice and Bob want to securely use it together. They just re-use the same pattern to tunnel it over the QUIC tunnel.
This is what I effectively prototyped in my homelab over the weekend. I was able to setup various machines across different hosting provides using a combination of direct or relayed connections and stream a number of protocols from machine to machine. All I had to do was stand up a service, configure my resolver, and then publish my (or my relay’s) connection details. As long as another machine knew my name, and I allowed the identity it presented, everything worked.
Notably, never once was there a centralized system involved in this process, and everything was securely encrypted. This is what I would imagine the “new internet” to look like. Free of prying eyes, no reliance on an intermediary service selling your data, and true peer-to-peer across the board.
Thanks for reading. If you’re interested in learning more about the DNTLS project, please head over to our website. From there you can register interest to gain access to our closed testnet and play with it yourself.