An expiring link and a self-destruction timer answer different questions: when should an invitation stop working, and how long should access remain after someone first opens it? Understanding that difference helps you choose useful limits without expecting a timer to recall a file someone has already saved.
Expiry closes an invitation at a fixed deadline
Choose an expiry within 30 days when creating a controlled share. The service stops granting access after that deadline whether anyone has opened it or not. You can also revoke the share earlier. These controls apply to the shared snapshot, not the files in your personal vault.
Imagine sending a document today that is needed until tomorrow evening. A fixed expiry gives that invitation an endpoint even if nobody uses it. Keep your original in your own vault; an expiring share is a temporary handoff, not a backup. If plans change, revoke the invitation instead of assuming that deleting the source document will cancel access.
Self-destruction starts at the first granted session
The optional self-destruction timer starts when the server first grants an access session, before successful decryption is confirmed. All recipients share the same deadline. Reopening does not reset it, and the earlier of this deadline and the original expiry ends access.
For example, a share might expire tomorrow but permit only ten minutes after its first access session. A recipient who starts now begins the same ten-minute window for everyone. A recipient who arrives just before tomorrow’s fixed expiry gets only the remaining time. A wrong decryption secret does not undo a session already granted by the service, so deliver the correct secret before the recipient opens the invitation.
Access counts measure sessions, not unique recipients
Set a maximum number of access sessions or leave sessions unlimited until expiry. The server counts granted sessions, rather than individual file views or identified recipients. Retrying with the same valid session token does not consume another access. A session lasts at most 15 minutes and never beyond the share’s deadline.
A one-session limit does not establish the identity of one person. An invitation is a capability, and anyone holding the link and secret may use it. A new session can consume another permitted access, even for the same recipient. Pick a limit that leaves room for the intended handoff, and use a separate invitation when different recipients need independent deadlines or counters.
Understand what view-only sharing can protect
Allow recipients to save an encrypted .qvault copy, or disable the app’s export actions for a temporary viewing flow. Exported copies open with the share secret and can remain usable after the invitation expires. Disabling export does not prevent screen capture or a modified client from retaining data.
Expiry and revocation stop future retrieval through Revault. They cannot erase screenshots, exported files, or copies retained by a recipient. Choose someone you trust, even when export is disabled.
These timed controls belong to Revault’s server sharing route. The alternative private CloudKit invitation between iOS users has no server-enforced access counter or automatic expiry. Choose a controlled share when those restrictions matter. Encryption protects file contents in transit and storage, while access policies govern what the service and official app allow during a sharing session.