We hold a sealed envelope. You hold the only key.
The moment your content arrives it is encrypted under a key that only your reveal token can regenerate. The token is created once, shown to you once, and destroyed. We store a hash of it — nothing that can open the envelope. Our server handles your text only for the moment it takes to encrypt it; it is never written to disk unencrypted. Without your token, a copy of our database cannot open your deposit.
The public sees your claim, never your content.
Title, author, timestamp, fingerprint, length. That is the entire public record. Your idea stays sealed until the day you choose to open it — and that day is yours alone.
Nothing in this register can be changed quietly. Any edit, by anyone, breaks the chain in public.
Each entry is hashed together with the one before it. Edit one word, insert one entry, move one timestamp, and every hash after it breaks in public. The entire chain is downloadable at /api/chain; recompute it yourself in ten lines of code. /api/audit does it for you on demand. We did not build a registry you have to trust. We built one you can check.
Even our clock answers to someone else.
The head of the chain is anchored every day in the Bitcoin blockchain through OpenTimestamps. Your position in the record is fixed by a timestamp that we cannot move, forge, or revoke.
Similarity reports are sealed into the record the instant they are made.
At deposit, your content is compared against every earlier deposit — sealed ones included — and the result is hashed into your entry. No one can go back and change what the registry saw on the day you filed.
Revealing adds. It never rewrites.
When you open your deposit, a new entry points back to the sealed one. The original stays untouched, so anyone can confirm that what you revealed is byte-for-byte what you sealed on the original date.
What we see, and for how long.
To compute the fingerprint and the similarity sketch, your plaintext passes through server memory once, at deposit, and is gone. Not written unencrypted. Not logged. Not kept. The sketch that remains is a one-way fingerprint; the text cannot be rebuilt from it.
No tracking. No ads. Nothing loaded from other sites.
We hold the name you type and nothing else about you.
For technical readersThe specific methods this version uses, and the limits of what it does.
- Content encryption
- AES-256-GCM. The key comes from HKDF-SHA256 over a random 256-bit reveal token with a random 16-byte salt, and each deposit has its own 12-byte nonce. The server generates the token, returns it once, and stores only its SHA-256 hash, compared in constant time when you reveal.
- Fingerprints and chain
- SHA-256 over your exact text. Each ledger entry hashes canonical JSON that includes the previous entry’s hash.
/api/chainlists entries (up to 1,000 per request, withlimitandoffset),/api/auditrecomputes the chain and checks each sealed blob against its recorded hash,/api/headshows the latest entry, and/api/verifylooks up a hash. A local audit alone cannot rule out a full rewrite of a history that has no external anchor. - Similarity
- Comparison is off unless you opt in at deposit. When it is on, a MinHash sketch of your text is compared with the stored sketches of earlier deposits that also opted in, and the result is included in your ledger entry. Sketches are not encryption and can leak some linguistic information.
- Reveal
- A reveal appends a new ledger entry that records the content hash; the original deposit entry is not edited. Revealing stores your text in readable form so that it can be shown publicly.
- Passwords and sessions
- Argon2id (argon2-cffi defaults). Session tokens are random, stored only as SHA-256 hashes, and expire after seven days. The sign-in cookie is HttpOnly and SameSite=Strict, and Secure in production.
- Request limits
- Per address, per minute: 5 sign-ups, 10 sign-ins, 12 deposits and 5 reveals. Counters are held in memory by each server process. Request bodies are capped at 400 KB.
- Browser protections
- A Content-Security-Policy that allows only this site’s own scripts, styles and connections, plus X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: no-referrer and a one-year HSTS header in production. No analytics, advertising scripts or third-party fonts are used.
- Deployment
- Caddy terminates TLS with automatic certificates and redirects www to the main domain. The application container runs as a non-root user and its port is not published.
- External time stamps
- An outside time-stamp authority has not been switched on in this deployment yet, so records show as pending and no independent time is claimed. When it is on, the application sends only a digest of the ledger head to the authority, using RFC 3161 with SHA-256 and a fresh nonce over HTTPS, and verifies the reply against the CA file the operator configures. Until that has been verified for your deposit, it shows as pending and no independent time is claimed. How to verify it.
- What this version does not do
- The server handles your text in readable form while it creates your deposit, and again if you choose to reveal it. This is server-side encryption, not end-to-end or “zero-knowledge” encryption.
- Your email address, author name, private title and similarity sketches are not encrypted by the application.
- Server backups, disk encryption, staff access and log retention depend on how the service is hosted. The application does not provide them. See the Privacy Policy.
- If you lose your reveal token we cannot recover a lost key, and nobody can open the deposit for you.
- A reveal makes your text permanently public.
- No online system is risk-free. These measures reduce risk; they do not remove it, and we do not promise otherwise.
Questions or a security concern
Contact: admin@inventpriority.com
Please do not send passwords, reveal keys or confidential text by email. For how personal information is handled, see the Privacy Policy, and for the limits of what a record proves, the Terms of Service.