Core concepts

Share links & visibility

The layered access model: public, unlisted, and private visibility, none / server / end-to-end encryption, and revocable share links with passwords and download caps.

Visibility

Every file carries a visibility that decides who can reach it. Access is enforced on every download request.

VisibilityWho can access
publicAnyone with the link; surfaced on the file's public view page.
unlistedAnyone with the unguessable link, but never listed or indexed.
privateThe owner's session only — or a valid share link/password.

Note

Anonymous uploads may be public or unlisted only. private requires a connected wallet so there is an owner to gate against.

Encryption modes

Visibility controls who is allowed; encryption controls what the server can read. The two compose.

  • none — stored as-is. The R2 bucket is private and served only through presigned URLs, but the operator could read the bytes. Suitable for public/unlisted files.
  • server — AES-256-GCM encryption at rest with a server-held key. The default for private files; transparent on download for the owner.
  • e2e — end-to-end. The browser encrypts with a key derived from a wallet signature before upload. The server stores only ciphertext plus opaque e2eMeta and cannot decrypt.

Warning

With e2e, losing the wallet that derived the key means the file is unrecoverable — by design. Nobody, including udrive, can restore it.

Beyond the canonical /f/<shortId> page, owners can mint scoped share links for a file. Each link is an unguessable token you can constrain and revoke independently.

  • Password — require a passphrase to download.
  • Expiry — auto-disable after a timestamp.
  • Download cap — stop serving after maxDownloads hits.
  • Revoke — kill the link at any time.
create a share linkShell
curl -X POST https://udrive.one/api/files/$FILE_ID/share \
  -H 'content-type: application/json' \
  -b "$SESSION_COOKIE" \
  -d '{ "password": "open-sesame", "maxDownloads": 25 }'

Revoke it with DELETE /api/files/:id/share/:token.

How downloads are served

The download endpoint runs an access check, increments the download counter, logs an anonymized event, and then 302-redirects to a fresh presigned GET (valid for ≤ 300 seconds). Presigned URLs are never cached or reused.

  • Downloads carry Content-Disposition: attachment and nosniff — user HTML/SVG is never served inline from the app origin.
  • Inline preview (on the file view page) is limited to safe types: images, video, audio, PDF, and text.

Tip

The stable, shareable URL is always /api/f/<shortId>/download. It mints a new presigned link on each hit, so you can paste it anywhere without leaking a long-lived storage URL.