Appreciate the kind words! Best of luck with whatever you are working on
259 karma · joined November 12, 2024
> A bit disappointed that it doesn't work on Firefox.
I swear the entire ~3% marketshare of FF users (myself included) are lurking in this thread lol. You are all giving me an excuse to increase the priority of cross-browser support
I do view this as somewhat of a meta-chrome extension. We've had people who were planning to make a simple, standalone chrome extension just build it using tweeks instead which is super cool to me. And congrats on your launch! Anything you're willing to share here?
> Also I find the founder journey interesting.
HR Tech is a segment littered with past founders and painful stories lol. It's been a long journey, but I will say that building this is more fun so far :)
Thank you! As others pointed out here, we admittedly didn't invest much in the "landing page" aspect, but I did work hard to make a great onboarding experience. Glad it shined through
> Since I also have to use Chrome for an extension I'm developing
We're in the same boat, I wouldn't be using chrome if not for this extension. Great to see HN has a strong cohort of Firefox users!
> Out of curiosity, how much, if any, of this did you vibe code?
A lot of the elements of the extension, backend, and even the onboarding page integrations push at the boundaries of what tools like codex and claude code can do right now.
We do believe in the tech (in some regards, the extension is powered by similar tech), and we are power users of both, but we also know when claude code has said "You're absolutely right" one too many times and we need to dig in and get our hands dirty.
And just to further clarify: "each use" means each generation. Applying the modification after generation doesn't cost tokens
I enjoy having control over my browser, as well. So much so that I built an extension that could help me with it :)
I didn't build this so I could make money, it was a side project that I tinkered with (after YC). I shared it with a few friends, they thought it was cool, their friends also thought it was cool, and it grew from there.
It's okay that many in the HN audience don't necessarily resonate with "Instead of digging through selectors and hand‑writing custom JS/CSS". At the very least, hopefully I inspired someone else to play with this idea. I personally think it is very cool and beneficial for the web!
More context: https://news.ycombinator.com/item?id=45916800
The VCs didn't fund us for this, we pivoted. (shhh don't tell them (edit: /s))
> I think it's better to use Tampermonkey/Greasemonkey. Rules are deterministic, you have full control, and you don't have to worry about monetization or malicious data collection in the future.
When you do a generation, the result is a deterministic script. You can even go to the options page and read the code for it yourself. From my experience though, writing a GM script from scratch is a massive pain. We just make that much more accessible.
> I really recommend against this. The AI spin doesn't add much since most sites have had rules that work for years, they don't change that often. Please don't build up this type of dependence on a company for regular browsing.
You're not wrong that rules can be robust. However, this extension has enabled me to build helpers that I never would have thought to implement by hand. E.g. on this page "highlight threads where jmadeano has not replied" -> super useful if I can generate it in a few seconds but a huge waste of time if I had to implement it myself.
If you're familiar with Greasemonkey, we work similar to the @match metadata. A given script could have a specific domain like (https://www.youtube.com/watch?v=cD5Ei8bMmUk) or all videos (https://www.youtube.com/watch*) or all of youtube (https://www.youtube.com/*) or all domains (https:///). During generation, we try to infer your intent based on your request (and you can also manually override with a dropdown.
> 2. What is your test and eval setup? How confident are you that the model is performing the requested change without being overly aggressive and eliminating important content?
Oh boy, don't get me started. We have not found a way to automate eval yet. We can automate "is there an error?", "does it target the right selectors", etc. But the request are open ended so there are 1M "correct" answers. We have a growing set of "tough" requests and when we are shipping a major change, we sit down, generate them all, and click through and manually check pass/fail. We built tooling around this so it is actually pretty quick but definitely thinking about better automation.
This is also where more users comes in. Hopefully you complain to us if it doesn't work and we get a better sense of what to improve!
> 3. What is your upkeep strategy? How will you ensure that your system continues to WAI after site owners update their content in potentially adversarial ways? In my experience LLMs do a fairly poor job at website understanding when the original author is intentionally trying to mess with the model, or has overly complex CSS and JS.
Great question. The good news is that there are things like aria labels that are pretty consistent. If the model picks the right selectors, it can be pretty robust to change. Beyond that, hopefully it is as easy as one update request ("this script doesn't work anymore, please update the selectors"). Though we can't really expect each user to do that, so we are thinking of an update system where e.g. if you install/copy script A, and then the original script A is updated, you can pull that new update. The final stage of this is an intelligent system where the script can heals itself (every so often, it assess the site, sees if selectors have changed and fixes itself) -> that is more long-term.
> 4. Can I prompt changes that I want to see globally applied across all sites (or a category of sites)? For example, I may want a persistent toolbar for quick actions across all pages -- essentially becoming a generic extension builder. Yes, if domain is https:/// it applies to all sites so you can think of this as a meta-extension builder. E.g. I have a timer script that applies across reddit, linkedin, twitter, etc. and keeps me focused.
> 5. Where and how are results being cached? For example, if I apply tweeks to a banking website, what content is being scraped and sent to an LLM? When I reload a site, is content being pulled purely from a local cache on my machine?
There is a distinction. When you generate a tweek, the page is captured and sent to an LLM. There is no way around this. You can't generate a modification for a site you cannot see.
The result of a generation is a static script that applies to the page across reloads (unless you disable it). When you apply a tweek, everything is local, there is no dynamic server communication.
Hopefully that is all helpful! I need to get to other replies, but I will try to return to finish up your business questions (those are the most boring anyway)
-- Edit: I'm back! --
> 6. Is this (or will it be) open source? IMO a large component of empowering the user against enshittification is open source. As compute commoditizes it will likely be open source that is the best hope for protection against the overlords.
It is very important to me that people trust us. I can say that we don't do X, Y, Z with your data and that using our product is safe, but trust is not freely given (nor should it be). We have a privacy policy, we have SOC II, and in theory, you could even download the extension and dig into the code yourself.
Open-source is one way to build trust. However, I also recognize that many of these "overlords" you speak of are happy to abuse their power. Who's to say that we don't open our code, only to have e.g. OpenAI fork it for their own browser? Of course, we could put restrictive licenses, but lawsuits haven't been particularly protective of copyright lately. I am interested in open-sourcing parts of our code (and there certainly is hunger for it in this post), but I am cognizant that there is a lot that goes into that decision.
> 7. What is your revenue model? If your product essentially wrestles control from site owners and reduces their optionality for revenue, your arbitrage is likely to be equal or less than the sum of site owners' loss (a potentially massive amount to be sure). It's unclear to me how you'd capture this value though, if open source.
The honest answer is TBD. I would push back on your claim that we wrestle control from site owners and reduce their optionality for revenue. While there likely will be users who say "hide this ad" (costing the site revenue) there are also users who say "move this sidbebar from left to right" or "I use {x} button all the time but it is hidden three menus in, place it prominently for easy access". I'd argue the latter cases are not negative for the site owners, they could be positive sum. Maybe we even see a trend that 80% of users make this UX modification on Z site. We could go to Z site and say, "Hey, you could probably make your users happy if you made this change". Maybe they'd even pay us for that insight?
Again, the honest answer is that I'm not certain about the business model. I am a lover of positive sum games. And in the moment, I am building something that I enjoy using and hopefully also provides value to others.
> 8. Interested in the cost and latency. If this essentially requires an LLM call for every website I visit, this will start to add up. Also curious if this means that my cost will scale with the efficiency of the sites I visit (i.e. do my costs scale with the size of the site's content).
As I noted above, this does not require an LLM call for every website you visit. You are correct that that would bankrupt us very quickly! An LLM is only involved when you actively start a generation/update request. There is still a cost and it does scale with the complexity of the site/request, but it is infinitely more feasible than running on every site.
In the future, we may extend functionality so that the core script that is generated can itself dynamically call LLMs on new page loads. That would enable you to do things like "filter political content from my feed" which requires test time LLM compute to dynamically categorize on each load (can't be hard-coded in a once-generated static script). That would likely have to be done locally (e.g. Google actually packages Gemini nano into the browser) for both cost and latency reasons. We're not there yet, and there is a lot you can do with the extension today, but there are definitely opportunities to build really cool stuff, way beyond Greasemonkey.
Wow, you really put me to work with this comment. Appreciate all the great questions!
So we built this to hopefully make browsing the web more enjoyable for us humans that remain :)
And I'm with you on Firefox. I'd love to be able to go back to Firefox as my daily driver. Will try to prioritize it!
We have standard data processing agreements with any and all LLM providers that we use. These include do not train/retain provisions (whether you trust them is another question entirely).
> Anything you make is or can become public. I would revisit this decision and prioritize keeping users' data private.
Totally valid. We haven't acted on this clause (scripts are not shared unless your yourself enable sharing) so probably best to remove it. To be clear though, your page data is your own. That will never be shared (not even you yourself can opt to share that because the privacy concerns are too great). The generated scripts are much safer (generally boils down to a bunch of static CSS selectors, styles, etc.). Nonetheless, a valid point.
> Also, I would encourage you to understand your technology, even your marketing site, to be able to add a link to Privacy Policy and ToS in the footer without the burden of "an entangled mess of state machine" and the risk of breaking anything. If the marketing site technology is outside the scope of your expertise, consider how much worse would a static page would be?
Fair comment, fwiw we did ship it in the footer already :) For the standard site, when the extension is installed, there are 6 steps. Each step dynamically progresses based on your install state (installed, pinned, permissions granted, first generation, etc.) We put a lot into the onboarding experience and it is pretty complicated (happy to geek out over the details!), but we hide all this if the extension isn't actively installed. Unfortunately, my blunder was that one of those steps that was hidden includes the privacy policy.
Thanks for all the feedback!
The limitation here is that the AI agent sees your page once and has to write a static script that applies generically.
What you're requesting would require an LLM call on every page request dynamically (rather than a static generated script) to categorize the content. It is possible and something we want to achieve, but we're not there quite yet.
Totally hear you on the permissions/access, and there isn't really a workaround:
In order for us to be able to execute your scripts that do powerful things (send notifications, save to local storage, download things, etc.), our extension needs to have those permissions itself.
I started off doing the same as you, having GPT to write scripts for me, and you can go a long way with that. I personally ran into the ceiling and felt I could build out a more robust solution, but it serves your needs well, by all means
We definitely could invest more in a flashy landing page, but we're early, and we've focused more on trying to build a product that is useful than one that is well-marketed. For Silicon Valley, we have our priorities reversed, but I enjoy the product building :)
For example:
Hate Google AI overviews? Delete them.
Tired of the slop on YouTube Shorts? Block shorts altogether.
Tired of going to a recipe site to find a simple recipe and getting hit with 1000+ trackers, more ads that you can imagine, and having to scroll 75% down the page to actually see the ingredients + recipe? Filter out the junk.
The potential is only limited by your creativity (and our models, but they're hopefully getting better everyday!)
I'm honestly not certain myself how we'll monetize this, but I have had a lot of fun building it and using it myself, and seeing how others use it. As you said, if we continue down this path without success, then worst case, what we built will still exist.
Re: local models, I am a big proponent, but they aren't there yet. This task is non-trivial. Try taking raw HTML from a webpage (minified, bundled, abstracted variable names, no comments, etc.) and using it as a basis to make useful edits. It's tough, and very impressive that any model can actually do it reasonably well. It tentatively looks like we're starting to reach a plateau for general models and open-weight is catching up, but I know the big labs/companies are aggressively capturing massive data and squeezing everything they can out of RL for more task-specific tuning. I hope open-weights can continue to compete!
These changes are the reason many of the existing userscript managers stopped working/being developed after MV3 went live. It is a real pain in the butt and unfortunately the functionality is not exactly the same between chrome and the generic browser API that firefox uses. There are a lot of edge cases that make everything even more of a pain.
Life would be much better (in many ways) if chrome didn't force MV3 down our throats.
Don't get me wrong, there are a lot more iterations of tool + prompt + agent flow updates we can and will do to make things even better, and the models will keep getting better themselves, but the task is non-trivial. If you download the raw HTML of a webpage, it's a messy jungle, and frankly impressive that the models are capable of doing anything useful with it
Edit: The site is an entangled mess of state machine and I don't want to break anything right now (+ I'm trying to keep up with all the comments + traffic) so I can just put it here for now: https://www.tweeks.io/privacy
We care a lot about privacy and tried to keep everything as minimal as possible. Definitely open to feedback here!
And if you don't want to use AI and just want to install other's scripts (with no sign up required), that is also totally valid and supported
> Think of us like Tampermonkey/some other userscript manager. The scripts you run have to go through our script engine. That means that any data/permission your script needs access to, our extension needs to have.
> We do try to make the scripting transparent. If you're familiar with the Greasemonkey API, we show you which permissions a given script requests (e.g. here https://www.tweeks.io/share/script/d856f07a2cb843c5bfa1b455, requires GM_addStyle)
So the permissions are either to 1) enable you to run scripts that can do many powerful things or 2) allow us to capture your active tab content if and only if you make a generation request (no passive logging).
To be fair, we're not sure about monetization either :) We just had a lot of fun building it and have enjoyed seeing what people make with it.
> It also requires access to all the data??
Think of us like Tampermonkey/some other userscript manager. The scripts you run have to go through our script engine. That means that any data/permission your script needs access to, our script needs access to. We do try to make the scripting transparent. If you're familiar with the Greasemonkey API, we show you which permissions a given script requests (e.g. here https://www.tweeks.io/share/script/d856f07a2cb843c5bfa1b455, requires GM_addStyle)