Making EasyOne Links More Shareable and Reliable

We shipped a set of updates focused on making EasyOne file links easier to share, easier to preview, and more dependable across browsers, Discord, and API clients.

The biggest change is simple: if someone has the file link and the decryption key, they can access the file. Public sharing should behave like public sharing. Previously, some download and preview flows could fail with CDN 403 errors because CDN tokens were treated too much like one-time-use credentials. That caused problems for previews, downloads, Discord embeds, browser range requests, and repeated file access during the same session.

Public Links Now Work More Naturally

EasyOne files are still end-to-end encrypted. The server does not receive or store the decryption key, and file contents remain unreadable without it.

What changed is access behavior around the encrypted file payload:

• CDN download tokens are now reusable during their short validity window.
• Preview, download, and embed requests no longer accidentally invalidate each other.
• Links are no longer effectively limited to the uploader’s own session.
• Anyone with both the CID/link and the decryption key can access the encrypted file.

This makes shared links behave the way users expect while preserving the core encryption model.

Fixes for Preview and Discord Embeds

Preview and embed flows often make more than one request. Video and audio players may use range requests, browsers may retry, and Discord crawlers may fetch metadata or media separately from the user’s own browser.

The previous replay-protection behavior was too strict for that reality. A token could be consumed by one request, then the next request would fail with a CDN 403.

We updated the CDN validation logic so tokens are checked for signature, file ID, and expiration, but are no longer consumed after a single use. This fixes cases where previews or downloads failed after the first request.

Public API and Download Flow Updates

The public download flow was also adjusted so access is not tied to the original uploader. User identity may still be included as metadata when available, but it is no longer used to decide whether a public file link can be loaded.

This is especially important for SDK users and API clients. Public file metadata and download endpoints now better match the intended sharing model: possession of the file identifier and decryption key is what matters.

Other Improvements Included in This Release

This update also brings several broader improvements from the development branch into production:

• Better upload and download rate limiting.
• Public API endpoints for upload, metadata, file listing, and download flows.
• API key management in the dashboard.
• Improved documentation for HTTP, Python, and TypeScript usage.
• Table of contents support for docs and blog pages.
• Improved Turnstile loading states.
• More robust upload and preview handling.
• Additional validation and security utilities.

Together, these changes make EasyOne more predictable for normal users and more useful for developers building on top of it.

What Stays the Same

EasyOne’s core privacy model has not changed:

• Files are encrypted before upload.
• The decryption key is not stored by the service.
• File contents cannot be read by the server without the key.
• Removed, expired, or download-limited files still respect their configured restrictions.

This release is about making sharing work correctly without weakening the encryption design.

Closing

This update should make EasyOne links feel much smoother in day-to-day use, especially when sharing files through Discord or previewing media before download.

If you have the link and the key, the file should load. That is the behavior EasyOne is meant to provide.