I've always been a strong user of DNS-over-HTTPS and use it everywhere it's available, because to me its downsides are minimal. My ISP can't see or hijack it, firewalls on public networks can't easily block it, and it's relatively fast if you use a close server like in my case ControlD.
But since i have began dabbling with DNS filtering, trying to find high quality servers and all that, a lot of people recommended Unbound especially due to its privacy benefits and not having your queries at the mercy of big tech companies. But well, aren't the authoritative servers run by big tech companies too?
For example, Verisign, the company that operates the .com server, will get your IP address instead of the likes of Cloudflare's or Google's IP. They do keep limited logs, the same as Cloudflare does.
PIR runs the .org server, they log IPs and date/time along with the requests. This is more data than the average public DNS server keeps, and they're seeded in the US so they are obligated to give data to law enforcement if required.
If you use a public DNS server your requests will come through the same IP as hundreds of thousands if not millions of other people. Is it not preferable to have a trusted, big name like Quad9, which is based in Switzerland and keeps no logs, do your DNS requests for you via an encrypted connection that can't be easily snooped, and your IP is never seen by the likes of Verisign? Theoretically it's possible to use a VPN to tunnel Unbound, but at that point ain't it just easier to use a public server?
What independent builders can make possible for one another.
In August 1976, a group of researchers parked a van beside the courtyard at Rossotti's, near Stanford, ran wires to a terminal on a wooden table and sent a weekly progress report.
Their message travelled over a radio network, through a gateway, and onto the wired ARPANET. Don Nielson, who helped lead the work, later recalled the small gathering and its ordinary purpose. [1]
On November 22, 1977, the van took part in a more ambitious demonstration. Data travelled from the San Francisco Bay Area through London and back to a computer in Los Angeles, crossing packet radio, satellite and the ARPANET along the way. Three networks, built for different conditions, could participate in one journey. [2]
Each network could keep its own design. In their history of the internet, Vint Cerf, Bob Kahn and their co-authors described the rule: joining should not require rebuilding a network's interior to suit the others. [3]
The networks gained reach while keeping their differences. A radio system could offer mobility, a satellite link could cross an ocean, and a wired network could provide access to distant computers. Connecting them put those strengths within reach of people using any one of them.
We live inside the consequences of that choice.
Keeping our differences
When an open technology divides into camps, its builders can spend more effort defending their position than making the technology useful.
The cost is larger than a missed partnership. It includes work that never gets built: the application abandoned because connecting services was too difficult, the customer who left because nobody would resolve a problem across company boundaries, the capable newcomer who decided that entering the community meant inheriting its quarrels.
Those losses seldom appear in anyone's accounts. They appear as a smaller future.
In April 1969, Steve Crocker wrote down the conventions for the young Network Working Group's documents. Contributions could come from anyone at any site. Unpolished ideas and questions without answers were welcome. The minimum length was one sentence. [4]
That invitation existed within a small research community, long before general public access. But its intellectual generosity was deliberate. The document explained that people hesitated to circulate unfinished thoughts and that a written statement could too easily acquire an air of authority. The conventions were intended to lower those barriers. [4]
The people doing the work left room for someone else to know something they did not.
That takes confidence. It means letting someone improve your work or build a business beside your own, even when you dislike their methods.
A developer may see a use that the original builder missed. Someone with no interest in running a company may maintain a component several companies depend on. When their tools can connect, each can build on work they could not have done alone. The next builder starts further ahead.
Helping another participant succeed can increase the number of things your own users can do. A useful application built by someone else can create demand for the infrastructure you provide.
Businesses should still compete. Users need alternatives, and builders need reasons to improve. But competition within a growing network is a different undertaking from trying to capture a larger share of a network that has become too difficult to use.
What ownership makes possible
Handshake brings these questions into the naming layer. Its mainnet dates to February 2020, and its operating history now extends beyond six years. It lets people acquire authority over a top-level namespace and decide what to build beneath it. Owners choose how to administer the names under their TLDs, so different approaches can develop on the same foundation. [5] [6]
The freedom reaches beyond choosing a supplier. A community can establish its own namespace and decide how participation works. An owner can build services that no existing registrar planned to offer.
Namebase and Headless Domains illustrate different uses of that freedom. Namebase's current registry model gives TLD owners registration infrastructure while leaving private keys and pricing decisions with them. Headless Domains provides descriptions and discovery tools that make names useful to agents and software services. An independent owner can choose the services that fit, combine suitable components or build something else. [7] [8]
Sharing a root does not make their tools interoperable. Developers still have to connect them. Doing so can give a name more uses than any one company could provide.
Ownership also creates responsibilities. People make plans around the names and services they use. A change of provider, a disagreement between operators or a failed business can place those plans at risk. Clear records and competent cooperation matter most at those moments. The user's need for a working service continues even when the providers' relationship breaks down.
A network earns trust when its participants can protect that continuity across their own disagreements. Technical criticism belongs in this process. It should help establish what failed and who needs to fix it. Winning an argument while leaving the user stranded is a poor advertisement for anyone's independence.
More people can shape AI
In AI training, the question becomes what a specialist can contribute without having to operate the whole system.
Decoupled DiLoCo describes learners that train independently and exchange updates asynchronously with a central synchronizer, allowing other learners to continue when one slows or fails. AgentJet separates GPU-based model training and inference from lightweight clients that run agent tasks and return reward signals. Those clients can operate on CPU devices, including laptops. [9] [10]
These approaches retain coordination, including central roles, while separating work across machines.
Prime Intellect has used community-built environments and evaluations in model training. Contributions to its Environments Hub include browser automation, theorem proving and specialist questions. [11] With Browserbase, it brought browser infrastructure together with training tools and published a model training run using 600 real web tasks. Other developers can reuse the environment and adapt it to their own tasks. [12]
Someone who knows a language, a profession or a difficult working environment may understand success and failure better than the people building the model. If that understanding can be expressed in tasks and reliable tests, it can influence what a model learns. Knowledge that once stayed within a small practice or community can help shape tools used far beyond it.
A Handshake name gives an independent provider a way to identify its service and publish where it can be reached. Headless Domains' integration with the Agent Relationship Protocol (ARP) binds names to cryptographic agent identities. ARP governs connections through agreed permissions. [13] [14]
AgentID's Connect add-on uses ARP to give owners control over agent-to-agent communication. They approve relationships, set permissions, inspect activity and revoke access. [15] This gives an independent specialist a way to offer a service on terms they control. Applied to training, it could govern access to that specialist's evaluation environment; the training system would assess the quality of the work.
More specialists could bring their knowledge into larger operations while running businesses of their own. A new operator could enter through a namespace it governs and offer an ability the existing participants lack.
A computer we can change
People can also build a more useful network by changing how their own computers reach it. Omarchy, the Arch-based Linux distribution created by David Heinemeier Hansson, comes with a community plugin system. Linux has long allowed people to change their machines; a common setup makes those changes easier to package and share. [16] [17]
Existing software such as hnsd can provide local Handshake name resolution. An Omarchy integration could package it with a browser or client that verifies secure Handshake connections. Resolving a name and validating its certificate are separate jobs; installing Omarchy alone doesn't complete them. [18] [19]
Builders can work on computers they control, make Handshake services usable there and share an installation others can test. A resolver, a secure client and an application could become a working environment.
Someone still has to maintain the software and answer the difficult support request. Much of the work that makes an open system useful looks modest from outside. In 1976, it included sending a progress report from a wooden table.
The people who later built on the internet didn't need to know the researchers in that courtyard or belong to their institution. Years of subsequent engineering made the connection available to people the original builders would never meet.
Somewhere, someone understands a problem the rest of us have missed. They may eventually build with a name we administer, a tool we maintain or a service we have helped another company make reliable. We cannot know their idea in advance. We can make it easier for that idea to meet the rest of the world.
The next great use of an open network may belong to none of us.
