note.md - your notes and research documentation now a local LLM Memory
by•
A local-first research workspace for Mac. Read papers, manage sources, take markdown notes, cite evidence, and turn literature into structured writing — instead of juggling Zotero, Obsidian, PDF readers and writing apps.
Replies
note.md
@andreaigner Congrats on the launch! 🎉 Love the local-first approach, especially for research. Does note.md support importing existing notes from apps like Obsidian or Apple Notes?
note.md
@nicole_hynek Thank you so much!
Regarding your Question... Most of the current users I have been talking to, have been using Obsidian before. So as of now you can effortlessly connect your Obsidian vault to a project in note.md but we haven't explored any other options besides that and importing plain .md files yet.
@andreaigner Congrats on the launch! I'm using Obsidian right now but I need something like note.md instead -- great job!
@andreaigner @xichiwoo Me too, curious to hear how this product is different than apps like notion and obsidian and what the use cases are for it?
note.md
@mikereachium
Good question. Quick version: note.md is basically Obsidian + Zotero in one, with Notion's easy writing.
From Obsidian it takes the local Markdown vault and knowledge graph, but you write block-based like Notion instead of in raw Markdown syntax. From Zotero it takes the literature side — read your PDFs, manage sources and citations, pull figures and tables straight out of your papers into your notes.
Neither Notion nor Obsidian really does the source half — that's the gap it fills. Use case is research: anywhere reading papers and writing notes/citations should live in one place instead of four apps.
@andreaigner A local-first research workspace that combines note-taking, citations, and reading in one place is exactly what academic workflows are missing — most solutions make you jump between 3 or 4 apps to do what this does in one.
Two things I'm curious about: How granular are the privacy controls for the vault when it's used as AI agent memory? Local-first is a strong promise — curious whether that holds when the agent memory feature is active, or whether any data leaves the machine at that point.
And is there any plan for cross-platform support? macOS native is a solid foundation but a lot of researchers and students are on Windows or Linux.
note.md
@lingha_dharshan_anparasu
On privacy: the line is clean and worth being precise about. note.md's own AI features — source indexing, semantic search, figure extraction, evidence scan — all run fully on-device. Nothing leaves the machine, ever. That's the default and it's non-negotiable.
The agent-memory part is opt-in and separate. If you connect an external agent like Claude via the Filesystem connector, you're choosing to let a cloud model read those files — so at that point data does go to that provider, by definition, because that's where the model lives. note.md isn't sending anything; you're granting an agent access to a folder, and you control which folder and when. So the honest framing is: local-first by default and on its own, and you decide if and when an external agent is allowed in. The vault doesn't quietly phone home — you open the door.
On cross-platform: macOS-native is the foundation for now, mostly because the local AI pipeline is deeply tied to the Apple stack. Windows/Linux is the most-requested thing and very much on my radar — Fair to call it a real limitation today.
@andreaigner This is basically my daily setup, a markdown memory folder Claude reads every session, plain files, no lock-in. The thing nobody warns you about: reading the vault is the easy part, curation is the hard one. Stale notes are worse than none, the AI will confidently cite something that was true three weeks ago. How are you handling freshness, any notion of a note going out of date, or is pruning on me?
note.md
@david_marko
What I did, because I hit that same wall: I gave the agent a web-connection Skill and let it read the citation in each note, then back-check that source against public info — arXiv and similar — to see whether the claim still holds. The key move is the last filter: it only reports things that are out of date and aren't already flagged as historic. So it's not nagging me about old notes I kept on purpose; it's catching the silently-stale ones — the "true three weeks ago" case you described, where nothing in the vault itself contradicts it.
What made it work is the open-folder design plus the citations. Notes carry their source reference in plain Markdown, so the agent has something concrete to look up and verify against the outside world, rather than just reasoning over the vault in isolation. Librarian, not ghostwriter — it surfaces "this looks outdated, you didn't mark it historic," I decide.
Today it's a Cowork job I run on my own vault, not a one-click feature yet — but honestly that's the argument for the whole local/open approach: I didn't have to build a new feature for note.md, I just pointed an agent at plain files. Making it a first-class flow is high on my list.
It works fine for me, but I don't trust it blindly. My vault for my current project is not small, but also it is not that big that it's impossible to manually check if the agent workflow messed something up.
note.md
@luki_notlowkey
Great framing. Honestly all three matter, but if I had to name the sharpest edge: it's that note.md is local-first and yours, and that's the one thing NotebookLM can't follow me on without becoming a different product.
NotebookLM is genuinely great at Q&A over a set of sources, but it's a cloud silo you query, not a workspace you own. Your material lives on Google's servers, and the output is answers, not a body of work that accumulates. note.md inverts that: everything is plain Markdown in real folders on your machine, every AI feature runs on-device, and nothing leaves. Same reason it doubles as memory an agent like Claude can read and write directly, your vault is files, not someone's database.
The second edge follows from the first: it's a place you write, not just ask. NotebookLM answers questions; note.md is where reading, sourcing, and drafting compound into something that's still there, and still yours, a year later.
And a deliberate philosophical split: my AI is a librarian, not a ghostwriter. It surfaces what you've read and the evidence for and against your claims, rather than thinking for you. NotebookLM leans toward giving you the answer; I'd rather sharpen your own.
Foyer
The interesting tension here is that "local LLM memory" means very different things depending on how retrieval actually works. Are you chunking and embedding the markdown files so the model can do semantic search across them, or is it more like context stuffing where relevant notes get injected into the prompt window at query time? That distinction matters a lot for how well it handles a large, messy note library versus a small tidy one. Also curious whether note.md watches files for changes and updates the index automatically, or whether syncing is a manual step.
note.md
@fberrez1
For the notes themselves: we deliberately don't run our own embedding/retrieval layer over the vault. The Filesystem connector just exposes the folder as plain files — so the agent of choice does its own retrieval over them: reading, searching, pulling what it needs into context. We're not pre-chunking or injecting a vectorised note layer; whether it's closer to "smart search" or "context stuffing" is really up to the agent's own strategy on top of plain files. We chose that because it keeps the vault honestly just-files, with no hidden index the notes depend on — and because the agent is already good at navigating a real filesystem.
For the sources it's a whole other story — that's where the real on-device pipeline lives. When you import a PDF, we extract it locally, chunk it, and embed it, so semantic search runs as proper hybrid retrieval (meaning + keywords) across your whole source corpus, entirely on your machine. That's the part built to scale to a large, messy library — and it's also what powers the source indexing, figure/table extraction, and the evidence scan that finds support and contradictions for a claim. None of it touches a server.
@andreaigner Congrats on the update! 🚀 Keeping the vault as plain Markdown while opening it up to AI is literally a game changer here. I'd definitely try to hook this up to a local LLM.
Just for quick idea: what about .aignore file to easily hide sensitive drafts or keys from the AI's view?
note.md
@sakshi_raichand
Thank you for your support! I am personally a bit sceptic regarding .aiignore files. In git it's hardcoded that these files are being ignored, but the thing with agents is that the security layers can be lacking sometimes. So me personally I would just on the top level of the vault create one private and public folder and give the agent only access to the public folder and keep the sensitive files in the private one. So note.md can see everything but the agent has only access to the public folder
The local-first angle is what makes this interesting to me — most "AI memory" tools quietly ship your notes to someone's cloud. Quick question: is the LLM itself running locally too, or local storage + a cloud model? That distinction is the whole ballgame for anyone with notes they can't send off-device.
The local-first angle for note.md caught my eye, especially paired with markdown and research writing. How are you thinking about people moving existing .md files into the workspace — is it meant to work with an existing folder structure, or more as a dedicated place where notes and drafts live together?
note.md
@mia_qiao
Good question. both, by design. note.md works on plain folder of Markdown files, so you can point it at an existing vault and keep your structure as is. It reads your files, it doesn't reorganise them. The block editor just gives you a Notion-style way to write into those same .md files.
One honest caveat on citations: they are stored as standard Markdown links pointing at a notemd:// reference, so the file stays clean Markdown and your prose is fully portable but those citation links only resolve inside notemd, since they hook into the built-in reference manager.
The notes are yours and portable, but the live source link is the one app-specific piece.
The "cited memory with receipts" part is what actually matters, raw chat-history memory loses provenance and you can't tell later what's real. Keeping it as plain markdown on disk so any filesystem-capable agent can read it, not just Claude, is the right call too. The whole thing only works if the vault's genuinely clean though, that's the hard part. Solid update 🙏
Interesting one today! The "librarian not ghostwriter" line is the reason I'd try this, most of these tools fall over themselves to write for you instead:)
MedReport AI
Love the simple, no distractions approach with seemingly so many features that you progressively discover throughout exploring the app - feels very well thought out!
Also a heads up: tried using the `PRODUCTHUNT` code and kept running into this error. Any ideas as to why this could be?
Excited to give the full suite a try even if its only a limited free trial ((:
note.md
@adam_sardo
Ive back checked on the Offer Code and from what I am seeing it should still be active and non restricted. Maybe it was a temporary issue on the side of the AppStore Connect system.
If this does not resolve feel free to contact us on contact@arsoftware.tech ad we will provide you with a different code :)
There's a really interesting trust/transparency UX challenge here: when an LLM "remembers" from your notes, users need to understand the boundary between "this is my document" and "this is what the AI learned from it." The line gets blurry fast. Most knowledge tools either treat memory as a black box or overwhelm you with provenance metadata. How are you surfacing what's been indexed — especially for notes users might consider private?