Shared recording rich previews + embeddable player

What it is

When you share a screen recording by link, the link now shows a rich preview — a thumbnail, the recording's title, and a short description — when you paste it into Slack, Notion, Gmail, and other apps that unfurl links, instead of a bare URL. The recording can also be embedded as a small inline player on another site (a Notion embed block, a blog, a Twitter/X player card) via a dedicated /embed link.

What you see

• Paste a shared-recording link (https://shares.omniscio.com/s/<id>/run) into Slack / Notion / Gmail → a preview card with the recording's poster image, its title, and a one-line description (pulled from the transcript when there is one).
• Embed https://shares.omniscio.com/s/<id>/embed in an <iframe> on another page → Omniscio's one video player — the same controls, speed menu and keyboard shortcuts as everywhere else — sized to fit the frame.
• Nothing changes for you at share time — the preview and the embed are produced automatically when you share; you still copy the one link as before.

Where to find it

Nothing to open: this is what a shared recording link does once it is posted. The preview and the embed are produced automatically at share time, from the screen recorder's own share control.

How it behaves

The viewer page

Opening the link itself (not just unfurling it) shows a polished, on-brand page — not a bare browser video. It carries the Omniscio look: a "Shared recording" eyebrow with the orb, the recording title, the video in a glassy, aurora-ringed frame played by Omniscio's one video player (play, seek, volume, an always-visible speed menu, captions, download and full screen, with the same keyboard shortcuts as in the app), a share card, the transcript, and one footer line with the link's expiry and a "Made with Omniscio" credit showing the real orb + Satoshi wordmark. The image-snip page uses the same share card and footer; the "still uploading" placeholder keeps a simple Copy link button.

The share card shows the link itself (selectable, so it can always be copied by hand), a large Copy link button that turns green with a check when the copy worked, and a Share button that opens the phone's or computer's own share sheet — shown only on devices that have one. Cancelling the share sheet does nothing; if the browser refuses it, the button copies the link instead. A copy that fails never claims success: the link is selected and the button says to copy it by hand. Copy and Share always hand out the page the visitor was sent: the share page when the share has one (every video published through POST /share/publish, and recordings shared with comments), otherwise the /run page. It stays fully self-contained (no external fonts, scripts, or stylesheets), so it renders identically under the strict share sandbox — on desktop and mobile, in light and dark.

A video published from a file rather than recorded — an agent's MP4, an onboarding tour or a feedback video — opens on the same page, labelled "Shared video" with a "· Video" browser-tab title and a "Video" link-preview line when it has no transcript. Only a real screen recording says "Shared recording". A page keeps the wording and layout it was published with, so a video shared before a change needs republishing to pick up the new label or the share card.

For agents

How it works (under the hood)

• A shared recording is served as a single top-level page at /s/<token>/run. That page's <head> carries OpenGraph + Twitter Card tags (og:title, og:description, og:image, og:type=video.other, and a Twitter player card) so a link-unfurling crawler reads them directly. Builder: screen-recorder-viewer-html.ts.
• When a share also has a share page at the bare /s/<token> (a video published with a share page, or a recording with comments), that page frames /run and carries the same preview tags, pointed at itself (buildRecordingShellHtml's preview option) — it is the link the share card copies, so it must unfurl as richly. Its frame grants fullscreen, clipboard-write and web-share to the framed page, which is opaque-origin under the share sandbox; measured in Chromium, the page's normal clipboard copy is refused inside the frame without that grant.
• The Copy button keeps id="copy-btn" data-url="<…>/run" exactly as before, because the share function's serve-time copy-link repair rewrites a bare /s/<token> found in that attribute to /run. The share-page address rides a separate data-page-url attribute that Copy and Share prefer; a test runs the real repair over the built page to keep the two in step.
• The preview thumbnail is the recording's poster frame, re-encoded to PNG and uploaded to /s/<token>.png when you share (screen-recorder-share-thumbnail.ts). It is best-effort: if the thumbnail can't be made, the link still previews with a title + description (a plain text card), and sharing is never blocked.
• The embed player is served at /s/<token>/embed by the share Cloud Function — the same one video player, streaming the same recording; its script is the only one the page's security policy lets run, pinned by a fingerprint of its own text. Unlike the normal viewer, the embed response sets no X-Frame-Options, which is what lets other sites frame it; that is safe because the embed is a pure media player with no login, cookies, or actions to hijack. Route + headers: serve-share.ts + share-headers.ts.
• The preview, thumbnail, and embed all respect the share's protection: a revoked, expired, or password-protected recording does not preview or embed (the crawler / embedder is refused just like a direct viewer without the password).
• The page is fully self-contained + on-brand: the orb and the "Omniscio" wordmark are inlined as base64 PNGs from share-brand-assets.ts. The wordmark is a RENDERED IMAGE of Satoshi, not the webfont — Satoshi's Fontshare licence forbids self-serving the font on the web and the page loads nothing external (a rasterised logo is permitted; see brand-font-contract.md no-web-self-serve). Regenerate WORDMARK_PNG_BASE64 if the brand font or the aurora gradient changes. The video itself plays in the one video player (see The video player), inlined into the page as a single script, so the page still loads nothing external; the transcript and watch beacon are unchanged.

CLI access

There is no separate control-server route — the rich preview and embed are produced automatically whenever a recording is shared (the normal Share action, or POST /capture/:id/share). The shareable link the user already gets is the one that previews and embeds.

Related

• screen-recorder.md — recording the video this share page plays.
• artifact-sharing.md — the sharing surfaces, and the privacy notice, link expiry and password options the preview sits on top of.