#+TITLE: 032/ #100daystooffload Veilid Unveiled
#+author: screwtape (pronounced -lisp)
*Somehow* I had until now missed this file:
==veilid/doc/guide/guide.md== from veilid ==https://gitlab.com/veilid/veilid.git==. This file wholly explains pretty much everything except for cryptography. Peers, envelopes are and do pretty much what I jammed at the start of this week. The guide helps with Safety Routes and Privacy Routes a bit too.

Each instance has its peer entity and its user entity.

The peer entity has a physical address associated with it, but is an asymmetric key pair for the purpose of encrypting and decrypting compiled envelopes. We sometimes make binary XOR comparisons between public keys and call the result the distance metric.

The user on the other hand is basically a signify(1) key pair. The ability to timestamp and sign things using the signify private key is considered being signed in.

I'll just treat ({(user . ({(k . v))})}) stores. Having bootstrapped some peers, when I (the user at this node) want to update my phlog (any entry in my user's KV store), I look up the peers I'm aware of whose peer IDs are closest to my USER ID, using XOR as the distance metric ('the usual strategy').

Then I ask them to set_value my updated (user . ((k . v))) cons. I sign this, and remembering my user id is a signify public key, they know I'm the real deal. They're meant to then store that value if they consider it a nearby peer, or if they don't consider my user to be near enough, return a list of nearer peers they're aware of. Having been set_value'd, they're meant to then also set_value some of their peers, so it's not clear who the original set_value'r was.

get_value uses the same propagation to keep requesting closer and closer peers to the user I'm requesting, until I stumble upon a peer that has a record for that user.

KV stores have a short halflife, so it's expected to keep reissuing them (triggering a re-issue re-issue) to keep them currently in the network.

My address that I would publish for others to find me on veilid is my user basically signify(1) public key (someone would browse to me - basically a gopher itemtype 1 alist - by asking their own peer to get_value my user public key).