WHAT VEILID IS
Veilid is an open-source peer-to-peer application framework, written in Rust and maintained by the Veilid Foundation. It provides encrypted transport, a place to put data, and a way to reach a peer without either side learning where the other is: the pieces an application would otherwise have to buy as a service or build and secure itself.
NODES, NOT SERVERS
There are no servers in Veilid, in the specific sense that no company operates infrastructure on an application's behalf. Every participant runs the same software core, but not the same duties: a node reachable from the public internet also relays for nodes that are not, and validates their addresses, while a node behind a restricted NAT and any node running in a browser consume those services without offering them. So no operator is paying for the application's capacity, but the participants who are publicly reachable are paying for the ones who are not.
The arrangement leaves no single point of control and no single point of failure: no one operator's decision takes the running network down for everyone. It degrades rather than stops, losing reach and capacity as nodes leave and recovering as they return.
Finding the first peer
A node joining for the first time has to learn about at least one peer from somewhere outside the network, and have some reason to believe what it is told.
As shipped, that outside source is DNS. A node resolves bootstrap-v1.veilid.net and trusts three signing keys held by the Veilid Foundation, so first contact depends on a registrar, a DNS operator, and one organization.
DNS is in that position because it is the one lookup every device already has, which makes it the bridge into Veilid from the internet as it stands.
The protocol does not require DNS. A bootstrap entry can be written as a direct address instead, which skips the lookup of the bootstrap name but not DNS: in current releases the peer at that address may still resolve the bootstrap records through DNS for the new node, which then looks up the host names those records carry unless they are written as IP addresses.
WHERE THE DATA LIVES
Veilid's shared storage is a distributed hash table. A record has a key, the key determines which nodes are responsible for holding it, and any node can ask any other for a record by that key. Nothing is stored centrally, no node holds the whole table, and no index is consulted, because the key itself says where to look.
Each node keeps its part in a database file on disk. A native node uses SQLite, encrypted at rest under a device key, and the shape inside is plain: a record is a key plus numbered subkeys, each subkey holding up to 32 KiB and the whole record up to 1 MiB. A record is therefore closer to a small set of rows than to a file, and anything larger than 1 MiB has to be split across several records by whatever is storing it.
A GetValue asks a node for a subkey; a SetValue pushes one to it. Each node keeps two separate stores, split by where an operation came from rather than by which operation it is: your own application's reads and writes touch the local store, while every query another node sends you touches the remote store:
| Store | What is in it |
|---|---|
| Local | Holds records your node opened or created for its own use. Veilid never answers another node's GetValue from here. |
| Remote | Holds records other nodes pushed to you with SetValue. A writer picks who to offer a copy to as it fans out, and your node accepts one only if it is close to the key: it refuses if it already knows ten or more reliable peers closer to that key than itself. Only this store answers an inbound GetValue, and your node runs the same closeness test before it answers. |
Reading and storing are separate jobs, though one node usually does both: it advertises the DHT capability by default, so it also accepts records other nodes push to it and answers reads for those. Closeness here is arithmetic rather than geography. A record key is a hash and a node identifier is the node's public key, both 256-bit values in one space; the distance between them is their bitwise XOR, and the routing table keeps peers in buckets by that distance. That is the Kademlia model, shared by most distributed hash tables, and so is the lookup: a node queries several peers in parallel and iterates itself rather than trusting one peer to do the work. Veilid adds a quorum on top, several matching answers drawn from a wider set of candidates, along with signed records, schemas, and the two stores. Your node's identifier, not what you have read, determines which records it holds for the network, and a node configured without the DHT capability answers nothing.
WHAT HAPPENS WHEN YOU READ
The steps when an application asks for a record it has never seen:
| Step | What happens |
|---|---|
| 1. Look at home | The node may check its own local store first, and on a hit with no refresh forced, that is the whole operation. An application that needs the current value forces the refresh, so it skips this and goes to the network. |
| 2. Ask the network | On a miss, the node picks the peers it knows that are nearest the record's key and asks them for it. |
| 3. Wait for agreement | By default it wants three answers that agree, drawn from up to ten candidates, rather than trusting the first reply. |
| 4. Verify | Each answer carries a signature over the value. Before the value is trusted, the signature is checked against the writer's key, which the record's descriptor must authorize for that subkey: the owner, or a listed member of a multi-writer record. The reader normally holds that descriptor already, from opening the record; only a reader that does not yet hold one asks a peer to send it. |
| 5. Keep it | The verified value is written into the local store, so the next read of it costs nothing and touches no one. |
Step four is why a dishonest node is not much of a threat on this path. A node that returns the wrong bytes fails the signature check, because only keys the record's descriptor authorizes can produce a valid signature, so the worst it can do is decline to answer, which the other candidates cover.
Reading keeps data alive
The remote store is bounded and evicts on a least recently used basis. How much it holds is configured rather than fixed, and there are two bounds: a record count and a storage budget in bytes. As of Veilid 0.5.7, veilid-server ships 65536 remote records and, where there is disk to spare, about 10 GB, while an application embedding veilid-core with no DHT config gets 128 records, or 64 in a browser. The first cap reached triggers eviction, and since there is no expiry timer and no retention setting, the record dropped is the stalest one present. Serving a read moves that record to the most recently used end, which defers its eviction while the node stays up; a restart rebuilds the order without counting reads. The local store has no bound, so what you read stays until you delete it.
Opening a record does more than read it. A node keeps its own copy of every record it has opened, and when it opens one of those records again, it checks how many nodes still hold each subkey: if fewer hold it than a write aims for, five by default, the node writes its local copy out again in the background. A record that has already fallen off the network can therefore return, restored by someone who opened it earlier rather than by whoever published it. If what is online is newer, the newer data wins and is driven to consensus instead. Veilid calls this rehydration.
Veilid has no built-in role that does this on a schedule. An application can add one: a process that re-reads particular records to keep them resident, and re-opens them to put them back when they have fallen off. It needs no special permission, because keeping data alive requires nothing more than asking for it.
WHAT IT DOES NOT DO
It does not promise to keep your data
Storage is best effort. Records are evicted under pressure, and no node has agreed to hold anything for you. Anything that must survive needs a copy somewhere that has committed to keeping it.
It is not a blockchain
There is no global ledger, no ordering of events across the network, and no consensus on what is true. The agreement in step three is a quorum of nodes returning the same stored bytes, which is a much smaller claim.
It does not make your content secret
Encryption protects data in transit between nodes, and when a record is created Veilid mints a fresh per-record key and encrypts that record's values under it. That encryption key is not the record's address: a record is stored under a hash of the crypto kind, the owner key, and the schema, and the encryption key travels beside that hash in the record key string. An application that keeps the key gets ciphertext at every storing node; one that later addresses the record by the bare hash gets plaintext. Either way it makes nothing secret from whoever ends up holding the key, and deciding who holds it is the application's job rather than the framework's.
VNS, a proposed application built on Veilid, puts the content key inside the signed manifest so that anyone who can resolve the address can read the site. That is the right trade for publishing and the wrong one for anything private. An application that needs confidentiality has to encrypt its own content and hand out the keys itself. The Foundation's own VeilidChat, currently a proof-of-concept demo, shows that pattern.
RELATED PROJECTS
Veilid Foundation
The project itself: source, documentation, and the community that maintains it. Veilid is public and usable today, independently of anything on this site.
Intersect
Intersect, by Evelyn-H, describes itself as “a decentralised platform for sharing notes privately”. A note is stored in the distributed hash table and shared by link, and the link fetches it from there with no application backend in the path.
VNS, a proposed name system
A naming system in which the address is the public key, generated rather than issued, so only the keyholder can publish at that address. It is designed to hold whole sites in the distributed hash table, kept resident by a guardian that re-reads their records on a schedule, and to resolve them with no origin server. Its storage model follows Intersect's.