Cookieless identity
Kymo identifies a visitor without storing anything on their device and without a persistent ID. It does this with a one-way hash computed server-side, fresh for each request.
The hash
visitor = sha256( HASH_SALT | UTC-date | IP | user-agent | site ).slice(0, 16)Five ingredients, joined and hashed, truncated to the first 16 hex characters:
HASH_SALT— a secret Kymo holds. Without it the hash cannot be reproduced or brute-forced from the other inputs.UTC-date— today's date in UTC,YYYY-MM-DD. This is what makes the hash rotate.IP— the request IP, used here and then discarded. Never stored raw.user-agent— the raw UA, used here and then discarded. Never stored raw.site— your domain, so the same person on two different Kymo sites never collides.
The result is deterministic within a day and a site, and opaque everywhere else. You cannot go from a stored hash back to an IP or a person.
Why it rotates daily
The UTC-date term changes at midnight UTC. That means the same device produces a different hash tomorrow, on purpose. There is no identifier that survives the day, so there is nothing to track a person across sessions, and nothing that could be correlated with another site's data.
The cost of that guarantee is precision. A "unique visitor" in Kymo is a unique visitor per UTC day.
What this means for your numbers
- Someone who visits on three different days counts as three unique visitors, not one.
- Sessions are reconstructed within a day using a 30-minute inactivity gap, not a stored session cookie.
- Counts reset conceptually at midnight UTC, which may not match your local midnight.
This is the same mechanism behind the privacy model: no cookie, no raw IP, no cross-day identity — by construction, not by policy.