Launched this week
Deepmark
Search your bookmarks by what's inside them, not the title
105 followers
Search your bookmarks by what's inside them, not the title
105 followers
Your browser bookmarks, X bookmarks, Instagram saves and YouTube Watch Later, in one private library you can search in plain language. Deepmark reads every page, transcribes videos and reels, describes and OCRs frames, then embeds it all. 'The reel with the one-pan pasta trick' finds the reel even though nothing in it says pasta. A save is searchable in about 90 seconds; search over 10k items returns in under 100ms. Also a hosted MCP server: your AI agent can search your library too.
Payment Required
Launch Team / Built With
Deepmark
to answer the "what would you want it to do" question - I screen a lot of early-stage stuff and my saved links skew heavily toward pitch decks (usually a PDF link or a Google Slides/Docs link shared directly, not a public webpage) and X threads that are only visible if you're logged in and following the person. both of those are exactly the kind of content that a "fetch and read the page" approach struggles with, since there's either no public HTML to fetch or the content sits behind auth the extension isn't supposed to touch. is that kind of source on the roadmap, or is it intentionally staying scoped to publicly fetchable pages plus the four social sources you already support
Deepmark
@galdayan Yes those are current limitations. Are you talking about X subscriber only threads? that wouldn't be possible I guess. Maybe a local native solution we might need to build. Reach out at support@usedeepmark.com with you requirements so we can keep in roadmap. Thanks!
@shafuxyz makes sense that it stays out of scope for now, auth-gated content is a whole different can of worms. will send a note to that email if I run into it enough to actually need it, appreciate the honest answer instead of a vague "on the roadmap"
Deepmark
@galdayan One correction to my own answer: public PDF and slide links are a different problem from auth-gated threads, and a much smaller one. That half of your use case is worth building. The logged-in-only half genuinely is not.
The number I'd watch there is the 90 seconds, not the 100ms.
I run a search index over about 10 million chess games, and the thing that caught me out was that whatever you extract at ingest quietly becomes the ceiling on what's findable forever after. When I improved the extractor, everything ingested before that point was still described the old way, and the fix isn't a deploy, it's re-running ingest across the whole corpus.
At 90s an item, a 10k library is roughly ten days of wall clock to redo. So the thing I'd want it to do that it may not: keep the fetched source and the generated description as separate layers, so a better describer can be replayed over pages you already have instead of going back out to the internet. I didn't split those at first and paid for it twice.
Indexing the frames rather than the caption is clearly the right call though. 'The reel with the one-pan pasta trick' only resolves if the trick is the thing that got indexed.
Deepmark
@andrew_f3 That is the right thing to poke at, and it is the reason the fetched artifact and the generated description are stored as separate layers.
What comes off the internet is kept: the extracted page text, the page screenshot, and for a reel the pulled audio and the sampled frames. Transcripts, visual descriptions, OCR and embeddings are all derived from those stored artifacts. So a better describer or a better transcriber replays over what is already in storage instead of re-fetching. That matters twice over, because several of these sources would rather not be fetched again.
Two related pieces are already in: a reindex does not re-render a screenshot that already exists, and it fingerprints the re-fetched text, so an item that comes back byte identical skips enrichment and embedding entirely rather than re-billing for the same output.
Where you are right: forcing a full re-describe over the stored artifacts is an operator pass today, not a button. The artifacts are there so that stays cheap. The switch is not built yet.
On the 90 seconds, that is per-item latency, not a serial rate. Items run in parallel, so the redo window is a lot shorter than 90s times the library. But the shape of your warning holds, and it is why the artifacts get kept.
The "browser bookmarks (automatic)" part is what caught my eye - since it indexes everything you bookmark by default, is there a way to exclude specific bookmarks or folders from ever being fetched/embedded? Some bookmarks are things like internal work docs or personal stuff you'd want searchable locally but not sent through any pipeline at all, opt-out per source doesn't quite cover that.
Deepmark
@omri_ben_shoham1 Straight answer: not today. Browser bookmarks are all or nothing. The other three sources are off until you switch them on, but with the extension installed, a new browser bookmark is saved and indexed.
You are describing the right feature though, and it is not an architectural problem. The bookmark tree already gives us the folder path for every bookmark, so an exclusion list ("never touch anything under Work") is a filter in two places. A domain-level never-fetch list is the same shape.
Until that ships the honest options are keeping those bookmarks in a browser profile without the extension, or deleting the item afterwards.
Mail support@usedeepmark.com if you want it and I will tell you when the folder filter lands.
thanks for the detailed answer, that's a fair tradeoff and good to know it's not architecturally blocked. I'll hold off on adding those bookmarks until the folder filter ships, appreciate you following up.
Wow! I have a teammate who absolutely needs this. Sending it to him now.
For me, I'd like the ability to query across LinkedIn and Facebook saved items too!
Deepmark
@tori_seidenstein Thank you for passing it along.
LinkedIn saved posts and Facebook saved items are the same shape as the syncs that exist: the extension runs in your own browser as you, through the site's own endpoints, and each site stays off until you switch it on. Nothing in that model has to change for those two, so it is build-and-test work rather than a wall.
Neither is built yet and I might try these before for next release. Send a note to support@usedeepmark.com and I will tell you when it ships.
woow ! the pile of stuff I saved once and never saw again is enormous, and just knowing something finally tackles that gives me real hope
Deepmark
@amine_aziz_alaoui Same here.