Documentation
Concepts
Sharing models

Sharing models

In Secrecy, sharing is handing over a key. Because data is only readable with its data key, giving someone access always means making that key available to them — and the only question is what the key is locked with. There are three answers, and they depend on who the other party is and which way the data flows.

Sharewith a user or a groupData keyof the shared dataData key, lockedto their public keyUser or groupopens it with their private keyLinkwith anyoneData keyof the shared dataData key, lockedwith your password, in the linkAnyonewith the link + the passwordthe password travels through a separate channelAnonymousfrom anyoneVisitor's datano account, no clientSealed datato your public keyYouopen it with your private key
ShareLinkAnonymous
The other partyA user or a groupAnyone, no account neededAnyone, no account needed
DirectionOut, from you to themOut, from you to themIn, from them to you
The key is locked withTheir public keyA password you chooseYour public key
They needAn identity in your appThe link and the passwordNothing — only your public key
Ending accessStop sharing, per userLet the link expire, or delete itNot applicable: you hold the data

Share

A share gives an identity access to a file or a folder: a user of your application, or a group. The SDK takes the data key and locks it again with the recipient's public key, so the recipient opens it with their own private key, from their own client. Sharing with a group locks the key once, for the group, and every member can open it. You address the recipient by their public key, not by their user id: resolve one into the other with secrecyClient.app.userPublicKey, which returns the user's key in your application.

A share also carries rights: what the recipient can do with the node (read, write, delete), and whether they can in turn share it with others or remove access. Access can be taken back at any time.

Mail works the same way: a mail is encrypted with the public key of each recipient. A recipient who has not signed in to your application yet has no identity there, and so no public key to encrypt to, which is why their mail is put on hold until they do.

See sharing files and folders and stop sharing.

Link

A link sends data to someone who has no Secrecy account, and whose public key you therefore cannot use. The data key is locked with a password you choose instead, and the locked key travels with the link.

The link on its own opens nothing: the recipient also needs the password, which you hand over through a separate channel. Secrecy never transmits the password for you. The recipient downloads and decrypts the data in their browser, with a standalone function that needs no client.

A link is revocable: give it an expiry date, or delete it to cut access immediately. Deleting the link leaves the data in place.

See transfer.

Anonymous

Anonymous encryption is the mirror image of a link: data flows in, from someone without an account, to you. You publish your public key — the one of your identity in your application; the visitor encrypts to it in their own browser, with a standalone function, and only your client can decrypt the result.

The visitor encrypts with a throw-away key pair that is discarded right away, so the ciphertext carries no sender identity — and the visitor cannot decrypt what they sent. The encrypted data is plain bytes that you store, in your own database for instance.

See anonymous encryption.

Zero-knowledgeAuth