BoomerClip is a browser-based screen recording application that allows users to easily capture and share their screen without requiring any software installation. The recorded video is ephemeral and automatically deletes when the viewing page is closed.
Live at boomerclip.com, for a small group of testers first.
- Code on GitHub (private), with history cleaned of test recordings and old credentials
- Installs and runs locally on Windows; the API, login and admin panel work
- Recording and upload work in Chrome
- Shared links play in Chrome
- Recordings are deleted when the viewer leaves, and refreshing asks first (fixed September 2026)
- Full code review done (September 2026), with an honest assessment and a fix plan
- Clean-up, phase 1 of the fix plan: unused "enterprise" code and 25 packages removed, production build compiles and runs, first automated tests check that recordings are deleted when viewers leave
- Phase 2, part 1: security fixes with tests for each. Uploads are checked to be real recordings, no one can switch deletion off, passwords stay out of logs, the free-premium loophole is closed, and recording lengths are measured correctly
- Phase 2, part 2: deletion is now a server guarantee. A recording can only be watched through its viewing page, leftover files are cleaned up, a server restart can't keep a recording alive, only its creator can delete it early, and sign-in and upload limits work behind a proxy
- Phase 3, part 1: the viewing page is safe from accidental deletion. Every way of leaving asks first, errors can be retried without losing the recording, an open page is told when its recording is deleted, and the person who recorded can check their own link without using it up
- Recordings-deleted statistic: the home page shows how many recordings were deleted beside how many were made, and its stats are always real numbers
- New look: a redesigned home page, logo and app icon from the brand artwork; no lint warnings or deprecation warnings left in the build tools
- Web client moved from Create React App (unmaintained) to Vite: current build tools, no known security advisories in the client's packages, and a production build that talks to its own server without extra setup
- Phase 3, part 2: one video player for every browser, with controls that work from the keyboard and screen readers; a browser that can't play a recording is told before the link is used; shared links checked in Safari on a Mac and an iPhone
- Shared links re-tested in Edge and Firefox: everything passed; clearer wording when several people watch one link, and a pop-out video button
- Phase 4, part 1: a more reliable recorder. The microphone and computer sound record together, recordings have a clear size limit with a warning, messages say what went wrong and what to do, and phones are told they can't record; checked in Chrome
- Phase 4, part 2: consent asked once per visit and working even when storage is blocked, no third-party location lookup, links can't lose a recording, and a secure local connection for testing on other devices
- Recording re-tested in Edge, Firefox and Safari: everything passed after a fix for Firefox recordings without sound
- Phase 5, part 1: a written list of exactly what the app collects; logs no longer link IP addresses to recordings or keep emails; you can delete your own account; the premium page is honest about what's coming
- Phase 5, part 2: a plain-language privacy policy and terms that match what the app really does (drafts until a lawyer reviews them), a minimum age of 18, and every project document checked against the code
- Phase 6: current build tools on the server, usage totals for admins, log files kept no longer than 30 days, and new deploy scripts rehearsed on a local copy of the server
- First deploy: live at boomerclip.com with a secure connection, no visitor access logs, and recordings never backed up
- Reporting: anyone with a link can report a recording, which removes it at once; admins review reports and can suspend accounts; the terms and privacy policy explain reports, legal requests and responsibility for what you share
- Uploads go straight to disk with a limit on how many run at once, and a page for addresses that don't exist
- Password reset by email and password change from the dashboard, with a notice email each time
- Two-step sign-in with an authenticator app, optional for every account, with recovery codes and notice emails
- Fixed: the dashboard said two-step sign-in was off until you reloaded the page, and "Member since" was blank; every page now gets the whole account the moment you sign in
- Testing with a small group of people
- Wider launch, once the business is registered and a lawyer has reviewed the privacy policy and terms
Live at boomerclip.com since 15 September 2026, tested by a small group first. BoomerClip was built in May–June 2025, then set aside for a year. It was brought back up in September 2026.
What's next
- Watch the first real use, including any reports, and fix what the testers find; admin panel fixes
- Smaller improvements: an email to the admin when a report arrives, and clearer messages for an email address the server refuses
- Before a wider launch: register the business and have a lawyer review the privacy policy, terms, consent wording and how reports handle illegal content
- One-click screen recording for any application or full desktop
- Record your microphone and your computer's sound together in one recording (Chrome and Edge; Firefox and Safari record the microphone)
- If you asked for your computer's sound but the share window didn't include it, recording doesn't start: you're told why and can share again or record without it
- Recordings have a clear size limit (100 MB, over six minutes of the busiest screen): the recorder warns as a recording nears it and stops by itself at the limit, keeping everything recorded
- Plain-language messages when something goes wrong: a blocked or missing microphone, a cancelled share window, a dropped connection while sharing, an expired sign-in. Your recording stays on the page so you can try again
- Phones, tablets and pages opened without https are told up front that they can't record, instead of showing a button that fails
- A consent step before recording asks you to get everyone's permission first, says plainly what happens to your recording, and makes no location lookup. It's asked once per visit, so the next person on a shared computer is asked too, and it works even when the browser blocks site storage
- Clicking a link or the back button while recording, uploading or before sharing asks first, so a recording isn't lost by accident
- A recording shared while signed in is tied to your account
- Automatic thumbnail and duration detection after upload (including Chrome recordings, whose files don't state their length)
- Uploads are checked to be real WebM or MP4 recordings; anything else is turned away with a clear message and nothing is kept
- Unique shareable link generation
- Ephemeral videos that auto-delete when viewing ends, guaranteed by the server: a recording can only be watched through its viewing page, and its files never outlive it (even if the server restarts mid-view)
- Asks before any way of leaving the viewing page (refresh, close, a link, the back button) deletes the recording, and keeps it if the viewer changes their mind
- The person who recorded can open their own link to check it, see whether it has been opened, or delete it, without using it up
- If playback hits a problem, the viewer can try again without losing the recording, and an open page says so when its recording has been deleted
- A brief network drop or a server restart doesn't delete a recording mid-view; the viewer reconnects and keeps watching
- Only the person who recorded (or an admin) can delete a recording early
- One video player for every browser: controls that work from the keyboard and with screen readers, full screen on iPhone, and a pop-out button to keep watching in a small floating window (Edge, Chrome and Safari; Firefox has its own)
- When several people have the same link open, the recording stays until the last of them leaves, and the page tells each viewer so instead of promising a deletion that hasn't happened yet
- If a browser can't play a recording, the viewer is told before the link is used, so they can open it somewhere else
- Optimized video playback with range requests for smoother streaming
- Smart thumbnail generation with multiple timemarks for better preview experience
- Automatic video playback after processing completes
- Designed for Chrome, Firefox, Edge and Safari (recording verified in Chrome, Edge and Firefox on Windows and in Safari on a Mac; shared links verified in Chrome, Edge and Firefox on Windows and in Safari on a Mac and an iPhone)
- Public statistics on the home page: recordings created beside recordings deleted (every deletion counted once, including links nobody opened), so anyone can see recordings really go. The counts start again from zero if the server restarts
- Uploads are written straight to disk and only so many are handled at once, so a busy moment can't overwhelm the server; if it's full, you're asked to try again in a moment and your recording stays on the page
- A clear page for addresses that don't exist, including recording links that were copied incompletely
- No software installation required (browser-based)
- Optional user accounts with a dashboard, plus an admin panel (user management, health checks)
- Delete your own account from the dashboard at any time (you confirm with your password)
- Forgot your password? Get a one-time reset link by email; setting a new password signs your account out everywhere
- Change your password from the dashboard; you stay signed in there and every other sign-in ends
- An email tells you whenever your account's password changes, sent from BoomerClip's own mail server (no email company in between)
- Add two-step sign-in with an authenticator app, so knowing your password is not enough to sign in as you: scan a QR code drawn on the page itself (nothing is sent to anyone to make it), keep ten one-time recovery codes for a lost phone, and get an email whenever any of it changes. Optional for every account
- The key your authenticator app shares with BoomerClip is stored encrypted, with the key to read it kept off the database and out of every backup, and a password reset by email asks for a code as well — so an emailed link alone is not a way past your second step
- Report a recording that shouldn't have been shared, from its page or from its link without watching it again: it's removed for everyone straight away, and the report (never the recording) is kept for review
- Admins review reports and can suspend an account, always by hand and reversibly; nothing suspends anyone automatically
- Logs are kept lean: they never link a visitor's IP address to a recording they watched or shared, and never hold email addresses or browser details
- A privacy policy and terms written from a list of exactly what the app collects, in plain language, marked as drafts until a lawyer has reviewed them
- Premium is "coming soon": the premium page shows what is free today and what paid plans are planned to add, with no prices until payments exist
- Admins see usage totals (recordings, views, data served and new accounts per day and month) that count activity without recording anything about any person
- A branded home page and app icon: the BoomerClip by RawData logo on every page, scenes from the brand artwork, and a self-hosted handwritten accent font (no third-party font requests)
- Backend: Node.js with Express
- Frontend: React with Tailwind CSS, built with Vite
- Video Recording: MediaRecorder API
- Temporary Storage: Redis for recording details and who is watching; the video files live on disk only as long as their details do
- Database: MongoDB (for user accounts)
- Hosting: a Linux server (OVH, United States) running the app as a system service behind nginx
- Viewing sessions: Socket.io, which tells the server who is watching and when they leave
Fixes
- The dashboard said two-step sign-in was off after signing out and back in, and on again after a reload: the sign-in answers carried an account without its
twoFactorstatus, and the page believed them until the profile arrived - "Member since" on the dashboard was empty until the page was reloaded, for the same reason
Technical Improvements
- One
accountForClient()on the server builds the account carried by every answer that carries one (registering, signing in, the second step, the profile), replacing four hand-written literals that had drifted apart - Three tests that compare those answers with each other, so a field added to one of them can no longer be missing from the rest (server tests 273 → 276)
- Prettier over
services/authService.ts, whose Session #54 lines had never been through it
Features
- Ten one-use recovery codes, shown once, to copy or save as a file; each signs in once if the authenticator app is lost, and using one emails the account with how many are left
- An email whenever two-step sign-in is turned on or off, new recovery codes are made, or a recovery code is used
Technical Improvements
utils/totp.ts: TOTP (RFC 6238 over RFC 4226) written overnode:cryptoand checked against both RFCs' published test vectors. A code is accepted one 30-second step either side of now, and never for a step already usedutils/secretBox.tsandconfig/twoFactorKey.ts: an account's shared key is stored encrypted (AES-256-GCM) underTWO_FACTOR_KEY, which production refuses to start without and which is never backed up, so a copy of the accounts collection cannot sign in as anyone- Five wrong codes in a row stop an account's codes being accepted for fifteen minutes, beside the per-address sign-in limit
- Server tests 213 → 273 and client 176 → 185; 26 deliberate breaks caught in isolated copies; 23 checks in headless Chrome, one comparing the QR on screen with the encoding of the expected
otpauth://URI module for module
Fixes
- The wrong-code message now says a code works once and to wait for the next one, instead of "check the code your app is showing now" when the app is showing the one just used
- The deploy rehearsal's post-rollback health check was passing on a 502: it asked once, immediately after the restart, and
set -eignores a failure before&&. It now waits and fails when health does not come back
Docs
- Privacy policy and its review copy,
DATA_INVENTORY.md,API.md,DATABASE_SCHEMA.md,CODE_MAP.md,ARCHITECTURE.mdandSECURITY_GUIDE.mdupdated from the code; a decision entry and guideline 86 rdsync/deploy/README.md: how to add two-step sign-in to a running server, and whyTWO_FACTOR_KEYis never rotated
Features
- A page for addresses that don't exist, which explains that a recording link may have been copied incompletely
Enhancements
- Uploads stream straight to disk instead of memory; at most 12 at once (one more is asked to try again in a moment), 2 processed at a time, and none while the disk is nearly full
- A person who leaves while their recording uploads or is processed leaves nothing behind
- The home page and the admin Usage card say the counts start from zero when the server's Redis restarts
Fixes
- An upload abandoned mid-send is no longer logged as a server error
Docs
- Privacy policy and
DATA_INVENTORY.md: the emails sent, the mail log (about five weeks), reset fields, counts that reset; the privacy mailbox marker removed - Deploy README: adding email to a running server; the server copy of the deploy scripts is replaced, not nested
On the source. This page mirrors a private repository. The milestones, changelog and narrative come from the project's own README and CHANGELOG, and the statistics are read live from the GitHub API, so it reflects the state of the work rather than a summary written after the fact. No source code is published here.