vns explainer

WHAT VNS IS

VNS (pronounced “vee-enn-ess” or “Venus”) is a proposed naming system built on one idea: the address is the key. A VNS address is a bech32m encoding of an ed25519 public key: the characters vns1 followed by fifty-nine more lowercase characters, carrying a checksum that catches typing mistakes. There is nothing behind it to look up, and no authority that issues it.

VNS joins two existing ideas. Self-certifying names are old, and Intersect, by Evelyn-H, showed that a Veilid record can hold content a reader retrieves directly, with no application backend. VNS adds a DNS- and HTTP-shaped publishing and resolution surface over that storage.

Because the address is the public key, only the holder of the matching secret can publish a valid record at that address. Squatting and forgery at an address are impossible by construction rather than by policy: there is no registry to race for a name, and the guarantee rests on ed25519 rather than on anyone's good behavior. Impersonating a party is a different question, and one no key format can settle. An attacker cannot write at your address, but can still grind a look-alike one or present your label beside their own key.

WHAT AN ADDRESS LOOKS LIKE

An address is sixty-three lowercase characters and nothing else. It is derived from a key rather than chosen, so there is nothing to buy and nothing to renew. The example below is real and correctly formed; nothing is published at it, and nothing ever will be.

Every address opens with vns1: vns names the format and 1 is the separator the encoding requires. Everything after that is key material from the first character, which is why a memorable prefix can be ground at position one. A version marker sits at the end of the key material, just before the checksum, where a future key type can be signaled while keeping the vns1 prefix. Tor v3 onion addresses likewise put the key first and the version at the end. Grinding is open to anyone, though, so a familiar-looking prefix proves nothing about who holds the key: read a prefix as decoration and compare the whole address before trusting one.

The last six characters are a checksum. It catches the transcription mistakes people make, a wrong character or two swapped ones, and refuses the address rather than resolving something else. It is not a signature and carries no information about ownership.

In a link

Where a scheme is required, a display label may sit before an @. Everything before the @ is decoration and everything after it is the address:

Read the label as a convenience and never as a claim. Any number of sites can present the same label, and only one of them holds the key the address encodes. A resolver derives trust from the part after the @, which is why that is the part worth comparing.

HOW A NAME RESOLVES

Resolution is one hop and consults no authority. A resolver decodes the address offline to recover the public key, derives a record key from it, reads a signed manifest from the Veilid distributed hash table, and verifies that manifest against the key it already holds. The manifest names the operational key and the record holding the content. The resolver confirms that record is owned by the named operational key, then reads the index it holds and checks every file against the digests in that index.

The address stays fixed while everything it points at can move. A publisher rotates a short-lived operational key on a regular cycle, minting fresh content records and issuing a new signed manifest, without the address ever changing. The long-lived identity key that the address encodes is needed only at rotation and stays offline in between.

WHAT IT REMOVES

The classic web needs each of these for a name to work; VNS has none of them.

For a reader running their own resolver, these removals hold for resolution itself. Joining the network in the first place still involves DNS as shipped, which the Veilid Explainer covers under Finding the first peer. A reader who uses a shared public gateway instead reaches the gateway by its DNS name over TLS, so for that last hop DNS and a certificate authority are back in the path, and the gateway sees which address and page each client reads.

The design moves concentration of risk rather than removing it: everything depends on one identity secret. If it leaks, the address is lost in a way no registrar can undo, because there is no registrar to appeal to.

WHAT IT DOES NOT DO

Availability is not guaranteed

Veilid storing nodes drop whole records, least recently touched first, once the bytes they hold exceed the storage budget they are configured with, or once they hit a record count cap. There is no expiry clock and no retention promise, so a site survives because readers fetch it or because someone runs a guardian, a process that re-reads the records on a cycle to keep them resident. A site nobody reads and nobody guards is evicted, and nothing in the protocol prevents that.

Content is not confidential

The content record is encrypted where it is stored, but the key that decrypts it travels inside the signed manifest. Anyone who can resolve the address can read the content, and so can the nodes storing the anchor; the encryption hides it only from a node holding content bytes without the manifest. VNS protects authorship, not secrecy.

What removal can and cannot reach

There is not yet a way to destroy a vns1 site: the specification lists the missing destruction path as a known defect. An owner can overwrite their own records. Separately, a publishing or serving node can refuse to write or relay media matching an operator-supplied list of known-bad perceptual hashes; that filter is on by default. It is hygiene rather than an unbreakable gate, and a node that has already cached a record is not obliged to forget it.

An identity can also be retired. A recovery event, co-signed by a quorum of recovery contacts named in advance, names either a successor address or a terminal retirement, and a resolver that sees one stops following the old address. That part is specified and not yet implemented.

None of this reaches copies already made. A key that no authority can override is also one that no authority can revoke: no registrar or host holds the site, so there is no single party that can remove it, and a guardian operator can only stop refreshing it.

A memorable word is not a secure introduction

Human-readable names sit above the key as a display layer and carry no authority of their own. They are safe for recognizing a key you already hold, and unsafe for discovering one you have never seen. First contact should carry the key itself: a vns1 string, a label@vns1 link, or a QR code.

A resolver keeps a local file pairing labels you chose with addresses you already hold, and nothing an attacker sends can write into it, so recognition is safe. A label arriving in a link is a suggestion for what to call the address beside it, never an entry in that file, and no directory of approved labels ships with a resolver.

RELEASE 2027-01-01

The first public release contains the specification and the reference implementation. VNS runs on Veilid, which is available now.