Skip to main content

​
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), each of which resolves to a specific version or follows the latest.
  • An append-only version history (see 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.
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.
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 for a deep dive.

​
Size and file-count caps

Caps depend on your plan: 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:

​
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.
  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.

​
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.