update site
This commit is contained in:
Raven Scott
@@ -0,0 +1,498 @@
|
||||
import type { Metadata } from 'next';
|
||||
import CodeBlock from '@/components/ui/CodeBlock';
|
||||
|
||||
export const metadata: Metadata = {
|
||||
title: 'How It Works - P2NS Documentation',
|
||||
description: 'Complete explanation of how P2NS works from domain registration to accessing services',
|
||||
};
|
||||
|
||||
export default function HowItWorksPage() {
|
||||
return (
|
||||
<div className="min-h-screen">
|
||||
<section className="py-20 bg-gradient-to-b from-blue-50 to-white dark:from-gray-900 dark:to-gray-800">
|
||||
<div className="max-w-4xl mx-auto px-4 sm:px-6 lg:px-8">
|
||||
<h1 className="text-4xl sm:text-5xl font-bold text-gray-900 dark:text-white mb-6">
|
||||
How It Works
|
||||
</h1>
|
||||
<p className="text-xl text-gray-600 dark:text-gray-300">
|
||||
Understanding the complete P2NS workflow from start to finish
|
||||
</p>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section className="py-20 bg-white dark:bg-gray-900">
|
||||
<div className="max-w-4xl mx-auto px-4 sm:px-6 lg:px-8">
|
||||
<h2 className="text-3xl font-bold text-gray-900 dark:text-white mb-6">Introduction</h2>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
P2NS (Peer-to-Peer Name System) is a decentralized DNS system that allows you to access services and websites
|
||||
without relying on traditional DNS servers or centralized infrastructure. Instead, it uses a peer-to-peer network
|
||||
where nodes work together to resolve domain names and establish direct connections.
|
||||
</p>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
Unlike traditional DNS where a central authority controls domain names, P2NS uses a distributed ledger where
|
||||
anyone can claim a domain and peers vote to reach consensus on which service should be associated with each domain.
|
||||
This makes it resistant to censorship and single points of failure.
|
||||
</p>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-6">
|
||||
The system uses advanced networking techniques like UDP hole-punching to connect through firewalls and NAT,
|
||||
making it possible to access services even when they're behind restrictive network configurations. Let's walk through
|
||||
exactly how this all works, step by step.
|
||||
</p>
|
||||
|
||||
<h2 className="text-3xl font-bold text-gray-900 dark:text-white mb-6 mt-12">The Big Picture</h2>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
Here's a high-level view of what happens when you access a P2NS domain:
|
||||
</p>
|
||||
<div className="bg-gray-50 dark:bg-gray-800 p-6 rounded-lg mb-6">
|
||||
<pre className="text-sm text-gray-700 dark:text-gray-300 whitespace-pre-wrap font-mono">
|
||||
{`1. User Request
|
||||
↓
|
||||
2. DNS Query → P2NS DNS Server
|
||||
↓
|
||||
3. P2P Network Lookup → Find Domain Hash
|
||||
↓
|
||||
4. Virtual Interface → Assign Local IP
|
||||
↓
|
||||
5. Holesail Client → Establish Tunnel
|
||||
↓
|
||||
6. HTTPS Proxy → Route Request
|
||||
↓
|
||||
7. Service Response → Back to User`}
|
||||
</pre>
|
||||
</div>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-6">
|
||||
The key components involved are: <strong className="text-gray-900 dark:text-white">peers</strong> (other P2NS nodes),
|
||||
<strong className="text-gray-900 dark:text-white"> Holesail</strong> (for firewall traversal),
|
||||
<strong className="text-gray-900 dark:text-white"> virtual interfaces</strong> (for local routing), and
|
||||
<strong className="text-gray-900 dark:text-white"> proxy servers</strong> (for HTTPS handling). Let's dive into each step in detail.
|
||||
</p>
|
||||
|
||||
<h2 className="text-3xl font-bold text-gray-900 dark:text-white mb-6 mt-12">Step-by-Step Process</h2>
|
||||
|
||||
<h3 className="text-2xl font-semibold text-gray-900 dark:text-white mb-4">Part 1: Setting Up a Domain (Service Provider Side)</h3>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
Before anyone can access a service through P2NS, the service provider needs to register their domain. Here's how it works:
|
||||
</p>
|
||||
|
||||
<h4 className="text-xl font-semibold text-gray-900 dark:text-white mb-3">1. Generate a Holesail Hash</h4>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
The service provider first needs to create a Holesail connection hash. They run:
|
||||
</p>
|
||||
<CodeBlock code="holesail --live 80" />
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
This generates a random cryptographic string (hash) like <code className="bg-gray-800 dark:bg-gray-700 text-gray-100 dark:text-gray-200 px-1.5 py-0.5 rounded">hs://s00084bf87dfa89a3048fb081c0e6207eb5a</code>.
|
||||
This hash is stored on the DHT (Distributed Hash Table). Other peers can use this hash to look up the service information on the DHT and establish a connection.
|
||||
</p>
|
||||
|
||||
<h4 className="text-xl font-semibold text-gray-900 dark:text-white mb-3">2. Create a Domain Claim</h4>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
Next, they register their domain (e.g., <code className="bg-gray-800 dark:bg-gray-700 text-gray-100 dark:text-gray-200 px-1.5 py-0.5 rounded">example.tld</code>)
|
||||
by creating a claim in the P2P network. This claim says "I own example.tld and it should point to this Holesail hash."
|
||||
The claim is stored in a distributed ledger called Autopass, which all peers can read and verify.
|
||||
</p>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
The claim is stored with a key like <code className="bg-gray-800 dark:bg-gray-700 text-gray-100 dark:text-gray-200 px-1.5 py-0.5 rounded">claim:example.tld:claimant-id</code>
|
||||
where <code className="bg-gray-800 dark:bg-gray-700 text-gray-100 dark:text-gray-200 px-1.5 py-0.5 rounded">claimant-id</code> is a unique identifier for the person making the claim.
|
||||
</p>
|
||||
|
||||
<h4 className="text-xl font-semibold text-gray-900 dark:text-white mb-3">3. Peer Discovery and Sync</h4>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
Once the claim is created, it's automatically synchronized to all connected peers in the network. Each peer maintains
|
||||
a copy of the distributed ledger, so the claim propagates throughout the network. This happens in real-time as peers
|
||||
connect and exchange data.
|
||||
</p>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-6">
|
||||
If multiple people claim the same domain, the network uses a voting and consensus mechanism to decide which claim
|
||||
is legitimate (we'll cover this in detail later).
|
||||
</p>
|
||||
|
||||
<h3 className="text-2xl font-semibold text-gray-900 dark:text-white mb-4 mt-8">Part 2: Peer Discovery and Network Formation</h3>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
For P2NS to work, nodes need to find and connect to each other. This happens automatically using a technology called Hyperswarm.
|
||||
</p>
|
||||
|
||||
<h4 className="text-xl font-semibold text-gray-900 dark:text-white mb-3">1. Topic-Based Discovery</h4>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
All P2NS nodes use the same "topic" to find each other. Think of it like a meeting room number - everyone who wants
|
||||
to participate in P2NS goes to the same room. The topic is generated from a seed string (<code className="bg-gray-800 dark:bg-gray-700 text-gray-100 dark:text-gray-200 px-1.5 py-0.5 rounded">p2ns-dns</code>),
|
||||
which ensures all P2NS nodes discover each other regardless of where they are in the world.
|
||||
</p>
|
||||
|
||||
<h4 className="text-xl font-semibold text-gray-900 dark:text-white mb-3">2. Connection Establishment</h4>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
When a node starts up, it joins the Hyperswarm network using this topic. Hyperswarm uses a distributed hash table (DHT)
|
||||
to help nodes find each other. Once two nodes discover each other, they establish a direct connection.
|
||||
</p>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
The connection process involves:
|
||||
</p>
|
||||
<ul className="list-disc pl-6 space-y-2 text-gray-600 dark:text-gray-300 mb-4">
|
||||
<li>Exchanging public keys for secure communication</li>
|
||||
<li>Setting up encrypted channels for data exchange</li>
|
||||
<li>Establishing replication streams for the distributed ledger</li>
|
||||
</ul>
|
||||
|
||||
<h4 className="text-xl font-semibold text-gray-900 dark:text-white mb-3">3. Data Synchronization</h4>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
Once connected, nodes use Corestore to synchronize the distributed ledger. Corestore is a distributed storage system
|
||||
that ensures all peers have the same data. When a new claim or vote is added, it's automatically replicated to all
|
||||
connected peers.
|
||||
</p>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
This means:
|
||||
</p>
|
||||
<ul className="list-disc pl-6 space-y-2 text-gray-600 dark:text-gray-300 mb-6">
|
||||
<li>Every node has a complete copy of all domain claims and votes</li>
|
||||
<li>New information propagates through the network automatically</li>
|
||||
<li>The network is resilient - if some nodes go offline, others still have the data</li>
|
||||
<li>No central server is needed - the network is truly decentralized</li>
|
||||
</ul>
|
||||
|
||||
<h3 className="text-2xl font-semibold text-gray-900 dark:text-white mb-4 mt-8">Part 3: DNS Resolution (When Someone Wants to Access)</h3>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
Now let's see what happens when someone wants to access a P2NS domain. This is where the magic happens!
|
||||
</p>
|
||||
|
||||
<h4 className="text-xl font-semibold text-gray-900 dark:text-white mb-3">1. The DNS Query</h4>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
When you type a domain like <code className="bg-gray-800 dark:bg-gray-700 text-gray-100 dark:text-gray-200 px-1.5 py-0.5 rounded">https://example.tld</code>
|
||||
in your browser, or when an application makes a DNS query, it goes to the P2NS DNS server (running on port 53).
|
||||
This server is configured as your system's DNS resolver, so all DNS queries go through it.
|
||||
</p>
|
||||
|
||||
<h4 className="text-xl font-semibold text-gray-900 dark:text-white mb-3">2. Checking the Cache</h4>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
First, P2NS checks its local cache to see if it recently resolved this domain. If the cache entry is still valid
|
||||
(typically cached for 30 seconds), it returns the cached result immediately. This makes repeated queries very fast.
|
||||
</p>
|
||||
|
||||
<h4 className="text-xl font-semibold text-gray-900 dark:text-white mb-3">3. Querying the P2P Network</h4>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
If not in cache, P2NS looks up the domain in the distributed ledger. It searches through all the claims stored locally
|
||||
(remember, each node has a complete copy) to find any claims for the requested domain.
|
||||
</p>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
The system looks for entries with keys like <code className="bg-gray-800 dark:bg-gray-700 text-gray-100 dark:text-gray-200 px-1.5 py-0.5 rounded">claim:example.tld:*</code>
|
||||
to find all people who have claimed this domain.
|
||||
</p>
|
||||
|
||||
<h4 className="text-xl font-semibold text-gray-900 dark:text-white mb-3">4. Consensus Mechanism</h4>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
If multiple people have claimed the same domain, P2NS uses a consensus algorithm to determine which one is correct:
|
||||
</p>
|
||||
<ul className="list-disc pl-6 space-y-2 text-gray-600 dark:text-gray-300 mb-4">
|
||||
<li><strong className="text-gray-900 dark:text-white">Count votes:</strong> Each claim can have votes from other peers. The system counts how many votes each claimant has received.</li>
|
||||
<li><strong className="text-gray-900 dark:text-white">Check quorum:</strong> A quorum (minimum number of votes) must be met. By default, at least 50% of active peers must vote, with a minimum of 2 votes.</li>
|
||||
<li><strong className="text-gray-900 dark:text-white">Resolve ties:</strong> If two claimants have the same number of votes, the system uses a tie-breaker (like preferring the oldest claim).</li>
|
||||
<li><strong className="text-gray-900 dark:text-white">Return the hash:</strong> Once consensus is reached, the system returns the Holesail hash associated with the winning claim.</li>
|
||||
</ul>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
This ensures that everyone in the network agrees on which service should be associated with each domain name.
|
||||
</p>
|
||||
|
||||
<h4 className="text-xl font-semibold text-gray-900 dark:text-white mb-3">5. Fallback to Public DNS</h4>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-6">
|
||||
If the domain isn't found in the P2P network, P2NS can fall back to traditional public DNS (like 1.1.1.1 or 8.8.8.8).
|
||||
This allows you to access both P2P domains and regular internet domains through the same DNS server. You can also configure
|
||||
local DNS records that take precedence over both P2P and public DNS.
|
||||
</p>
|
||||
|
||||
<h3 className="text-2xl font-semibold text-gray-900 dark:text-white mb-4 mt-8">Part 4: Virtual Interface Setup</h3>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
Once P2NS has the Holesail hash for a domain, it needs to set up local networking to route traffic to that domain.
|
||||
This is where virtual network interfaces come in.
|
||||
</p>
|
||||
|
||||
<h4 className="text-xl font-semibold text-gray-900 dark:text-white mb-3">1. Assigning a Local IP Address</h4>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
P2NS assigns each domain a unique local IP address from a configured subnet (default: <code className="bg-gray-800 dark:bg-gray-700 text-gray-100 dark:text-gray-200 px-1.5 py-0.5 rounded">192.168.3.x</code>).
|
||||
For example, the first domain might get <code className="bg-gray-800 dark:bg-gray-700 text-gray-100 dark:text-gray-200 px-1.5 py-0.5 rounded">192.168.3.2</code>,
|
||||
the second gets <code className="bg-gray-800 dark:bg-gray-700 text-gray-100 dark:text-gray-200 px-1.5 py-0.5 rounded">192.168.3.3</code>, and so on.
|
||||
</p>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
You can configure multiple subnets with different IP ranges, and P2NS will automatically allocate IPs from available subnets.
|
||||
This gives you flexibility to organize domains across different network ranges.
|
||||
</p>
|
||||
|
||||
<h4 className="text-xl font-semibold text-gray-900 dark:text-white mb-3">2. Creating the Virtual Interface</h4>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
P2NS creates a virtual network interface (like <code className="bg-gray-800 dark:bg-gray-700 text-gray-100 dark:text-gray-200 px-1.5 py-0.5 rounded">lo0</code> on macOS or <code className="bg-gray-800 dark:bg-gray-700 text-gray-100 dark:text-gray-200 px-1.5 py-0.5 rounded">lo</code> on Linux)
|
||||
and adds the IP address as an alias. This makes the IP address available on your local machine, even though it's not
|
||||
connected to a physical network.
|
||||
</p>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
The virtual interface acts like a local network adapter, allowing your system to route traffic to that IP address.
|
||||
When your browser or application connects to the domain, it resolves to this local IP, and the traffic gets intercepted
|
||||
by P2NS for processing.
|
||||
</p>
|
||||
|
||||
<h4 className="text-xl font-semibold text-gray-900 dark:text-white mb-3">3. Why Virtual Interfaces?</h4>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-6">
|
||||
Virtual interfaces are necessary because:
|
||||
</p>
|
||||
<ul className="list-disc pl-6 space-y-2 text-gray-600 dark:text-gray-300 mb-6">
|
||||
<li>They allow P2NS to intercept traffic destined for P2P domains</li>
|
||||
<li>They provide a consistent local endpoint for routing</li>
|
||||
<li>They enable the HTTPS proxy to handle TLS connections properly</li>
|
||||
<li>They allow multiple domains to coexist on the same machine without conflicts</li>
|
||||
</ul>
|
||||
|
||||
<h3 className="text-2xl font-semibold text-gray-900 dark:text-white mb-4 mt-8">Part 5: Holesail Connection Establishment</h3>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
Now that we have a local IP address, P2NS needs to establish a connection to the actual service. This is where Holesail
|
||||
comes in - it's the technology that punches through firewalls and NAT to create direct connections.
|
||||
</p>
|
||||
|
||||
<h4 className="text-xl font-semibold text-gray-900 dark:text-white mb-3">1. What Holesail Does</h4>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
Holesail uses UDP hole-punching to establish connections through firewalls and NAT (Network Address Translation).
|
||||
Traditional networking often fails when both the client and server are behind firewalls, but Holesail solves this by:
|
||||
</p>
|
||||
<ul className="list-disc pl-6 space-y-2 text-gray-600 dark:text-gray-300 mb-4">
|
||||
<li>Using a bootstrap server to coordinate the connection</li>
|
||||
<li>Sending UDP packets from both sides simultaneously to "punch holes" in the firewall</li>
|
||||
<li>Establishing a direct peer-to-peer connection once the hole is punched</li>
|
||||
<li>Maintaining the connection even through network changes</li>
|
||||
</ul>
|
||||
|
||||
<h4 className="text-xl font-semibold text-gray-900 dark:text-white mb-3">2. Using the Hash to Connect</h4>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
The Holesail hash we got from the domain claim is a random cryptographic string that acts as a key to look up the service
|
||||
on the DHT. When P2NS needs to connect, it:
|
||||
</p>
|
||||
<ul className="list-disc pl-6 space-y-2 text-gray-600 dark:text-gray-300 mb-4">
|
||||
<li>Uses the hash to query the DHT for the service information</li>
|
||||
<li>Retrieves the metadata stored on the DHT (host, port, protocol configuration)</li>
|
||||
<li>Uses this information along with the hash to establish the connection</li>
|
||||
</ul>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
P2NS creates a Holesail client that uses this hash to look up and connect to the service provider's Holesail server.
|
||||
The connection process happens automatically in the background.
|
||||
</p>
|
||||
|
||||
<h4 className="text-xl font-semibold text-gray-900 dark:text-white mb-3">3. Connection Persistence</h4>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-6">
|
||||
Once established, the Holesail connection can be kept alive persistently. This means:
|
||||
</p>
|
||||
<ul className="list-disc pl-6 space-y-2 text-gray-600 dark:text-gray-300 mb-6">
|
||||
<li>Subsequent requests to the same domain reuse the existing connection (faster)</li>
|
||||
<li>The connection automatically reconnects if it drops</li>
|
||||
<li>You can configure timeout behavior for non-persistent connections</li>
|
||||
<li>Multiple domains can share connections when appropriate</li>
|
||||
</ul>
|
||||
|
||||
<h3 className="text-2xl font-semibold text-gray-900 dark:text-white mb-4 mt-8">Part 6: HTTPS Proxy and Routing</h3>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
Now we have a Holesail tunnel established, but we still need to handle HTTPS properly and route requests correctly.
|
||||
This is where the proxy servers come in.
|
||||
</p>
|
||||
|
||||
<h4 className="text-xl font-semibold text-gray-900 dark:text-white mb-3">1. TLS Certificate Generation</h4>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
P2NS automatically generates TLS certificates for each domain using its own Certificate Authority (CA). When you first
|
||||
access a P2NS domain, the system:
|
||||
</p>
|
||||
<ul className="list-disc pl-6 space-y-2 text-gray-600 dark:text-gray-300 mb-4">
|
||||
<li>Generates a certificate for the domain if it doesn't exist</li>
|
||||
<li>Signs it with the P2NS root CA</li>
|
||||
<li>Includes the domain name and local IP in the certificate (Subject Alternative Names)</li>
|
||||
<li>Stores the certificate for reuse</li>
|
||||
</ul>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
You need to trust the P2NS root CA in your browser/system to avoid security warnings. The system can help install
|
||||
the root CA automatically.
|
||||
</p>
|
||||
|
||||
<h4 className="text-xl font-semibold text-gray-900 dark:text-white mb-3">2. HTTPS Proxy Server</h4>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
P2NS runs an HTTPS proxy server on port 443. When your browser makes an HTTPS request to a P2NS domain:
|
||||
</p>
|
||||
<ul className="list-disc pl-6 space-y-2 text-gray-600 dark:text-gray-300 mb-4">
|
||||
<li>The request goes to the P2NS HTTPS proxy</li>
|
||||
<li>The proxy uses the domain's TLS certificate to establish a secure connection with your browser</li>
|
||||
<li>The proxy then forwards the request through the Holesail tunnel to the actual service</li>
|
||||
<li>Responses flow back through the tunnel and proxy to your browser</li>
|
||||
</ul>
|
||||
|
||||
<h4 className="text-xl font-semibold text-gray-900 dark:text-white mb-3">3. HTTP to HTTPS Redirect</h4>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
P2NS also runs an HTTP server on port 80 that automatically redirects all HTTP requests to HTTPS. This ensures
|
||||
all connections are encrypted and secure.
|
||||
</p>
|
||||
|
||||
<h4 className="text-xl font-semibold text-gray-900 dark:text-white mb-3">4. WebSocket Support</h4>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-6">
|
||||
The proxy also supports WebSocket connections, allowing real-time applications to work through P2NS. WebSocket
|
||||
upgrades are handled transparently, maintaining the connection through the Holesail tunnel.
|
||||
</p>
|
||||
|
||||
<h3 className="text-2xl font-semibold text-gray-900 dark:text-white mb-4 mt-8">Part 7: Complete Request Flow</h3>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
Let's put it all together! Here's exactly what happens when you access a P2NS domain:
|
||||
</p>
|
||||
|
||||
<div className="bg-gray-50 dark:bg-gray-800 p-6 rounded-lg mb-6">
|
||||
<ol className="list-decimal pl-6 space-y-3 text-gray-700 dark:text-gray-300">
|
||||
<li><strong className="text-gray-900 dark:text-white">You type</strong> <code className="bg-gray-200 dark:bg-gray-700 px-1.5 py-0.5 rounded">https://example.tld</code> in your browser</li>
|
||||
<li><strong className="text-gray-900 dark:text-white">DNS query:</strong> Your system queries the P2NS DNS server (port 53) for <code className="bg-gray-200 dark:bg-gray-700 px-1.5 py-0.5 rounded">example.tld</code></li>
|
||||
<li><strong className="text-gray-900 dark:text-white">Cache check:</strong> P2NS checks its cache - if found and valid, returns cached result</li>
|
||||
<li><strong className="text-gray-900 dark:text-white">P2P lookup:</strong> If not cached, P2NS searches the distributed ledger for claims matching <code className="bg-gray-200 dark:bg-gray-700 px-1.5 py-0.5 rounded">example.tld</code></li>
|
||||
<li><strong className="text-gray-900 dark:text-white">Consensus:</strong> If multiple claims exist, P2NS runs consensus algorithm to determine the correct hash</li>
|
||||
<li><strong className="text-gray-900 dark:text-white">Hash retrieved:</strong> P2NS gets the Holesail hash (e.g., <code className="bg-gray-200 dark:bg-gray-700 px-1.5 py-0.5 rounded">hs://s00084bf87dfa89a...</code>)</li>
|
||||
<li><strong className="text-gray-900 dark:text-white">Virtual interface:</strong> P2NS assigns/uses a local IP (e.g., <code className="bg-gray-200 dark:bg-gray-700 px-1.5 py-0.5 rounded">192.168.3.2</code>) for this domain</li>
|
||||
<li><strong className="text-gray-900 dark:text-white">Holesail client:</strong> P2NS creates or reuses a Holesail client connection using the hash</li>
|
||||
<li><strong className="text-gray-900 dark:text-white">Tunnel established:</strong> The Holesail connection punches through firewalls and establishes a tunnel</li>
|
||||
<li><strong className="text-gray-900 dark:text-white">TLS proxy:</strong> P2NS sets up an HTTPS proxy using the domain's TLS certificate</li>
|
||||
<li><strong className="text-gray-900 dark:text-white">Browser connects:</strong> Your browser connects to the P2NS HTTPS proxy (port 443)</li>
|
||||
<li><strong className="text-gray-900 dark:text-white">Request forwarded:</strong> The proxy forwards your request through the Holesail tunnel to the actual service</li>
|
||||
<li><strong className="text-gray-900 dark:text-white">Response received:</strong> The service responds, and the response flows back through the tunnel</li>
|
||||
<li><strong className="text-gray-900 dark:text-white">You see the website:</strong> The response reaches your browser, and you see the content!</li>
|
||||
</ol>
|
||||
</div>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-6">
|
||||
All of this happens automatically in milliseconds! The first request might take a bit longer as connections are established,
|
||||
but subsequent requests are much faster as connections are reused.
|
||||
</p>
|
||||
|
||||
<h2 className="text-3xl font-bold text-gray-900 dark:text-white mb-6 mt-12">Consensus and Voting</h2>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
One of the most important aspects of P2NS is how it handles conflicts when multiple people claim the same domain.
|
||||
The consensus mechanism ensures the network agrees on which service should be associated with each domain.
|
||||
</p>
|
||||
|
||||
<h3 className="text-2xl font-semibold text-gray-900 dark:text-white mb-4">How Voting Works</h3>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
When a peer sees a domain claim, they can vote for it by creating a vote entry in the ledger. The vote key looks like:
|
||||
<code className="bg-gray-800 dark:bg-gray-700 text-gray-100 dark:text-gray-200 px-1.5 py-0.5 rounded">vote:example.tld:claimant-id:voter-id</code>
|
||||
</p>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
Peers typically vote for the claim they believe is legitimate. This could be based on:
|
||||
</p>
|
||||
<ul className="list-disc pl-6 space-y-2 text-gray-600 dark:text-gray-300 mb-4">
|
||||
<li>Who they know and trust</li>
|
||||
<li>Which claim was made first (timestamp)</li>
|
||||
<li>Which service they want to use</li>
|
||||
<li>Automatic voting based on local claims</li>
|
||||
</ul>
|
||||
|
||||
<h3 className="text-2xl font-semibold text-gray-900 dark:text-white mb-4 mt-8">Quorum Requirements</h3>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
For a domain to be considered "resolved" (consensus reached), it must meet quorum requirements:
|
||||
</p>
|
||||
<ul className="list-disc pl-6 space-y-2 text-gray-600 dark:text-gray-300 mb-4">
|
||||
<li><strong className="text-gray-900 dark:text-white">Percentage threshold:</strong> By default, at least 50% of active peers must vote</li>
|
||||
<li><strong className="text-gray-900 dark:text-white">Minimum votes:</strong> At least 2 votes are required, regardless of peer count</li>
|
||||
<li><strong className="text-gray-900 dark:text-white">Vote validation:</strong> Votes must reference existing claims (invalid votes are ignored)</li>
|
||||
</ul>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
This ensures that consensus isn't reached by just one or two nodes, but represents actual network agreement.
|
||||
</p>
|
||||
|
||||
<h3 className="text-2xl font-semibold text-gray-900 dark:text-white mb-4 mt-8">Tie-Breaking Strategies</h3>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
When multiple claimants have the same number of votes, P2NS uses tie-breaking strategies:
|
||||
</p>
|
||||
<ul className="list-disc pl-6 space-y-2 text-gray-600 dark:text-gray-300 mb-4">
|
||||
<li><strong className="text-gray-900 dark:text-white">Timestamp:</strong> Prefer the oldest claim (default)</li>
|
||||
<li><strong className="text-gray-900 dark:text-white">Claimant age:</strong> Prefer the claimant with the longest history in the network</li>
|
||||
<li><strong className="text-gray-900 dark:text-white">Lexicographic:</strong> Alphabetical ordering of claimant IDs</li>
|
||||
</ul>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-6">
|
||||
This deterministic approach ensures all nodes reach the same conclusion when resolving ties, maintaining network consistency.
|
||||
</p>
|
||||
|
||||
<h2 className="text-3xl font-bold text-gray-900 dark:text-white mb-6 mt-12">Key Technologies Explained Simply</h2>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
P2NS uses several advanced technologies. Here's what each one does in simple terms:
|
||||
</p>
|
||||
|
||||
<h3 className="text-2xl font-semibold text-gray-900 dark:text-white mb-4">Hyperswarm</h3>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
<strong className="text-gray-900 dark:text-white">What it does:</strong> Helps nodes find each other on the internet without a central directory.
|
||||
</p>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-6">
|
||||
<strong className="text-gray-900 dark:text-white">Simple analogy:</strong> Like a distributed phone book where everyone helps maintain the listings.
|
||||
When you want to find someone, you ask the network, and it routes you to the right place.
|
||||
</p>
|
||||
|
||||
<h3 className="text-2xl font-semibold text-gray-900 dark:text-white mb-4">Corestore</h3>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
<strong className="text-gray-900 dark:text-white">What it does:</strong> Provides distributed, synchronized storage for the domain claims and votes.
|
||||
</p>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-6">
|
||||
<strong className="text-gray-900 dark:text-white">Simple analogy:</strong> Like a shared Google Doc that everyone has a copy of and automatically syncs.
|
||||
When someone makes a change, everyone's copy updates automatically.
|
||||
</p>
|
||||
|
||||
<h3 className="text-2xl font-semibold text-gray-900 dark:text-white mb-4">Autopass</h3>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
<strong className="text-gray-900 dark:text-white">What it does:</strong> Manages the secure, append-only ledger of claims and votes.
|
||||
</p>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-6">
|
||||
<strong className="text-gray-900 dark:text-white">Simple analogy:</strong> Like a blockchain ledger, but simpler. It keeps a permanent record
|
||||
of who claimed what and who voted for whom, and this record can't be tampered with.
|
||||
</p>
|
||||
|
||||
<h3 className="text-2xl font-semibold text-gray-900 dark:text-white mb-4">Holesail</h3>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
<strong className="text-gray-900 dark:text-white">What it does:</strong> Establishes direct connections through firewalls and NAT using UDP hole-punching.
|
||||
</p>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-6">
|
||||
<strong className="text-gray-900 dark:text-white">Simple analogy:</strong> Like two people behind locked doors coordinating to open their doors
|
||||
at the same time so they can pass messages through. The "hole" is the temporary opening in the firewall that allows
|
||||
direct communication.
|
||||
</p>
|
||||
|
||||
<h2 className="text-3xl font-bold text-gray-900 dark:text-white mb-6 mt-12">Real-World Example</h2>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
Let's walk through a concrete example to see how everything fits together:
|
||||
</p>
|
||||
|
||||
<h3 className="text-2xl font-semibold text-gray-900 dark:text-white mb-4">Scenario: Alice hosts a blog, Bob wants to read it</h3>
|
||||
|
||||
<div className="bg-gray-50 dark:bg-gray-800 p-6 rounded-lg mb-6">
|
||||
<h4 className="text-xl font-semibold text-gray-900 dark:text-white mb-3">Step 1: Alice Sets Up Her Blog (Service Provider)</h4>
|
||||
<ul className="list-disc pl-6 space-y-2 text-gray-700 dark:text-gray-300 mb-4">
|
||||
<li>Alice runs a blog server on her home computer (port 80)</li>
|
||||
<li>She generates a Holesail hash: <code className="bg-gray-200 dark:bg-gray-700 px-1.5 py-0.5 rounded">hs://s00084bf87dfa89a3048fb081c0e6207eb5a</code></li>
|
||||
<li>She claims the domain <code className="bg-gray-200 dark:bg-gray-700 px-1.5 py-0.5 rounded">alice.blog</code> with this hash</li>
|
||||
<li>The claim is stored in the P2P network and synced to all peers</li>
|
||||
</ul>
|
||||
|
||||
<h4 className="text-xl font-semibold text-gray-900 dark:text-white mb-3 mt-6">Step 2: Bob's Node Joins the Network</h4>
|
||||
<ul className="list-disc pl-6 space-y-2 text-gray-700 dark:text-gray-300 mb-4">
|
||||
<li>Bob starts his P2NS node</li>
|
||||
<li>His node connects to Hyperswarm and discovers other peers</li>
|
||||
<li>The distributed ledger syncs, and Bob's node now knows about <code className="bg-gray-200 dark:bg-gray-700 px-1.5 py-0.5 rounded">alice.blog</code></li>
|
||||
</ul>
|
||||
|
||||
<h4 className="text-xl font-semibold text-gray-900 dark:text-white mb-3 mt-6">Step 3: Bob Accesses the Blog</h4>
|
||||
<ul className="list-disc pl-6 space-y-2 text-gray-700 dark:text-gray-300 mb-4">
|
||||
<li>Bob types <code className="bg-gray-200 dark:bg-gray-700 px-1.5 py-0.5 rounded">https://alice.blog</code> in his browser</li>
|
||||
<li>DNS query goes to P2NS DNS server</li>
|
||||
<li>P2NS looks up <code className="bg-gray-200 dark:bg-gray-700 px-1.5 py-0.5 rounded">alice.blog</code> in the ledger</li>
|
||||
<li>Finds Alice's claim and gets the Holesail hash</li>
|
||||
<li>Assigns local IP <code className="bg-gray-200 dark:bg-gray-700 px-1.5 py-0.5 rounded">192.168.3.2</code> to <code className="bg-gray-200 dark:bg-gray-700 px-1.5 py-0.5 rounded">alice.blog</code></li>
|
||||
<li>Creates Holesail client connection using the hash</li>
|
||||
<li>Holesail punches through firewalls and connects to Alice's server</li>
|
||||
<li>HTTPS proxy routes the request through the tunnel</li>
|
||||
<li>Alice's blog server responds with the blog content</li>
|
||||
<li>Response flows back through the tunnel to Bob's browser</li>
|
||||
<li>Bob sees Alice's blog!</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-4">
|
||||
<strong className="text-gray-900 dark:text-white">Timeline:</strong> All of this happens in under a second for the first request.
|
||||
Subsequent requests are even faster because the Holesail connection is reused.
|
||||
</p>
|
||||
<p className="text-gray-600 dark:text-gray-300 mb-6">
|
||||
<strong className="text-gray-900 dark:text-white">The magic:</strong> Even though Alice and Bob are both behind firewalls and NAT,
|
||||
they can communicate directly thanks to Holesail's UDP hole-punching. No central server needed, no port forwarding required!
|
||||
</p>
|
||||
</div>
|
||||
</section>
|
||||
</div>
|
||||
);
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user