UniNet

Solutions · Private networking

Reach a service. It never sees your IP.

Every visit crosses up to three relays, each unlocking one layer. Host a static site hidden, and no record names its machine either.

How a visit works

Step through it, node by node.

Each card shows what that node knows: who sent the packet, what its key unlocks, and where it goes next.

Visitor privacy. A container on a name its host's node owns, reached the ordinary way: the host's IP address is in a record every validator holds, but the visitor is never given it. In 7 steps:

  1. Resolve. The visitor's node looks up hello.unp in two records: the DNS Registry Chain, which says which node owns the name, and that node's signed route record, which every validator holds and which lists its IP address and keys. So the visitor's node knows the host's IP address, but it gives the visitor only the service key and a locked token. The visitor's node, looking up the name sees: Who the visitor is, the name asked for, and the host's ID and IP address. It does not see: The request: the visitor locks it so only the host can read it. Every node that runs the network (a validator) can see which node hosts each name. Hosting a site hidden removes that.
  2. Lock. The visitor locks the request with the host's service key, so only the host can read it. Its node unlocks its own note in the token, which says which node is the host, picks three relays, and wraps the request in three more locked layers, one for each relay. The visitor's node sees: Who the visitor is, the host's ID and IP address, and the three relays it picked. It does not see: The request: it is locked with the host's service key. If someone else's node is used as a web gateway, that node reads the request too. It stays private only on the visitor's own node.
  3. Entry. The entry relay unlocks the outer layer with its onion key. Inside is one instruction: which relay to send the packet to next, named by its ID, not by an IP address. The entry relay knows who sent the packet, but not where it is going. Entry relay sees: The visitor's node (its ID and IP address) and the next relay (its ID and IP address). It does not see: Which site is asked for, which node hosts it, and what the request says.
  4. Middle. The middle relay unlocks the next layer the same way. It sees only the relay before it and the relay after it: neither the visitor nor the host. Middle relay sees: Only the relay before it and the relay after it. It does not see: The visitor, the host, which site is asked for, and what the request says.
  5. Deliver. The exit relay unlocks the last layer, which names the host only by its ID. The exit finds that ID in its own copy of the host's signed record, which gives the host's IP address, and sends the still-locked request there. Exit relay sees: The relay before it, and the host's ID and IP address, taken from the host's own signed record. It does not see: Which site is asked for, what the request says, or whether the host answered.
  6. Target. Only the host can open the request. Its onion key unlocks the token, which says which of its names is asked for; its service key unlocks the request. It hands the request to the container that hello.unp points to: api. Host sees: The exit relay's ID and IP address, which of its names is asked for, and the whole request. It does not see: The visitor's IP address, or the IP address of the visitor's node.
  7. Answer. The host locks the reply with the visitor's one-time key. The reply goes back the same way, each relay adding a locked layer and padding it, so every link carries only a block of fixed size. Every relay on the way back sees: Locked data, padded to a fixed size, and when it passes. It does not see: What the reply says, or which site it comes from.

What the words mean. Node ID: A node's name on UniNet: its public key. It says who the node is, not where it is. IP address: Where a machine is on the internet. Whoever has it can connect to that machine. Onion key: Each relay has its own. It unlocks one layer of a packet, which names only the next stop. Signed record: The host signs its own IP address and keys. The exit sends only to an IP address the host signed. Service key: The host's key, from that record. The request is locked with it, so only the host can read it. One-time key: The visitor makes a new one for each request. The reply is locked with it. Locked token: Two locked notes: which node, for the resolver only; which name, for the host only. Neither holds an IP.

