DEV Community: ethan

Bookmarks before transcripts: what we learned building a lecture recorder

ethan — Thu, 12 Nov 2026 14:29:20 +0000

TL;DR: AI Lecture Recorder records lectures offline, lets you bookmark the moments that matter with one tap, and transcribes only when you ask it to. This post is about why the bookmark button ended up more important than the AI.

🤖 Google Play · 📱 App Store

Originally published on the Nexa Tech blog.

When we started AI Lecture Recorder, the obvious headline feature was transcription: record an hour, get an hour of text. Students told us they rarely read a full transcript. What they wanted was to find the five minutes that mattered. So we organised the product around three moments in a student's day.

Before: start recording fast. Open, tap record, put the phone on the desk. No setup screen in the way.
During: mark what matters. One tap to bookmark the moment the lecturer says "this will be on the exam".
After: find it again. Jump straight to bookmarks, and transcribe only when text actually helps.

Before: getting out of the way

Lectures start whether you are ready or not. The app opens straight to a record button, and recording works fully offline. Nothing about capture depends on a network or an account.

During: one tap beats a note

The biggest button on the recording screen, after stop, is bookmark. One tap marks the current moment. A label can be added later, but doesn't have to be. Marking something takes less effort than writing it down, so people actually do it.

The most advanced feature is not always the most useful one. Sometimes it is a single button that fits the moment.

After: review, not replay

Reviewing a lecture is different from listening to music. You skip, rewind a few seconds, slow down a dense part, speed through a tangent.

Record: phone on the desk, screen off
Tap to bookmark: mark the moment, label it later
Jump back: playback starts just before the mark
Transcribe: optional, when text helps

Bookmarks do the finding; transcription is there when you want words.

Playback starts slightly before each bookmark so you hear the lead-in.
Skip buttons are sized for the short jumps people make most.
Speed control is one tap, not buried in a menu.

Where transcription fits

Transcription is still there, powered by Groq, for when text genuinely helps: searching for a term, copying a definition into notes, or reviewing in a quiet library without headphones.

You want to…	Best tool
Find the exam hint	Bookmarks
Re-hear an explanation	Bookmarks + playback speed
Search for a term	Transcript
Copy a definition into notes	Transcript

Optional on purpose. Transcription is a choice per recording, not a default. People decide when audio is sent for processing, and recording never depends on it.

Update: what's new in 2.0

Since this post first went up we shipped recording with the screen off, trimming, folders, and export to audio, TXT or PDF. We also removed subscriptions: you can now earn points to unlock the premium AI features instead of paying monthly.

If you're a student (or build tools for students), I'd love feedback:

What would make you actually review a lecture recording instead of letting it sit in a folder?

A QR scanner that shows you the link before it opens

ethan — Thu, 12 Nov 2026 05:04:25 +0000

TL;DR: ScanQR is a free QR code and barcode scanner for Android and iOS that never jumps straight to a website. It shows you the real domain first and warns about suspicious links. This post explains why we built it that way.

🤖 Google Play · 📱 App Store

Originally published on the Nexa Tech blog.

Many scanners open a link the instant they read a QR code. It feels fast. It also means visiting a website without ever seeing its address, which is exactly what a fake sticker on a parking meter is counting on. ScanQR adds one step: a preview. This post explains what that preview shows and why.

Anatomy of a suspicious link

Here is a made-up address of the kind found on fake parking stickers:

https://pay.citypark-0nline.com/meter/4471?ref=sticker

"pay" and "meter" make it look official, but the real domain (citypark-0nline.com) is not the city's, and the zero in "0nline" is a classic lookalike trick. Shown full size, it is easy to spot. Hidden behind an instant redirect, nobody sees it at all.

Every scan passes through a preview

Scan a QR code or barcode
Classify it: link, Wi-Fi, contact or text
Preview it, with the real domain shown large
Act: open, copy, connect or save

Nothing opens until the user decides.

