TOKIMI TIMESTAMP
Tokimi.
Time, in view.
Keep a record of the exact file version you hand over, so it can be checked later.
Your original stays on your device. Keep a salted hash commitment and a portable log receipt.
Give its version a record.Commitment in the log · Receipt in your hands
Concept illustration, not a registered record
A VERSION YOU CAN RETURN TO
Which version
did you hand over?
Artwork, proposals, design drafts and research attachments can all start with one file. Tokimi helps you keep a version record. You decide how to deliver it.
Keep the current version
Create a commitment locally and receive a log receipt after registration. The registration API receives neither the original file, its digest nor its salt.
Share the file and receipt yourself
When you need to hand it over, share the original and receipt bundle with your chosen recipient. The bundle contains the digest and private salt; share it only within your intended scope.
Check the same file later
Recipients can compare the file and receipt locally, using a key pin they trust independently. Registration time remains an operator claim; it does not establish authorship or creation time.
KEEP A VERSION
Keep a version. Check it later.
Choose the file version to record
The SHA-512 digest and a random 64-byte salt are created locally. The original, digest and salt are never sent to the registration API.
The v2 cryptographic profile and its limits
New registrations use SHA-512 for digests, commitments and log hashes, with ML-DSA-87 post-quantum tree head signatures. This profile excludes drand, which uses classical BLS signatures; no commitment formation lower bound is established. Historical v1 receipts can still have their beacons checked offline. These choices do not make network transport or the whole system fully post-quantum.
Save a recovery file, then register
Registration is invitation-only. Without a token, you can still create local commitments, verify receipts and read the API. Tokens are never saved to storage or recovery files.
Download the recovery file first. It contains your private salt and retry ID. After submitting, download an updated copy with the request handle. If you close the page before the receipt is ready, use the same recovery file to resume.
Have a recovery file? Resume a request
v2 recovery files are read locally. Re-enter the original API token to refresh the status or resend with the same idempotency key. The salt is not regenerated. Historical v1 recovery files are view-only and will not be resubmitted or converted.
Bring a receipt and your own trust reference
v2 uses a sha512: fingerprint; historical v1 uses a sha256: fingerprint. Supply the complete value from a source you can independently check. The embedded key and this site’s directory are not automatically trusted pins.
Verification runs locally in your browser. This button makes no network requests and fetches no keys, beacons or external evidence. Without a pin, log trust stays unavailable. You can also download the standalone offline verifier for your own copy.
Fetch the v2 public key directory · reference only
This explicitly queries the v2 directory online, separately from offline verification. It will not fill in or overwrite your trusted pin.
Not queried.
WHAT THE RECORD MEANS
See the record.
Understand its limits.
The commitment is public. Your original stays with you. The same file with different salts produces different commitments. If you lose the salt, the original file alone cannot reconstruct this binding.
The signed registration time is the operator’s time claim. Log inclusion is available; an independent existence upper bound remains unavailable. The receipt alone cannot establish that the file existed before an independently trusted time, and does not prove creation time.
Compare versions. Keep each conclusion separate. Artwork, proposals, design drafts and research attachments can all be committed. A receipt does not establish content truth, authorship, delivery acknowledgement or legal effect.
API FIRST
Fit it into your workflow.
Send only a 64-byte commitment and the fixed v2 profile. Writes need an invitation token. Read and verification scopes remain explicit.
OpenAPI referencecurl https://tokimi.space/api/timestamps/v1/requests \
-H 'Authorization: Bearer YOUR_INVITE_TOKEN' \
-H 'Idempotency-Key: YOUR_STABLE_UUID' \
-H 'Content-Type: application/json' \
--data '{"profile":"tokimi-timestamp/commit/2","commitment":"YOUR_128_CHAR_LOWERCASE_HEX"}'202 = accepted, pending. 201 = receipt durably stored. Retry with the same commitment and Idempotency-Key. This example contains no private key or administrator session.