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
A controlled share gets its expiry when you create it, at any point within 30 days. The deadline holds whether or not anyone opens the invitation, and you can revoke the share sooner.
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 timer starts when the server grants the first access session, even if transfer or decryption later fails. Every later session shares that deadline, and reopening never resets it.
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.
A timeline: expiry tomorrow, a ten-minute timer
Suppose you create a share at 9:00 on Monday with an expiry of 18:00 on Tuesday and a ten-minute timer after first access. Nothing changes until someone opens the invitation. If nobody does, it stops working at 18:00 on Tuesday.
If your recipient opens it at 14:00 on Monday, the server grants the first access session and starts the timer. Access now ends at 14:10 on Monday, the earlier of the two deadlines. Closing and reopening the shared vault does not reset the clock, and anyone else using the same invitation works within the same ten minutes.
If they open it at 17:55 on Tuesday instead, they get only five minutes, because the fixed expiry still applies. At the deadline the service refuses further reads and queues the encrypted data for deletion, and the Revault viewer closes and releases its share keys and temporary files.
Access counts measure sessions, not unique recipients
You can cap the number of access sessions or leave them unlimited until expiry. The server counts the sessions it grants, not file views or people, and a retry with the same valid session token does not use another one.
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.
Choosing settings for common handoffs
For a one-off document handoff, such as a lease or a signed form, set an expiry of a day or two and allow a few access sessions in case the recipient needs to reopen it. Revoke the invitation once they confirm they have what they need, and allow export only if they should keep their own encrypted copy.
For a few days of photos, such as pictures from a shared trip, set an expiry that covers those days and leave sessions unlimited or generous, so reopening the shared vault does not lock anyone out. Skip the first-access timer: it would end access for everyone shortly after the first person opens the share.
For view-only access, disable export, set a low session limit and add a short timer after first access. These settings limit what the official app offers. They cannot stop a screenshot or a modified client.
Understand what view-only sharing can protect
When export is allowed, recipients can save an encrypted .qvault copy that opens with the share secret, and that copy can stay usable after the invitation expires. When export is disabled, the app’s export controls are absent.
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.
Does deleting my original revoke the share?
No. A share is a separate snapshot, so removing the original file from your vault leaves the share in place. Revoke the invitation itself when you want access to end.
Can a timer recall a file someone has already saved?
No. At the deadline the service stops serving the share and the Revault viewer releases its keys and temporary files. Cleanup cannot erase screenshots, data retained by a modified client or a copy exported earlier.