Three apps got the same treatment today: ownscribe, inbox0, and weekly. But it wasn't three separate features. It was one pattern, repeated across an entire suite -- and it turns out the pattern was three months overdue.
Service Workers That Actually Update
PWAs have a well-known problem: deploy a new build and half your users never get it. They keep serving from an old service worker cache until they clear browser data manually. I've seen it in my own apps every time I pushed a fix.
The fix is embarrassingly simple. Instead of hardcoding CACHE_NAME = 'ownscribe-v2'
or 'weekly-v9', compute a hash of every UI file's modification time at serve time.
Change one stylesheet? New hash. New SW. Browser sees a different CACHE_NAME,
activates it, purges the old one, and reloads the page. No manual cache clearing. No "clear site
data" instructions in your issue tracker.
I applied it to seven apps today. The pattern is now consistent across the suite:
- Server computes a short hash from all UI file mtimes on every request to
/static/sw.js. - SW templates now read
const BUILD_VERSION = '__BUILD_VERSION__'and derive their cache name from it. - Frontend hooks into
controllerchangeso the browser auto-reloads when a new SW activates. - HTML pages are fetched network-first (no more stale UI). API caches are also versioned by build hash.
This is not a clever trick. It's what I should have done on day one. But the reason it's worth noting is that it exposed a pattern: deployment hygiene is a platform concern, not something each app should reimplement or forget. Tomorrow someone else will need it too.
inbox0 Finally Has a Real Dashboard
inbox0 has always pulled emails, triaged them with AI, and shown you what's a must, should, or nice to reply to. But the UI was static. Once an email landed in a category, it stayed there. Until today.
Three things changed:
1. Reprioritize with undo. Every email card now has a dropdown to move it between must/should/nice/notifications categories. If the patch request fails, the move reverses optimistically -- same pattern as the rest of the dashboard.
2. Dismiss and restore. Dismiss any card and it disappears from the live view, drops into a "Cleared" panel you can toggle open. A toast with an Undo button means that dismissal was reversible. Click Restore in the cleared panel and it pops back into its original place.
This is what triaging actually feels like. You clear your inbox. You come back later. You realize you didn't want it gone after all.
3. Everything is now collapsible. Priority groups, category sections, and
individual email cards all collapse with a click. Your choice is persisted in localStorage.
You can expand or collapse all with one button. And each category has a sort toggle --
newest or oldest first -- also persisted.
These aren't theoretical UX improvements. They're fixes for things I kept wanting while dogfooding inbox0 for a week: the ability to say "this doesn't matter right now" without deleting it, and the ability to close 12 cards you've already read so your screen actually fits on a laptop.
The difference between a tool and a dashboard is whether it understands your triage decisions in real time. inbox0 just got a lot closer to the latter.
The Bigger Question
Service worker cache busting is the kind of thing you fix once and never think about again. But inbox0's triage improvements sit in the same place I've been pushing toward for months: a personal dashboard that actually behaves like one. Something that lets you surface what matters, defer what doesn't, and undo your mistakes.
The next step is making that dashboard cross-app. The triaged must list from inbox0 should feed directly into the Pomodoro timer's suggested tasks. And the cleared panel across all apps should tell you not just what you dismissed, but what you've already handled.
One dashboard. Seven apps. Your rules.
If you are interested, reach out.