[Feature Request] Delayed / Escrow share links with approval timeout (auto-approve or auto-deny)

[Vadorequest]

What type of request is this?

New feature idea

Clear and concise description of the feature you are proposing

Summary

Add a new sharing mode for a file or folder: an “escrow” (time-delayed) share link that is not immediately accessible. When someone opens the link, they trigger an access request, and:

• the owner can Approve or Deny within a configurable delay window, or
• if the owner does nothing, the system automatically applies a configurable default decision:
  • Auto-approve after delay (dead-man-switch style), or
  • Auto-deny after delay (explicit-consent style)

This enables “make available unless I intervene and refuse” workflows for sensitive content.
There are also other workflows made possible, but this one is the most important, IMHO.

Proposed behavior (suggested UX flow)

New share link type: “Escrow / Delayed access link”

1. Owner creates an escrow link for a file or folder and selects permissions (view/download/edit depending on existing link capabilities).
2. Owner configures:
   • Delay window (examples: 24h, 7 days, 30 days, custom)
   • Default decision at timeout: Auto-approve OR Auto-deny
   • Owner notifications: on request creation (in-app/email)
   • Requester notifications: optional (and/or no notification during setup)
   • Optional restrictions: allowed emails/domains, require login/guest email, require message
3. Requester opens the link:
   • They see a “Pending access” page with countdown and optional “Add message” field.
4. Owner can Approve or Deny any time before timeout.
5. If owner does nothing:
   • Auto-approve mode: access is granted after delay
   • Auto-deny mode: request is denied after delay
6. Owner can revoke the link or change policy at any time (until access is granted, and ideally even after, depending on current share revocation semantics).
7. All actions are audited: request created, approved/denied, auto-decision applied, link revoked, access events.

Two variants

• Request-based timer (recommended): delay starts when someone opens the link / requests access.
• Creation-based timer: link becomes accessible after X time from creation, without a request step.

Use cases

1. Emergency access / “digital legacy”

   • You prepare a link to critical documents (insurance, instructions, business continuity).
   • Trusted people can access it if you’re incapacitated and you do not respond within the waiting period.
     Similar patterns exist in other products:
   • Proton: “either immediately or after a custom wait time… ranging from days to months” and “If you do nothing, the request will automatically be approved after the designated waiting time.”
     Source: https://proton.me/blog/emergency-access
   • Bitwarden: “Wait time dictates how long your trusted emergency contact must wait… if the access is not manually approved.”
     Source: https://bitwarden.com/help/emergency-access/

2. Safer external sharing for sensitive files

   • You send a link to a contractor/lawyer/accountant.
   • They request access, but you keep a review window. If you realize it was a mistake, you deny or revoke.

3. Secure “handoff” for keys or escrow material

   • Store a recovery key, backup codes, or an encrypted archive.
   • Team members can recover it after a delay if you do not intervene (auto-approve mode).

4. Explicit-consent mode (auto-deny)

   • You want requests to expire unless you explicitly approve in time (useful when you might be offline and do not want accidental leaks).

Design suggestions (to gain inspiration)

Settings / configuration (suggestion)

• delayDuration: integer + unit (hours/days/months)
• timeoutDecision: { autoApprove | autoDeny }
• notifyOwnerOnRequest: { true | false }
  • Additionally, the ability to write down a comment sent in the notification to explain what'll happen and why
• notifyRequesterOnDecision: { true | false }
• requesterIdentityMode: { anyoneWithLink | guestEmail | authenticatedUser }
• allowedEmails / allowedDomains (optional)
  • Might be useful when we want to restrict who might receive the content, depends on the auth flow (requesterIdentityMode)
  • Typically, we might want not to restrict who triggers the request for sharing content, but we might want to decide to whom the content will be shared with (specific emails, etc.)
• oneTimeAccess (optional)

Security and abuse considerations

• Rate limit requests per link/IP to reduce spam or brute force discovery.
• Separate “request token” and “access token” so opening the link does not leak access prematurely.
• Ensure revocation works immediately (including post-grant, if consistent with current link behavior).
• Full audit trail visible to the owner (and space manager if relevant to governance).

---

I know I've been using this feature for years with tools that allow it (1Password, etc.) because it's very reassuring to know our loved ones or business partners will get access to exactly what I want if anything was to happen to me.

Validations

• Check the feature is not already implemented in the project.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.
• Check that the feature is technically feasible and aligns with the project's goals.

[johaven]

Hi @Vadorequest, this is a very comprehensive and truly interesting request.
Thank you for sharing this idea.
The request for approval is a relevant suggestion.
I think we should proceed in stages when it comes to implementation.

Have you started working on the PR for your request?