What the preview shows for each type

Content	Preview shows	Main action
Web link	Real domain, large, separate from the rest	Open in browser
Wi-Fi	Network name and security type	Connect
Contact	Name, phone, email	Save to contacts
Plain text	The text itself	Copy

Signals we point out

Shortened links: they hide where they really go.
Plain http without encryption.
Lookalike domains: a well-known name spelled slightly differently.
Very long addresses where the real domain is pushed out of view.

A preview is not a guarantee. None of this proves a link is safe. It gives people the information to make their own decision, which is more than an instant redirect does.

Half a second of friction is a fair price for knowing where you are going.

Beyond scanning

Scans are saved to a searchable history on the device, so the menu from lunch or the event link from a poster is still there tomorrow. The same app generates codes for Wi-Fi networks and contact cards, which turned out to be popular with small shops and cafes.

Update: what ScanQR 2.0 added

Since this post first went up, the preview grew into a fuller set of features:

More scam checks: raw IP addresses, look-alike characters, and links pretending to be banks or big retailers now get a warning before you open them.
Payment QR codes: reads and creates Pix, UPI, SEPA/EPC GiroCode, Swiss QR-bill, PromptPay, VietQR and other EMVCo formats, so you can see who you're paying before your banking app opens.
Product and book lookups: EAN/UPC and ISBN barcodes are looked up via Open Food Facts, Open Beauty Facts and Open Library.
Every common format: QR, Data Matrix, Aztec, PDF417, EAN, UPC, ITF, Code 39/93/128 and Codabar.
Private by default: no account, and history stays on the device. Available in 22 languages.

Try it free:

How do you handle link previews in your own apps? I'd love to hear other approaches in the comments.

How we find duplicate photos and pick the best shot on-device (React Native + Expo modules)

ethan — Wed, 11 Nov 2026 13:20:22 +0000

TL;DR: CleanMaster is a free iOS & Android app that frees up phone storage: it finds duplicate and similar photos, keeps the best shot, clears old screenshots, chat-app media and big videos, and locks private files in a vault. Everything runs on the device. This post is how the photo part works under the hood.

📱 App Store · 🤖 Google Play

Phones fill up with near-copies: the same meme saved three times, a forwarded photo that came back from WhatsApp, a burst of 12 shots where only one has everyone's eyes open.

While building CleanMaster, a storage cleaner for iOS and Android, we set two rules: nothing leaves the phone, and nothing is deleted that the user hasn't reviewed. That ruled out sending photos to a cloud model. Here's how the on-device pipeline works, with the actual code.

1. Fingerprinting photos with difference hashes

To find "the same picture saved more than once", we need a fingerprint that survives re-compression and resizing (what chat apps do to a forwarded photo) but changes when the picture really changes.

A difference hash (dHash) fits well: shrink the image to a tiny grayscale grid, then store one bit per pixel saying whether it is brighter than its right-hand neighbour. Re-encoding a JPEG barely moves those comparisons; cropping or editing does.

We compute two of them in a native Expo module (Swift on iOS, Kotlin on Android):

a coarse 64-bit hash (9×8 grid) to gather candidates quickly
a fine 256-bit hash (17×16 grid) to make the final decision

The thresholds are deliberately tight:

/**
 * Differing bits allowed. The coarse 64-bit hash only gathers candidates; the
 * 256-bit one decides. Kept tight: two different screenshots of the same app
 * screen look alike at this size, and a false match means a wrong deletion.
 */
const COARSE_MAX = 3;
const FINE_MAX = 8;
/** Copies keep their shape; a different aspect ratio is a different picture (or a crop). */
const ASPECT_TOLERANCE = 0.02;
/** Fewer set (or unset) bits than this in the 256-bit hash means a near-flat picture. */
const MIN_DETAIL_BITS = 24;

The last constant matters more than it looks. Black frames, white walls and pocket shots all hash to almost the same value, so "near-flat" pictures are excluded from duplicate matching entirely.

