How share links carry a key without leaking it
Two modes, one base64url blob, and the part of a URL that browsers never send to a server.
Everything after the # stays in the browser.
A share link carries its payload in the URL fragment. Browsers do not transmit the fragment to the server, which makes it the one place in a URL where a key can travel without being logged by every hop in between. The server hosting the link never receives the material needed to read it.
Open links carry a key. Locked links carry a salt.
An open share embeds a freshly generated 32-byte AES-GCM key in the fragment — anyone with the link can read the note. A locked share embeds only a 16-byte salt; the key is derived from a password you give the recipient separately, again with PBKDF2-SHA256 at 250,000 iterations. The link alone is useless without it.
One base64url string, not a query soup.
The fragment is a single encoded blob with a fixed layout: a version byte, a flags byte recording mode and compression, a 12-byte IV, then either the raw key or the salt, followed by ciphertext. Packing it this way keeps links short and leaves no readable parameters to inspect.
Expiry and revocation stay with you.
Shares can carry an expiry and be revoked early from Vault Settings. Critically, a share never exposes your vault key — revoking one has no effect on your vault, and a leaked share link cannot be walked back into it.