Trust

What each reader can actually read

loot is a from-scratch encryption system that nobody outside this project has audited. This page is the whole answer to who can read your work — including the parts that are less comfortable than the pitch.

Start here: your own machine

loot seals your content against hosts and collaborators. It does not seal it against the machine it sits on.

The objects in .loot/objects/ are ciphertext. But your content keys sit beside them in .loot/keyring, and your identity key is .loot/id. Unless you have set a passphrase, both are readable by anything that can read the directory. The unit of exposure is the whole .loot/ folder: copy it and you hold every tier, including the paths you sealed to yourself alone.

This is not hypothetical. A repo inside Dropbox, iCloud, OneDrive, or a backup tool has already handed that provider every tier — silently, without you typing a verb. Run loot unlock/loot lock and set a passphrase at loot init if the repo holds anything you would mind losing that way. On Windows there is no reboot-cleared session store, so an unlock lasts until you loot lock it.

This is the same boundary git gives you — your working tree is plaintext there too. We state it because the rest of this page is about remote readers, and it would be dishonest to let that imply the local one is solved.

The matrix

Five readers, four tiers. Every cell below is a property of the code, not a policy we promise to honour.

Tier	Your `.loot/`	Relay operator — or a collaborator with no grant	Forge operator	Anonymous visitor	The git mirror
Internal the default	Reads	Reads — the key rides in every sync bundle	No — holds ciphertext	No	Reads — projected as plaintext
Published	Reads	Reads	Reads — the one tier it can	Reads — that is what published means	Reads
Restricted	Reads	No — the key never travels	No	No	Absent — by omission, not by keys
Embargoed before reveal	Reads, if you sealed it	No — but see who enforces that	No	No	Absent
Embargoed after reveal	Reads	Relay: never. A relay is not a grant recipient, so it never receives an embargoed key at all. Collaborator: reads, from reveal time.	No	No	Absent

Regardless of tier

Everything below is never encrypted, at any tier. loot seals content; it does not seal the shape of your history. If a filename is itself the secret — acquisition-notes/theranos.md — sealing the bytes does not hide it.

Path names	Readable by a relay, a forge, and any collaborator. Restricted and embargoed paths are absent from the git mirror entirely, so their names do not reach it. Anonymous visitors see them only if the repo is explicitly marked metadata-public (off by default).
Change messages Author pubkeys DAG shape	Same as above. A change describes itself as a whole and its ancestry spans every path, so this cannot be scoped per-path — it is one repo-level switch, and it defaults to private.

Two cells where the plain answer misleads

1. Restricted, against the git mirror, is not protected by keys. It is protected by the git bridge omitting the path from every commit. The bytes are correctly sealed either way — but that means a defect in the projection is its own escape class, in which a correctly-sealed object still reaches git as plaintext. It has happened here before. If you use the git bridge, do not treat Restricted as cryptographically enforced against that mirror.

2. An embargo's reveal time is enforced by the relay's clock, not by mathematics. The key travels as a timed, sealed grant sitting in the relay's mailbox, and the relay decides — against its own clock — when to hand it over. A hostile or simply wrong-clocked relay can release it early, and no client-side check can detect that. What is cryptographic is the other direction: the reveal time rides inside a grantor-signed envelope, so a relay cannot move a reveal later, forge one, or read the key itself. When we demonstrate that no advanced clock or patched binary beats an embargo, that is a claim about the client. It has never been a claim about the relay.

What the site itself records

Everything above is about content you store here. Visiting this website is a separate question: the web server keeps logs for 30 days, a summary is counted from them, and your browser sends one short message per page so visits can be counted as people rather than requests.

Privacy says exactly what those records contain, what they deliberately do not, and how to object.

Hosting here is invite-only

You can sign in today and still not push.

This forge refuses a key that is not on its allowlist, by construction. That list is not a waiting queue — a host that cannot read what it stores can only choose whose code it holds. Reading stays open to anyone. Running your own needs nobody else's permission: install loot and serve your own relay.

What we do not guarantee

loot's cryptography is written from scratch and has never been independently reviewed.

The primitives are standard and well-regarded — ed25519 for signatures, X25519 for key agreement, ChaCha20-Poly1305 for content and key wrapping. The composition of them is ours. How keys are derived, when they travel, how grants are framed and authenticated, how the tiers map onto them: that is this project's design, it has had no external cryptographic review, no formal analysis, and no audit. We are not planning one before the alpha; it is a question for a later stage.

There is no warranty. loot is offered under the MIT and Apache-2.0 licences and those disclaimers are the operative ones. If you are deciding whether to trust loot with something whose disclosure would genuinely hurt you, the honest answer today is keep a copy somewhere you already trust, and treat loot as the experiment it is.

Reporting a vulnerability

Email security@millerbyte.com.

Please do not open it in the public Discord, and please do not post a working exploit before we have talked. That mailbox is not end-to-end encrypted; if you would rather encrypt your report, mail an empty message asking for a key and you will get one.

What to expect, honestly. loot is maintained by one person. There is no security team, no rotation, and no paging. Expect an acknowledgement in days, not hours. If something is being actively exploited, say so in the subject line and it will be read sooner. There is no bug bounty — if you find something real, you will be credited in the release notes unless you ask not to be.

If it leaves your machine, it's experimental

The local loot CLI is what this alpha is about. Nothing leaves your machine unless you ask: every destination loot contacts is one you configured. What you put on a relay or a forge is a demonstration, not a service — and that is where the matrix above stops being theoretical. Your repository will open in every later version of loot; that is the one guarantee. The rest can change.

Known issues Why loot Read the docs