Show HN: Eesel – Federated search without API integrations

Hey there! Amogh here from eesel (https://eesel.app https://eesel.app). eesel filters your browser history to show the docs you need for work, right in your new tab. You can see recent docs, filter by app or search by title or content. We're trying to solve a pretty universal problem. Everyone's work is spread across apps - there's a project brief in Google Docs, issues in Jira, a mockup in Figma, PRs in GitHub - and with this kind of sprawl, it can be a game of trial and error to find the links we need to do our job. Trying keywords in the address bar only works if we remember the title and it's specific enough, search in apps can be slow and noisy, company "knowledge hubs" in Confluence or Google Drive are usually not up to date, and we ultimately just ping each other on Slack to find things. I was struggling with this acutely as a PM at Intercom, and it felt ridiculous that I could search the web faster than my company's docs. It was around this time that I also discovered an Effective Altruism blog post on Operations (https://80000hours.org/articles/operations-management/ https://80000hours.org/articles/operations-management/) and how "maximising the productivity of others in the organisation" can have this multiplier effect for your own impact. That's when it clicked - here's an "operations" problem that felt tractable for my skills and I could potentially multiply my impact by solving it. This is what gave the conviction to prototype something on the weekends, and things spun off from there. Let's talk about the solution more. The magical thing about eesel is that we don't use APIs. When it comes to "search across apps", integrating with different APIs is a pretty default way to approach things. That's how we started, but things felt uneasy - could we really build API integrations with _everything_? There's so much out there, and this list is pretty much always changing. If we really did want a search across all work apps, we'd have to play catch up with old and new APIs. You could argue that these were just the schleps (http://www.paulgraham.com/schlep.html http://www.paulgraham.com/schlep.html) we had to overcome, but it was amidst this we realised that uh, the browser exists. We mostly work in the browser, and the great thing about it is that it's built on web standards. From HTTP and URLs to HTML and CSS, all apps in the browser follow the same predictable patterns: documents are accessed via URLs, content lives inside the HTML, there's a page title, there's a favicon, and so on. It's not a perfect replacement for APIs, but it felt good enough. We didn't need to manually integrate with each app, and could instead rely on existing web standards. And that's what we did. eesel works with any app in the browser, including apps without APIs (like that internal company tool), or apps that don't exist yet (the new Product Hunt hit). Not using APIs also meant that we could go an extra step with privacy - eesel works fully locally by default and you don't need to login to _anything_ (even eesel!). Simply install and it works. We want to keep building on this approach and improve how we work in the browser. For instance, eesel uses keywords to automatically organise pages into Folders, and there's Commands to take actions (spoiler: you can customise a JavaScript to inject on a page, like this script that goes to a Notion backlog and clicks the "New" button - https://eesel.notion.site/Notion-New-page-f10c7398209544088a0d9fee5dd1051c https://eesel.notion.site/Notion-New-page-f10c7398209544088a...). Alright, that's a lot of writing from us. We have a bunch of ideas, and would love to hear about where you think we should take this next.