Comparing hashes is a Hamming distance. We split the hex string into 32-bit words and popcount the XOR, bailing out as soon as the limit is passed:

function popcount(v: number) {
  v -= (v >>> 1) & 0x55555555;
  v = (v & 0x33333333) + ((v >>> 2) & 0x33333333);
  return (((v + (v >>> 4)) & 0x0f0f0f0f) * 0x01010101) >>> 24;
}

function distance(a: Int32Array, b: Int32Array, max: number) {
  let d = 0;
  for (let i = 0; i < a.length && d <= max; i++) d += popcount(a[i] ^ b[i]);
  return d;
}

Hashes are cached by asset ID in the app's cache folder (they can always be recomputed), and we hash four photos at a time. A nice side effect on iOS: the small local thumbnail of an iCloud-only photo hashes the same as the full image, so we don't need to download anything.

2. Deciding which copy to keep

For true duplicates the rule is simple: keep the copy with the most pixels, and if that's a tie, the oldest one.

function better(a: WinItem, b: WinItem) {
  const pa = a.width * a.height;
  const pb = b.width * b.height;
  if (pa !== pb) return pa > pb;
  const ta = a.createdAt || Infinity;
  const tb = b.createdAt || Infinity;
  return ta !== tb ? ta < tb : a.id < b.id;
}

3. Best Shot: picking the winner in a burst

Bursts are harder. The shots aren't duplicates; they're different moments a fraction of a second apart, and "keep the first one" is often wrong. So the native module scores each photo:

Sharpness: variance of the Laplacian on a grayscale copy. Blur flattens edges, so the variance drops.
Exposure: mean brightness plus the share of clipped (blown-out or crushed) pixels.
Faces: on iOS, Vision's VNDetectFaceCaptureQualityRequest plus face landmarks, where we compute an eye aspect ratio (about 0.3 is wide open, under 0.1 is shut). On Android, ML Kit face detection's eye-open probability. The worst face in the frame counts, because one person blinking ruins a group shot.

Then each burst is ranked relative to itself:

const maxSharp = Math.max(...qs.map((q) => q.sharpness), 1);
const maxFaces = Math.max(...qs.map((q) => q.faces));
// ...
const sharp = q.sharpness / maxSharp;
const exposure = Math.max(0, 1 - Math.abs(q.brightness - 0.5) * 1.6 - q.clipped);
if (!maxFaces) return { item, total: 0.7 * sharp + 0.3 * exposure, q };
const signals = [q.eyesOpen, q.faceQuality].filter((v): v is number => v != null);
// Someone missing from the frame (turned away, cropped) counts against it.
const face = (signals.length ? signals.reduce((a, b) => a + b, 0) / signals.length : 0.5) * (q.faces / maxFaces);
return { item, total: 0.4 * sharp + 0.4 * face + 0.2 * exposure, q };

Two details made a real difference:

Sharpness is relative to the sharpest shot in the same burst. A dim restaurant photo is never as "sharp" as a sunny beach, and it shouldn't be punished for that.
faces / maxFaces penalises the frame where someone turned away or walked out of shot.

The app also shows why a photo won ("Sharpest · eyes open"), and you can tap to compare before deleting. People trust a cleaner far more when it explains itself.

What we learned

Bias towards false negatives. Missing a duplicate costs a few MB; a wrong match costs someone a photo they cared about.
Make caches recomputable and store them where the OS is allowed to purge them.
Native modules pay off. Hashing and scoring in Swift/Kotlin through Expo modules, with JS only orchestrating, kept scans of thousands of photos usable on mid-range Android phones.
On-device is good enough. Apple Vision and Google ML Kit cover faces and eyes for free, with no privacy questions to answer.

Try it

CleanMaster is free on both stores. It also cleans old screenshots, chat-app media and big videos, and includes a PIN-locked private vault:

Happy to answer questions about the hashing or the scoring in the comments.