Visitor + host privacy. A site hosted hidden: no record names its host or its IP address. Only the first relay of the host's own route sees that IP, without knowing which site it serves. In 9 steps:

  1. Wait. Before anyone visits, the host keeps a request waiting at its meeting relays, sent through two relays of its own. The first of those relays is the only node that sees the host's IP address, and it cannot tell which site the host runs. The host's entry relay sees: The host's IP address, and that the host runs something. It does not see: Which site the host runs, or which meeting relay it uses.
  2. Hold. The meeting relay unlocks the waiting request with its onion key. It checks a proof that the sender holds the secret of the site's service key, then holds the request open, without learning who sent it. Meeting relay sees: The site's service key, how often the site is visited, and the last relay on each side. It does not see: The host's ID or IP address, the visitor's node, the request, or the reply.
  3. Resolve. The visitor's node looks up hello.unp. Its binding on the chain names a service key and meeting relays, and no node. No route record exists for the name, so there is no IP address to give out. The visitor's node, looking up the name sees: Who the visitor is, the name asked for, and the meeting relays. It does not see: The host's ID or IP address. Every node can read the binding: the name, its service key and its meeting relays. None of it names the host.
  4. Lock. The visitor locks the request with the service key, wraps it for one of the meeting relays, and adds two more locked layers, one for each relay of its own. The visitor's node sees: Who the visitor is, the name asked for, the meeting relay and the two relays it picked. It does not see: The host's ID or IP address. If someone else's node is used as a web gateway, that node reads the request too. It stays private only on the visitor's own node.
  5. Entry. The visitor's entry relay unlocks the outer layer. Inside is only the next relay, named by its ID. It knows the visitor's node, but not which site is asked for. Entry relay sees: The visitor's node (its ID and IP address) and the next relay (its ID and IP address). It does not see: Which site is asked for, and what the request says.
  6. Exit. The visitor's exit relay unlocks the last layer: hand this to meeting relay a3f0…. It finds that relay's IP address in its own list. What it carries is still locked with the service key. The visitor's exit relay sees: The meeting relay it hands to, the size of the packet, and when it passes. It does not see: Which site is asked for, the request, or the reply.
  7. Meet. The meeting relay unlocks the wrapper: inside is a visit for service key 7f3a…, and a host is waiting for it. The relay passes the still-locked visit down that host's relays, never learning where they end. Meeting relay sees: The site's service key, how often the site is visited, and the last relay on each side. It does not see: The host's ID or IP address, the visitor's node, the request, or the reply.
  8. Open. Only the host's service secret unlocks the visit. The host serves the page from the site and locks the reply with the visitor's one-time key. Host sees: The request, which only its service secret unlocks. It does not see: The visitor's IP address, or the visitor's node.
  9. Answer. The reply goes back the same way: through the host's relays to the meeting relay, then through the visitor's relays, padded at every link. Only the visitor's one-time key unlocks it. Every relay on the way back sees: Locked data, padded to a fixed size, and when it passes. It does not see: What the reply says, or which site it comes from.

What the words mean. Node ID: A node's name on UniNet: its public key. It says who the node is, not where it is. IP address: Where a machine is on the internet. Whoever has it can connect to that machine. Onion key: Each relay has its own, on both sides and at the meeting relay. It unlocks one layer of a packet. Service key: Named in the site's binding. Only the host holds its secret, which unlocks each visit. One-time key: The visitor makes a new one for each visit. The reply is locked with it.

Hidden hosting is the owner's choice and covers static sites. The host's first relay knows its IP address, the nodes that store the owner's files can point at it, and someone watching both sides can match them by timing. This is a routing design, not an anonymity system.

Two modes

Protect the visitor, or the visitor and the host.

The same relays carry both. Keeping the host private takes a meeting relay in between.

Visitor privacyVisitor + host privacy
Keeps privateThe visitorThe visitor and the host
What it servesStatic sites, and apps on names their host’s node ownsStatic sites
The host seesThe last relay, never the visitor’s IP addressThe last relay of its own route, never the visitor
Who knows the host’s IP addressThe validators that run the network, from the host’s signed recordOnly the first relay of the host’s own route, which cannot tell which site it serves
RelaysOne to three, chosen by the visitor’s sideOne to three on each side, joined at a meeting relay
Round tripsOneAbout twice as many

What it is for

Services that should not reveal who uses them.

Internal tools

Reach a team’s services by name, over relays. Visitors are given a key and a locked token, never the machine’s IP address.

Agent endpoints

An agent calls a service by its name. The service answers the last relay, and never sees the agent’s IP address.

Sites whose host stays private

Publish a static site that no record ties to the machine serving it. Visits meet the host at a relay.

How to use it

A name, a binding, a tier.

Everything else is the network's job.

Step 1

Register the name

Register hello.unp on the DNS Registry Chain, under your own identity.
Step 2

Bind it

Bind the name to your site on a node. Ask for it hidden, and the node creates the site’s service key and picks up to three meeting relays.
Step 3

Set the tier

Standard, Private or High security: one, two or three relays. A visitor can raise the tier, never lower it below yours.
Step 4

Visit

Through any node’s gateway, or the desktop app, which builds its own route so no node draws it for you.

The details: names and bindings, onion routing and the networking model.

Run the network

Every relay is a node someone runs.

Relays and hosts are operators’ machines. Run one on hardware you already have.