Privacy

mutis runs on the Tari™ Ootle testnet. What we collect, what we can't, every table in our database, and how long each thing lasts.

The short version

We collect ciphertext, padded sizes, hours, rules, open counts, your locker's random id and a hash of its login key (if you use one), and invoices for space you rent. The full list is below.
We don't collect names, emails, phone numbers, file names, file contents, keys, passwords, analytics or tracking cookies.
Your IP: our server sees your IP address while you're connected. We don't write it to disk: rate limits use a keyed hash, kept in memory, with a key that changes every day. Our web server keeps no access logs.
Third parties: our host, Hostinger, which can see what our server stores; Let's Encrypt, for our certificate; Tari's indexer, only when you press “Check it on Tari's indexer”. No analytics, no trackers, no third-party scripts or fonts.

Your IP address

We need your IP address to answer you, and we see it while you're connected. We don't write it to disk. To rate-limit, we keep a keyed hash of your network prefix in memory, with a key that is regenerated every day at 00:00 UTC and never stored. Our web server writes no access log, and its error log drops addresses, paths and headers. A VPN or Tor hides your IP from us.

Every table in our database

This is the complete list, from our schema. Each link also has a “What we know” page that prints its own rows.

Table	What it holds	How long
`items`	One row per stored file: a random id; the locker that owns it, if any; a hash of the uploader's manage token; whether it's a link or kept; its lane; its state; the clear 32-byte header (format, chunk count, a random salt); the encrypted name, type and size; for kept files, the file key locked to your locker; chunk count and padded size; the ciphertext's hash; the hour it arrived; when it expires and when it left; today's download volume.	The ciphertext is deleted within a minute of the exit. The row stays as a note, so we can tell a visitor why a link is gone.
`chunks`	The SHA-256 of each encrypted chunk.	With its file.
`uploads`	An upload in progress: its id, its file, its lane, the space reserved for it.	Until it finishes or expires (two hours).
`shares`	One row per link: its mode (link, link + password, password only); the file key wrapped by the link's secret; the SHA-256 of its access token and, for link + password, of its link proof; the password's stretching parameters (never the password); opens allowed and used; expiry; state; the hour it was made and when it ended; wrong-password counters; opens in the current hour; the minute of its first open, shown only to its owner.	The wrapped key and the hashes are erased at the exit; the rest stays as the note above.
`tickets`	A download in progress: the SHA-256 of its token, the link and file, a byte cap.	Until the download ends.
`identities`	One row per locker: a random-looking id; the SHA-256 of its login key; the first and last day it was active and on how many days; bytes used, reserved and rented; when rented space ends; today's send count.	Until you delete your locker.
`sessions`	The SHA-256 of a sign-in token, its locker, when it was made and expires, the last day it was used.	Until it expires.
`drops`	One row per drop link: its id; its Tari address and tag (public by design); its label; a hash of its manage token; its state; the day it opened and closed; today's file and byte counts.	While it's open, then after you close it or it's removed.
`jobs`	Deliveries and payments waiting to go out on the Ootle. While a relay send waits, it holds the destination address and the sealed 125-byte blob.	The address and blob are erased once it's sent; the job is deleted a day after it ends. Our own test jobs are kept as evidence.
`invoices`	For rented space: the pack, its price, our receiving address with the invoice's reference inside it, status, amount received, times, and the locker it's for.	For our books.
`payments`	Each chain output that paid an invoice: its id, the invoice, its value, when we saw it, and the results of our checks.	For our books.
`chain_utxos`	A copy of the public TARI outputs on the Ootle, so your browser can look for its own deliveries without telling us which.	Public data; kept while useful.
`abuse_reports`	A report: the reported link's id, the category, your details, a contact if you gave one, and the link's key only if you chose to include it.	Kept with what we did about it, as our record of what we removed and why.
`budgets`	Daily totals per kind of action (sends, demo payments). Nothing per person.	Daily.
`used_nonces`	The SHA-256 of each spent anti-bot challenge, so it can't be reused.	Five minutes.
`seal_leaves`, `seal_checkpoints`	SealLog: hashes of stored files and exits, and the checkpoints written to the Ootle.	Permanent, like the chain.
`judge_passes`	The SHA-256 of each one-time pass we gave the Council, and its uses left.	For the contest. They hold nothing about a person.
`meta`	Server settings and counters, such as when the last file was locked and which file is our hourly test.	Overwritten as they change.

What we publish

Our live numbers (/api/v1/stats) are public: the free quota; our disk's size and free space, rounded; whether uploads or the Tari features are paused; how many lockers were active recently, once there are enough of them; SealLog's latest checkpoint; and how many minutes ago the latest file finished uploading, to the minute.

The wall of lockers on our home page shows, for up to 24 recent files at least an hour old, a coarse size and an exit rule, only when at least 8 exist in the last week: never a name, an id or whether a file was opened. Someone who knows a file's size and rule may still recognise it there. Our hourly test file and our own test transactions are public too; never a visitor's.

How long things last

We delete the ciphertext from our disk within a minute of its exit. If the exit was a download, we wait for it to finish. We never had the key, so any leftover bytes are noise.

Our database (never files) is backed up daily. It holds the rows listed above, including the wrapped key of every link still open when the copy was made; a wrapped key opens nothing without the link's secret. What we erase from the database is overwritten, but an older copy of it can sit in the database's write-ahead log until that space is reused, and in the backups until they're deleted.

Our host (Hostinger) can take weekly snapshots of the whole server. We haven't switched them off, and we haven't yet confirmed in its panel how long it keeps them. A file that existed when one was taken stays in it, as ciphertext, until that snapshot is rotated out.

Disks can't be securely wiped, so deleted ciphertext can linger in free blocks. Without the key it's noise.

Deleting everything

Delete a link at any time from the card you got when you made it, or from your locker. Delete my locker, in your locker, removes its record, its files and every link to them; it asks for your key first.

Your browser

We set no cookies. Your locker key lives in your browser's own storage (IndexedDB), and small preferences, like Lights off, in localStorage. Nothing in them is sent to us except what each action needs.

Your browser history, and any history sync, can keep the full link, key included. We clear the key from the address bar once it's opened, but we can't reach your history.

Third parties

Hostinger rents us the server. It can see everything our server stores, and its snapshots are described above.
Let's Encrypt issues our certificate. It never sees our visitors.
Tari's public indexer, only when you press “Check it on Tari's indexer”. It then sees your IP address. Otherwise your browser talks only to this site.

Contact

Report a link · Report a vulnerability