Once a Cap's link is out there — in a README, an onboarding email, a pinned Slack message — it's tied to that exact recording. Re-recording means a new ID and chasing down every place the old link was pasted, so evergreen demos tend to go stale.
I noticed apps/web/app/admin/replace-video already swaps a video's file while keeping its ID, just gated on viewer.isAdmin. Would you be open to exposing that to a Cap's owner — in the dashboard, and ideally via the API so it can be scripted? Right now createUpload always mints a new ID and updateCap only takes title/public.
The interesting part isn't the plumbing, it's what should happen to everything hanging off the old recording: transcript and summary, timestamped comments, view counts. Curious how you'd want those to behave — happy to implement once that's settled.
(Custom slugs like /demo would be the fuller version, but that's a bigger conversation about namespacing — separate issue if there's interest.)
Once a Cap's link is out there — in a README, an onboarding email, a pinned Slack message — it's tied to that exact recording. Re-recording means a new ID and chasing down every place the old link was pasted, so evergreen demos tend to go stale.
I noticed
apps/web/app/admin/replace-videoalready swaps a video's file while keeping its ID, just gated onviewer.isAdmin. Would you be open to exposing that to a Cap's owner — in the dashboard, and ideally via the API so it can be scripted? Right nowcreateUploadalways mints a new ID andupdateCaponly takestitle/public.The interesting part isn't the plumbing, it's what should happen to everything hanging off the old recording: transcript and summary, timestamped comments, view counts. Curious how you'd want those to behave — happy to implement once that's settled.
(Custom slugs like
/demowould be the fuller version, but that's a bigger conversation about namespacing — separate issue if there's interest.)