> ## Documentation Index
> Fetch the complete documentation index at: https://docs.slideless.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Presentations

> A presentation is an HTML deck — a single file or a folder with sibling assets — with share tokens, version history, and view tracking.

## What it is

A **presentation** is a Slideless record that wraps:

* The deck itself — either a **single self-contained HTML file** or a **folder** with an `index.html` and any sibling assets (images, video, 3D models, CSS, JS, shaders, data files).
* One or more **share tokens** (see [Share tokens](/concepts/share-tokens)), each of which resolves to a specific version or follows the latest.
* An append-only **version history** (see [Versioning](/concepts/versioning)) — every update creates a new immutable version, nothing is overwritten.
* Metadata: title, owner, timestamps, view counters.

Presentations live under the organization that the uploading API key belongs to.

## Folder vs single file

Slideless accepts two shapes, same URL, same backend:

**Single HTML file** — maximum portability, everything inline. Use for text-heavy decks, or when you're embedding images as base64 anyway.

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
slideless push ./deck.html --title "My talk"
```

**Folder** — any layout, no forced `/assets/` convention. Use when you have images, video, 3D models, shaders, or separate CSS/JS bundles. Relative paths inside the HTML (`./hero.jpg`, `./images/logo.png`, `./three/scene.js`) resolve exactly like a static webserver.

```
deck/
├── index.html          (entry file; override with --entry)
├── styles.css
├── images/
│   └── hero.jpg
└── three/
    ├── scene.js
    └── model.glb
```

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
slideless push ./deck --title "My talk"
```

The CLI walks the folder and uploads every file that isn't in the default ignore list (`.git/`, `node_modules/`, `.DS_Store`, `*.log`, `slideless.json`, etc.) plus whatever a `.slidelessignore` file at the folder root excludes. Parent-directory references (`<img src="../outside/foo.jpg">`) are rejected at upload time — decks must be self-contained within their root.

See [Working with assets](/guides/working-with-assets) for a deep dive.

## Size and file-count caps

Caps depend on your plan:

| Tier       | Max single file | Max total deck | Max file count | Max HTML file |
| ---------- | --------------- | -------------- | -------------- | ------------- |
| Free       | 50 MB           | 250 MB         | 500            | 10 MB         |
| Starter    | 100 MB          | 500 MB         | 1000           | 10 MB         |
| Pro        | 250 MB          | 2 GB           | 2000           | 20 MB         |
| Business   | 500 MB          | 5 GB           | 5000           | 20 MB         |
| Enterprise | 1 GB            | 20 GB          | 10000          | 50 MB         |

Uploading content that exceeds any cap returns `413 payload-too-large`. External CDN references (`https://unpkg.com/...`, `https://fonts.googleapis.com/...`) don't count against your quota — only uploaded bytes do.

## Content-addressed storage and deduplication

Under the hood, each file is stored at a path derived from its SHA-256 hash. When you push an update, only the files whose contents actually changed re-upload — everything else dedupes. A five-version deck with one changed image across versions costs you \~1.1× the size, not 5×.

The CLI reports dedup hits after every upload:

```
Assets uploaded: 1
Assets deduped:  12
```

## Lifecycle

1. **Push** via `slideless push <path> --title "..."` — creates a new unshared presentation. No public URL yet. Writes `slideless.json` at the deck root.
2. **Share** via `slideless share <presentationId>` — mints a viewer token whose `versionMode` is `latest`. The URL this returns is what you send to recipients.
3. **View**: anyone with the token URL renders the deck in a sandboxed iframe; view count increments server-side.
4. **Collaborate** via `slideless invite <presentationId> --email <addr>` — grant another user push + pull access. See [Collaboration](/concepts/collaboration).
5. **Re-push** — run `slideless push` again from the same folder to bump the version. Tokens + view counters preserved, unchanged files deduped.
6. **Pin** via `slideless pin <presentationId> <tokenId> --to-version <N>` — freeze a specific recipient on a specific version so later pushes don't affect their view.
7. **Unshare** via `slideless unshare <presentationId>` — revoke every token on the deck (or one, with `--token <tokenId>`). The deck itself stays editable; you can mint new URLs later.
8. **Delete** via `slideless delete <presentationId>` — hard-remove the deck, every version, every asset, every collaborator row. Irreversible. See [Lifecycle](/concepts/lifecycle).

## Not yet in v3

* Expiry dates (schema supports `expiresAt`, not exposed in CLI/dashboard yet).
* Garbage-collection of unreferenced blobs (storage grows with history; manual cleanup not automated).
* In-dashboard upload — v3 uploads are CLI-only. The dashboard handles browsing, previewing, token management, collaborators, sharing/unsharing, and deletion.