- manifest share_target (POST multipart: title/text/url + audio/video files)
and eight shortcuts (Search, Queue, Saved, Downloads, History, Library,
Notes, Settings). /?view=<page> now actually opens that page — the old
shortcuts pointed at it but nothing read it.
- sw.js receives the share: files are parked in the ytp-share-inbox cache (not
a versioned shell cache, so deploys never evict it) and the app is opened;
links/text go to /?shared=. A server POST /share-target fallback covers the
first visit before a worker is in control (links only).
- The app plays a YouTube link found anywhere in the shared text (watch,
youtu.be, shorts, live, embed, music; keeps t=), otherwise searches the text.
/?shared=<link> also works from an iOS Shortcut (iOS has no share target).
- Shared files upload with progress to PUT /api/uploads/shared and join a
"Shared uploads" playlist; network failures stay in the inbox for the next
open, refusals are dropped with the reason.
- The public route is bounded: audio/video only (ffprobe-validated, error text
without server paths), 500 MB per file, 2 GB and 20 a day per device, 50 GB
for all shared uploads, one at a time per device (all env-tunable). Shared
uploads are unlisted: reachable by id, never in anyone else's search.
uploads gains owner + listed columns (idempotent ALTER).
- UPLOAD_DIR moves to the USB drive; reads fall back to UPLOAD_BACKUP_DIR on the
ytplayer-data volume, and while the drive is offline new uploads land there
- scripts/ops/uploads-backup.sh (homelab cron, 03:30) copies both ways, never
deletes; the server removes a deleted upload from both places
- /api/channel resolves a bare channel name ('Artist - Topic') to its id via a
search, and the client falls back to the channel name for old saved entries
