Posting an external URL used to skip the torrent/webseed benefit entirely. Now the
upload modal's external tab auto-derives a WebTorrent webseed from the URL at
publish time: fetch the remote file (CORS-permitting), stream it under a hard size
cap, compute the infoHash, and publish a magnet with the URL as the webseed (ws=).
Best-effort — CORS failure / over the cap / any error silently degrades to
URL-only. Only runs when the user didn't paste their own magnet.
- js/utils/externalUrlTorrent.js: fetchBlobWithCap (streams with a 500 MB cap,
aborts past it, short-circuits on content-length), buildWebseedMagnet, and
deriveExternalUrlTorrent (reuses createTorrentMetadata). Pure + injectable → unit
tested without network/WebTorrent.
- mediaUploader.deriveTorrentForExternalUrl: derives the ws= magnet and, when
storage is unlocked, also hosts the tiny .torrent so the webseed can actually
bootstrap P2P (xs=) — best-effort, falls back to ws=-only.
- UploadModal.handleExternalFlow calls it; deriveExternalWebseed only hosts the
.torrent when storage is unlocked, shows progress on the submit button, and
never throws.
Tests: tests/external-url-torrent.test.mjs (9 — magnet assembly, name parsing,
streamed size-cap enforcement + short-circuit, fetch-failed, derive-with-injected-
hash, failure propagation). Lint + build green.
Next: the same for editing a URL in the Edit modal.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
With both Backblaze B2 and Cloudflare R2 configured, an upload could fail with "S3
endpoint is required." when the upload modal's tracked provider drifted out of sync
with the active credentials (user: storage selector on Backblaze but the modal set for
Cloudflare). A Cloudflare R2 connection stores an accountId and derives its endpoint, so
routing it through the S3 service — which requires an explicit endpoint — threw.
Fix: MediaUploader.uploadVideo/uploadThumbnail now choose the service + provider from the
CREDENTIALS' own provider (credentials.provider || credentials.meta.provider || provider),
so a stale modal provider can no longer send an R2 connection through the S3 path (or
vice-versa). The R2 service derives the endpoint from accountId as before.
Test: tests/media-uploader-provider-routing.test.mjs (4 — R2 creds route to r2Service
even with a stale Backblaze arg; B2 creds route to s3Service; meta.provider + passed-arg
fallbacks). Build + lint clean; upload/storage suites green.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Extract UploadModal's storage+torrent upload core into a reusable
js/ui/components/mediaUploader.js (resolveActiveConnection, uploadThumbnail,
uploadVideo incl. infohash/.torrent/magnet) so the Edit modal can reuse it
without duplicating R2/S3 + torrent logic (and without blowing EditModal's
file-size budget). UploadModal now delegates its thumbnail/video upload core to
MediaUploader, keeping its own progress/state/zombie-guard wrappers — behavior
preserved.
UploadModal: 1319 -> 1191 lines. Build + full lint + unit suite green.
NOTE: the upload flow can't be unit-tested (browser + S3/R2 deps); this is a
behavior-preserving extraction pending manual re-test of a normal upload before
Edit upload is layered on top (steps 2-3).
Co-Authored-By: Claude Opus 4.8 <[email protected]>
