LeakGuard v1

Now I added a privacy-safe password checker to FluxOSINT. Instead of sending passwords to the server, I used browser-side hashing and k-anonymity to only query small hash prefixes against a public breach database.

The coolest part was realizing the backend never touches the real password at any point so all the sensitive work stays in the browser. It made the feature feel way more “real-world” than just calling an API.

Next up, I’m adding Reports v1 so FluxOSINT can generate clean PDF intel summaries instead of just showing raw JSON.

Module Engine v1

Now I turned FluxOSINT from a database into an actual system. I built a module engine that automatically runs OSINT tools when a target is added instead of just saving it.

My first real module checks if a username exists on a few major platforms and returns results instantly in the API. Watching it scan and respond in real-time was honestly the “okay this is real now” moment.

Next up, I’m building Email Intel + Breach Check, so FluxOSINT starts doing actual security analysis instead of just presence checks.

Today I finally got FlavorForge’s streak system working, and honestly this was way more of a fight than I expected.

At first, my popup just kept throwing a “failed to fetch” error, even though the API endpoint worked fine in the browser. Turns out Chrome extensions don’t like you talking to random websites directly because of CORS. So I had to reroute everything through the content script and basically make the page itself fetch the data for me, then pass it back to the popup. Once I did that, it instantly clicked into place.

Now FlavorForge:

• Pulls the latest devlog
• Figures out if I posted today or yesterday
• Updates my current streak and best streak
• Shows a 🔥 badge in the Flavortown sidebar that updates in real time

Seeing that little fire icon pop up in the menu for the first time was lowkey way more satisfying than it should’ve been.

Next up, I’m planning to build the Vault system so I can save projects I like, tag them, and actually find them later instead of losing them in the explore feed forever.

Focused on packaging and distribution for this phase. I experimented with building a Windows installer using electron-builder and ran into platform-specific code signing and tooling constraints. After testing different approaches, I decided to ship a portable Windows executable for this developer preview.

The portable build runs without installation or admin permissions and makes it much easier for others to try Flux quickly. This felt like the right trade-off for v0.2: prioritizing accessibility and reliability over a traditional installer.

With this, Flux now exists not just as source code, but as a real runnable desktop app.

Added incognito mode to Flux using isolated Chromium sessions so private tabs don’t share cookies or storage with normal tabs.

While testing, I ran into an edge case where tab reordering broke when dragging the first tab because fixed tab buttons were being treated like reorderable tabs. Fixed this by separating fixed controls from tab logic so only actual tabs participate in drag reordering.

Incognito tabs now work correctly, and the tab system is stable again.

Next up: content blocking.

Did some UX polish on Flux.

Added proper tab closing with a close button on each tab, smart switching when closing the active tab, and blocked closing the last remaining tab.

Also added a small but important browser behavior: you can now press Enter in the address bar to navigate, instead of having to click the Go button every time.

These changes don’t add new features on paper, but they make Flux feel much closer to a real browser in daily use.

Next up: improving tab interactions even more.

I built a web tool that explains pasted code using an AI backend.

The frontend sends code to a Node + Express API, which calls an LLM and returns structured JSON containing an overview, line-by-line explanation, and improvement suggestions.

The hardest part was handling unreliable AI output (like markdown-wrapped JSON), so I added defensive parsing to make the app stable.

I turned Explain My Code into a real frontend–backend app.

The frontend now sends code to a backend API, which responds with structured explanations (overview, line-by-line, issues). Setting this up forced me to think about data formats and separation of concerns instead of dumping logic into the UI.

With this structure in place, adding real AI-generated explanations should be clean and straightforward.