textbased.video for Premiere editors

In Premiere, before you send

• · Pick a sequence on your timeline. The extension reads the rushes that touch it and generates web-friendly proxies of just those clips. Your full-resolution media stays untouched on your drive.
• · Provide the transcript by exporting it from Premiere's Text panel and pointing the extension at the file. Auto-transcription is not yet built in — we're aiming to add Whisper support in a future build so the extension can generate transcripts itself.
• · Connect a cloud service. Currently the only supported option is Google Drive; Dropbox, OneDrive and SharePoint are on the roadmap.
• · Choose Server Send (default — bundle is uploaded to your Drive, recipient gets an invite email with a link) or Secure Send (no upload, you deliver the bundle to the recipient yourself).
• · Add a recipient's email (Server Send only) and hit Send.

What the recipient does

If the recipient has used any of those well-known text-based editing tools, this will feel familiar. The transcript sits front-and-centre with the video next to it. They strike through the bits they don't want; what's left is the cut. They can rearrange paragraphs, leave a note for you, and click Send back when they're done.

No account to create. The desktop app is free and one click to install.

Back in Premiere

• · The Returns panel in the extension lights up with a new return.
• · You see the recipient's note alongside the edit name and runtime. That note is where the recipient labels the cut for you — "main edit, 6 minutes", "30-second social cut", "interview-only preview, no broll" — so you know what you're looking at before you import. Especially useful when one project produces several different cuts.
• · Click Import. The extension drops the cut into your project as a new sequence.
• · It auto-relinks the proxies back to your full-resolution rushes — no manual relink dialog, no project-panel offline-media triage.
• · Pick up where you would normally: trim, refine, finish.

Where bytes live

Security-conscious editors and their org IT will rightly ask, and the architecture is a deliberate choice rather than marketing copy. The details below are what's shipped today, not roadmap.

Send path — rushes, proxies, transcript, project XML

• · These never touch our servers. Server Send writes the bundle to your Google Drive and shares it with the recipient. Secure Send writes the bundle to a local folder you choose and you deliver it manually.
• · Cloud support today: Google Drive only. Dropbox, OneDrive, SharePoint, and a local-folder backend for IT-locked-down orgs are on the roadmap. Same picker-based architecture across all clouds, different primitives.
• · Server Send shares your project files with anyone-with-link permission, scoped per project. The link is a 33-character random ID with allowFileDiscovery off — unindexable and uncrawlable, but anyone you forward the link to can open the project. Recipients agree, in writing, not to redistribute the link before they can open the desktop app. If your org policy forbids anyone-with-link sharing, use Secure Send.

Return path — the recipient's edit XML and their note

• · The return XML and the recipient's note are end-to-end encrypted on the recipient's machine before they leave it. The encryption envelope is P-256 ECDH → HKDF-SHA-256 → AES-256-GCM (we call it loopit-e2ee-v2; per-message random IV, per-project HKDF salt and AAD). Open-source review welcomed once we publish the spec.
• · The encrypted ciphertext is uploaded to our infrastructure (Supabase) and held there until your extension polls, downloads it, and decrypts it locally on import. We never see the plaintext. The recipient's public/private keypair is generated on their device; we only ever receive the public key.
• · Recipient access is revocable. Revoking a project at the dashboard breaks the link immediately; the desktop app refuses to open the project on next attempt and existing returns can no longer be claimed.

What we hold on our servers

• · The project code (8 characters) and a pointer to the Drive file the recipient should fetch.
• · The recipient's email address (Server Send only — used to send the invite).
• · The encrypted ciphertext blobs for returned XMLs and recipient notes, until you import them.
• · Per-licence activation records and a per-machine ID hash for seat enforcement.
• · A small cleartext metadata record per return — project code, the recipient-chosen edit name, cut count, sequence runtime in seconds, and timestamps — so your extension can show pending returns and let you pick the right one to import without decrypting first.
• · No cleartext media, no cleartext transcripts, no cleartext edit XML, no cleartext notes — ever.

If even the cleartext metadata above is more than your project allows, use Secure Send for the send path and the desktop app's Export XML button (next to Job finished) for the return path — together they bypass our infrastructure entirely; we see nothing about that project.

The product is in private alpha. The architecture above is what's shipped today, not a roadmap promise. If something on this page is wrong, please tell us — accurate copy is a hard requirement of how we want to build this product.