A Chrome extension to never miss a Greg creation

Greg has built a small but eclectic set of web toys—an IKEA complexity index, a sound‑synthesizer called Boing, and a handful of other experiments—all hosted under the greg.technology domain. For developers who follow his work, missing a new subdomain can feel like skipping a surprise release, especially when the URLs are terse and the projects appear without fanfare.

The solution is a Chrome extension that surfaces any link pointing to *.greg.technology. Built on Manifest V3, it declares a content script that runs on every page, scanning the DOM for anchor elements whose href matches the pattern https?://*.greg.technology/*. When a match is found, the script injects a small badge next to the link and updates the extension’s toolbar badge count, giving the user an at‑a‑glance indicator that a Greg project is present.

Behind the scenes a service worker handles the heavy lifting. It stores user preferences—such as whether to highlight only first‑party links or all subdomains—in Chrome’s storage.sync, allowing settings to follow the user across devices. The popup UI, rendered with plain HTML and a touch of CSS, offers a toggle for “quiet mode” and a quick link to the GitHub source. Communication between the content script and the service worker uses the standard chrome.runtime.sendMessage channel, keeping the extension’s footprint small and avoiding the need for persistent background pages.

Detecting Greg’s work isn’t as trivial as matching a static domain. The developer chose a regular expression that tolerates optional www, sub‑subdomains, and trailing paths, while explicitly excluding known false positives like example.greg.technology used for testing. To respect privacy, the extension never logs URLs to external servers; all processing stays local, and the only data persisted is the badge count and user preferences.

The project is open‑source on GitHub, inviting contributions to broaden its scope—perhaps adding support for other creators who publish under a common domain pattern. Its modest codebase (under 500 lines) serves as a practical example of how declarative content scripts, service workers, and Chrome’s storage APIs can be combined to build a focused, privacy‑first utility.

In a landscape where content discovery often relies on algorithmic feeds, a simple domain‑watcher reminds us that a few lines of code can keep a community tightly connected to the creators they admire, without the noise of broader recommendation engines.