Peer-to-Peer
You now know what Avatarnet stores, how it is organized, and who can see it. But how does any of this reach you? On the internet you use every day, the answer is simple: a server. On Avatarnet, there is no server.
The Internet You Know
When you visit a website, your browser sends a request to a server. That server is a machine in a data center, owned by a company, running around the clock. It holds the data, decides who gets access, and sends back the response. Every interaction passes through it.
This model is called client-server. Your device is the client, the company's machine is the server, and the server is in charge. It works well enough when the server stays online and the company stays honest. But those assumptions do not always hold.
Every one of these has happened to real services, affecting real people. The fundamental problem is that client-server puts a single machine between you and your data. Remove that machine and everything breaks.
No Server, No Single Point of Control
Avatarnet takes a different approach called peer-to-peer, or P2P. In a peer-to-peer network, there is no central server. Every device that participates is both a reader and a host. Your laptop can serve Einstein's avatar to visitors. A university server can store thousands of avatars. A phone can browse without hosting anything. The network is the sum of its participants.
No single machine is in charge, which means no single machine can take the network down. No company can pull the plug because there is no plug to pull. If one device goes offline, the rest of the network keeps running.
This raises an obvious question. On the traditional web, if you want to find Einstein's page, you ask the server. If there is no server, how do you find anything?
The Distributed Hash Table
On the traditional web, DNS is the phone book. You type "google.com" and DNS translates that into an IP address so your browser knows which server to contact. DNS works, but it is centralized. A handful of root servers, managed by ICANN, sit at the top of the hierarchy. Domain registrars control who owns which name. With enough legal leverage, a government or corporation can seize a domain.
Avatarnet needs a phone book with no central authority. That phone book is the Distributed Hash Table, or DHT.
A DHT works like a phone book that has been torn into thousands of pieces, with one piece handed to every person in the city. No one holds the whole book, but everyone knows which neighbor to ask. You ask your neighbor, they point you to someone who is closer to the answer, that person points you closer still, and in three to five hops you have the entry you were looking for.
The algorithm that makes this work is called Kademlia. It defines "closeness" using a mathematical distance function so that every lookup converges quickly, even in a network of millions of nodes. The details of the math are not important here. What matters is the result: any record can be found in a handful of hops, without asking a central authority.
Each record in the DHT is stored on the 20 nodes whose addresses are closest to the record's hash key. This redundancy means the phone book survives even when individual nodes go offline. Records expire after a set time and must be republished, which prevents stale entries from accumulating.
How einstein.avtr Resolves
When a visitor types einstein.avtr into the browser, the network resolves that name in three steps. Each step queries the DHT for a different record, and each record changes at a different pace.
This three-layer design exists for efficiency. If a hosting node's IP address changes because the machine rebooted, only the third record needs updating. The name-to-key binding and the key-to-hosts binding stay the same. Without this separation, every IP change would require updating every avatar record that mentions that host, potentially thousands of records at once.
The first step is the Avatar Name System, or ANS. It maps .avtr names to public keys in the DHT, replacing DNS entirely. Once a name is certified, that mapping is permanent. Even if the avatar goes offline forever, no one else can claim the name.
Who Participates: Node Types
Not every device on the network does the same job. Avatarnet defines five roles, and a single machine can play more than one at the same time.
A university might run a beacon for its own institutional avatar while also mirroring thousands of public avatars from other creators. A home laptop might be a beacon for its owner's avatar and a receiver for everything else. A dedicated server in a data center might do nothing but relay traffic and mirror popular content. A phone might act as a satellite, browsing your own avatar while offloading AI chat inference to your beacon at home.
The beacon is the only role that requires a specific relationship with an avatar: you can only be a beacon for your own. Every other role is open to anyone.
Institutional Nodes
Some machines on the network are run by institutions: universities, archives, hosting providers. These register a .node domain name (like oxfordarchive.node) through the same DHT that resolves .avtr names. The .node domain identifies the infrastructure, not a person.
A single .node provider can manage many nodes, and each node can host hundreds of Network Estates. Think of it like an apartment building: the building is the .node provider's infrastructure, and each unit is someone's Network Estate. The building has its own address (the .node domain and node keypair), and each unit has its own lock (the Estate Key). You own your estate regardless of which building hosts it.
At smaller scales, the same model applies. Your own computer running a node is a house you own. A dedicated server you rent is a house you rent. A .node provider hosting many avatars is an apartment building where you own a unit. In every case, your Network Estate is your property, and it comes with you if you move to a different building.
How Nodes Connect
All of this networking is built on libp2p, a modular library that handles peer identity, connection encryption, protocol negotiation, and the DHT. Avatarnet does not reinvent networking from scratch. It uses battle-tested building blocks from the same library that powers IPFS and other decentralized networks.
When two nodes connect, libp2p handles the handshake automatically. It establishes a secure, encrypted channel, verifies each node's identity against its Peer ID, and negotiates which protocol to speak. The connection is authenticated by the same public-key cryptography that protects the avatars themselves.
You already saw in Key and Hash Sizes how a machine's SLH-DSA public key is hashed and encoded into a compact Peer ID, and how the full network address is expressed as a multiaddr like /ip4/198.51.100.0/tcp/4242/p2p/QmYwAPJzv5CZsnN.... That Peer ID is the machine's identity on the network. It is separate from any avatar or estate keypair.
Three keys answer three separate questions. The node key answers "which machine am I talking to?" The Identity Key answers "who wrote this content?" The Estate Key answers "whose hosting position is this?" A single machine can host many estates, and a single person can run their estate from different machines at different times. Keeping the three keypairs separate means the network can verify machine identity, content authorship, and hosting ownership independently.
Nodes find each other and data flows. But what happens when a node goes offline? A laptop closes, a server reboots, a hard drive fails. If einstein.avtr lives on only one machine, that machine dies and Einstein is gone. The next page Replication explains how the network makes sure that never happens.