How Bento Uses Signed Manifests for Verifiable HTML Slides

Most presentation tools are just fancy ways to lock your data in a proprietary cloud. You don't actually own your slides; you own a subscription to a viewer that might change its layout or pricing whenever the company feels like it. Bento does something different. It packs the editor, the viewer, and the live data into a single portable HTML file.

It's an odd approach that feels like a throwback to the early web, but it works. I like that it's view-source honest. If you want to know how a transition is happening, you can just look at the code. The tool even checks a signed manifest at launch to handle updates, though you can toggle that off if you prefer your files to be truly static.

The feature set is lean. You get the standard shapes, tables, and media embeds, but the hover states are where it gets interesting. You can set them to reveal content or focus a group, which makes it feel more like a prototype and less like a linear deck.

The real question is whether a single HTML file can actually replace the convenience of a shared link.

The Single-File Philosophy

The goal here is to eliminate the "presentation mode" struggle. By bundling the editor and the viewer into a single HTML file, the document is its own runtime. You don't need PowerPoint, Keynote, or a specific version of a browser plugin to make it work. If you can open a web page, you can run the deck. It's a pragmatic approach to portability that treats a presentation like a piece of software rather than a slide deck.

This design creates a weird tension between convenience and file size. Because the CSS and JavaScript are embedded, the file is heavier than a plain text Markdown file. However, that's a fair trade. I'd rather have a 2MB file that works everywhere than a 10KB file that requires a specific environment to render.

The setup is straightforward. You aren't installing a heavy framework; you're just running a build command that squashes your content into a standalone file.

npm install -g slidev
slidev build

The resulting file contains everything. This is genuinely confusing for people used to traditional build pipelines where assets are split into different folders. In this model, the "build" isn't just optimizing code; it's fusing the logic and the content into one object. It's a return to the old-school way of distributing software, and it's the only way to guarantee the deck looks the same on a client's laptop as it does on yours.

Interactive Elements and Hover States

The "Reveal" and "Focus-group" states are a way to handle information density without cluttering the UI. Instead of using linear animations that slide elements into view, these states act as binary toggles. You're essentially hiding secondary data until the user expresses intent. It's a pragmatic approach to the "too much data" problem: you show the high-level metric first, and the granular details only appear on hover.

The "Focus-group" interaction is a bit more confusing because it's not just about visibility; it's about spatial relationship. It groups related data points together visually so the user doesn't lose their place when scanning a dense table. This is a better way to manage cognitive load than a standard tooltip, which often obscures the very data you're trying to highlight.

/* Toggle visibility and scale for a Reveal state */
.data-cell:hover .detail-view {
  opacity: 1;
  transform: scale(1);
  pointer-events: auto;
}

.detail-view {
  opacity: 0;
  transform: scale(0.95);
  transition: all 0.15s ease-out;
  pointer-events: none;
}

Some users find this behavior jarring. One person mentioned they'd prefer a global setting to kill all animations entirely. I get that. When you're staring at 20,000 rows of data, a 150ms transition can feel like a delay. If the interaction isn't instant, it's just friction.

Live-Linked Data and Tables

The "single-file" approach is a clever bit of engineering, but I think the community is conflating a neat technical trick with a fundamental shift in how we build. Using base64 and DecompressionStream to pack an entire app into one file is an impressive way to bypass traditional hosting friction, but it doesn't actually solve the problem of state management or long-term maintenance. It just changes where the complexity lives.

The real interest here is the signed manifest. If you can actually verify that the data you're seeing hasn't been tampered with since launch, it moves the needle on trust. Most "live" data is just a black box where we trust the API blindly. A signed manifest creates a verifiable trail. I'm not convinced this will move beyond a niche for high-security tools or enthusiast projects, but for those specific use cases, it's a meaningful upgrade over standard fetch calls.

I'm still skeptical about the "native transition" claim. Moving from a web-wrapped experience to something that feels truly native usually requires more than just a better data-loading strategy; it requires deep integration with the OS that a single-file manifest can't provide.

The question I'm left with is whether the "single-file" obsession is actually about portability, or if it's just a reaction to how bloated and fragmented modern dependency chains have become.

Security and the Signed Manifest

The signed manifest is a decent attempt at solving the "trust" problem for single-file apps, but I think it underestimates the friction of actual adoption. Checking a signature at launch is great for security-conscious users, but for the average person, it's just another prompt to click through. If the goal is to make the web feel more like native software, adding a manual verification step at the start of every session is a step in the wrong direction.

I've seen a lot of people on social media praising the "single-file" concept as a way to reclaim ownership of software. The Bento architecture—using base64 and DecompressionStream—is clever, and it proves you can build complex, collaborative tools without a massive backend. But there's a gap between "this is a cool technical feat" and "this is how we distribute software." Most users don't care if an app is one file or ten thousand; they care if it loads and doesn't leak their data.

The real question is whether this is a legitimate shift in distribution or just a niche preference for minimalism. I'm not convinced that signed manifests will stop the tendency for developers to just bundle everything into a bloated JS framework. We'll have to see if anyone actually keeps the signature check turned on after the novelty wears off.

Conclusion

The single-file philosophy is a nice return to how the web was meant to work. Having the deck, viewer, and editor all in one HTML file—with embedded assets and no account required—removes the friction that usually kills these types of tools.

I'm still skeptical about the signed manifest. While it's a clever way to handle verifiable updates at launch, the fact that you can just turn it off suggests it's more of a "nice to have" than a hard security requirement.

If the goal is true portability, does the added complexity of a signed manifest actually solve a problem most presenters have, or is it just over-engineering for a use case that doesn't exist?