# TranscriptDrop Privacy and Retention

TranscriptDrop is built around a single request — one URL or file in, one
Markdown transcript out — and keeps that flow anonymous and non-persistent by
default. Console accounts and the saved transcript library are opt-in features;
they only persist data when an authenticated operator explicitly saves a
transcript.

## Public API flows

The anonymous public API flows do not persist transcripts or create accounts by default.

### YouTube URL requests

For `POST /api/transcript`, TranscriptDrop parses the submitted YouTube URL or
video ID into an 11-character video ID, then asks the configured caption provider
for existing captions in the requested language.

The submitted value is carried into the returned response and quoted provenance
metadata. The server does not store a transcript history for this flow and does
not create a user account.

### Uploaded media requests

For `POST /api/transcribe-file`, the upload enters a bounded temporary-storage
path. Uploaded media files are written to server-owned temporary paths under the
configured upload temp root. User filenames are retained only as provenance
metadata; they are not used as storage paths.

Uploaded files are validated for supported extension/content-type pairs and byte
limits before ASR routing. Temporary upload files are deleted in a `finally` block
after synchronous processing, including provider failure paths. The
in-memory job abstraction also cleans temporary uploads when jobs succeed, fail,
or expire.

## Console accounts and saved transcript library

Console accounts are created only by an admin (via the `/console/users` API or
`transcriptdrop admin create`). Logging in creates a session cookie tied to a
server-side session with a 24-hour TTL. Console auth is independent of the
anonymous public API.

Saved transcripts are persisted only when an authenticated operator explicitly
sends a sidecar to `POST /console/transcripts`. The stored record includes:

- Metadata: title, source type/id/URL, language, provider/model, content hash,
  creation/update timestamps, and the ID of the operator who saved it.
- Content: the full Markdown rendering and the JSON `TranscriptDocument` sidecar.
- Tags and notes supplied by the operator.

Saved transcripts can be soft-deleted by the operator (`DELETE
/console/transcripts/{id}`). Soft-deleted records are hidden from the library and
search; their retention is controlled by operator and deployment policy. The
saved sidecar and Markdown are controlled by the operator who saved them.

## ASR providers

No external ASR provider is called unless an ASR provider is configured in the
running application. Provider adapters should read credentials from environment
or secret storage, not source code. Provider responses are normalized into a
`TranscriptDocument` before exports or API responses.

## Logs and audit tables

The database schema also includes `logs` and `audit` tables. These tables are
reserved for future phases and are not written by current application code.
Operators should avoid logging uploaded file contents, full transcript text,
provider secrets, private source URLs, or session tokens in deployment logs.

## What TranscriptDrop does not persist by default

The public API flows do not create accounts and do not persist transcripts. The
JSON sidecar is returned only when requested and is written wherever the client
chooses to save it.

## Current limits

The built-in rate limiter and job store are process-local and non-durable. A
multi-worker production deployment should replace them with shared infrastructure
before exposing paid ASR providers broadly.