Fair points, especially on GSM8K saturation and Qwen possibly already sitting close to the solution. That said, even if this is mostly "last-mile alignment", the fact that it can be done with such a tiny signal is still interesting, it suggests the gap between capability and behavior might be much smaller (and cheaper to bridge) than we assume.
If 13 parameters can unlock better reasoning, then we will not be "training" models, we'll be steering them. Most of the capability is already there.
The real unlock isn’t TinyLoRA, it’s what this implies: ultra-cheap, continuous adaptation. The bottleneck shifts from compute to having a good reward signal.
You can also do this with a simple bookmarklet, no extension needed.
Create a new bookmark in your browser, name it something like "Profile HN User", and paste this as the URL:
javascript:void(function(){var u;var m=window.location.href.match(/news\.ycombinator\.com\/user\?id=([^&]+)/);if(m){u=m[1]}else{u=prompt(%27Enter HN username:%27)}if(!u)return;var msg=%27Profile this HN user: https://hn.algolia.com/api/v1/search_by_date?tags=comment,au...})()
If you're on a HN profile page (news.ycombinator.com/user?id=someone) it grabs the username automatically. Otherwise it prompts you to type one. It copies the profiling prompt to your clipboard and opens a new Claude conversation, just Cmd/Ctrl+V and hit Enter.
Thanks for the feedback. This is a proof of concept, not production-hardened software, and the README should be clearer about that.
To your questions:
- 1. The CryptoKey is extractable: false, so JS can't export the raw key material, it only exposes encrypt/decrypt operations. It won't stop a full XSS attack on the same origin, but it does prevent casual inspection of IndexedDB/DevTools. Defense in depth, not a silver bullet.
- 2 & 4. You're right, the fetch_url tool and javascript eval in the worker both have unrestricted network access. A confirmation step for outgoing requests is worth adding. Good callout.
- 3 Honest oversight, no reason the Telegram token shouldn't get the same treatment. Will fix.
Updating the security language in the README to be more accurate about the threat model. PRs welcome if anyone wants to tackle sandboxing the JS tool (iframe with a null origin is one approach).
Thanks! Currently the scheduler runs on the main thread. It checks every 60s and fires due tasks while the app is open. So it works well for recurring prompts during active use, but won't fire if the PWA is closed since browsers don't support persistent background timers. Periodic Background Sync is the closest web API but it's Chrome-only with no timing guarantees, so for now pinning the tab is the reliable path.