What Files.md Actually Is — and What It’s Quietly Challenging
Files.md is an open-source Markdown editor built for local-first personal knowledge management. It handles notes, journals, habit tracking, checklists, tasks, and project documents — all stored as plain .md files that never leave your device. The project has been in development for five years, built by a single developer, and is currently accessible in beta at app.files.md. No installation required. It runs entirely in the browser and works offline.
The privacy commitment is explicit and unconditional: no data is sent to a server, ever. That’s not a tier of a pricing plan or a toggle in settings — it’s the architecture. Your files stay on your machine because the software is designed around that constraint from the start.
Most coverage of new note-taking tools treats this kind of thing as a feature checkbox. Files.md treats it as a philosophical position. The GitHub repository states it plainly: “You should own your files, and the software that opens them.” That framing puts it in direct tension with cloud-locked tools that store your thinking on someone else’s infrastructure, accessible only through their interface, on their terms.
The app positions itself as a leaner alternative to Obsidian — intentionally so. Where Obsidian has grown into a plugin ecosystem with hundreds of community extensions, Files.md is built around deliberate restraint. The stated design principle is that restrictions foster creativity, and the codebase reflects that: simple enough for one person or an LLM to maintain and understand entirely.
The tool is also explicitly LLM-friendly, meaning your plain-text files are structured to work well with AI tools without routing your content through a third-party service to get there. You control the files. You choose which tools touch them.
What Files.md is quietly challenging isn’t just Obsidian or Notion — it’s the assumption that powerful personal software requires a company behind it, a sync server beneath it, and a subscription model holding it together.
The ‘Plain Text’ Bet: Why .md Files Are a Surprisingly Radical Choice
Markdown is 21 years old. Any text editor on any operating system opens it instantly. That longevity is the entire argument behind Files.md, a local-first notes tool built around the deceptively simple premise that your journal entries, project documents, and daily checklists should live in plain .md files on your own device — not in a database owned by a venture-backed company.
The contrast with tools like Notion is deliberate. Notion stores your data in proprietary cloud infrastructure. If Notion raises prices, gets acquired, or shuts down, extracting your knowledge becomes a fire drill. Files.md inverts that dependency entirely. Because every note is a standard .md file that never leaves your device, the application itself becomes optional. Lose the app, keep the files. Open them in VS Code, Obsidian, Notepad, or a terminal. Nothing breaks.
Files.md creator Zakirullin frames this not as a feature but as a philosophical position. The project’s tagline — “Both can last through the ages” — refers specifically to your knowledge and the software you use to access it. Most productivity app marketing promises you a better workflow today. This tagline promises your data will still be readable in 30 years. That’s a radically different value proposition, and it’s one Notion, Evernote, and similar cloud-locked tools cannot honestly make.
The durability argument has teeth because history backs it. Text files from the 1980s open fine today. Proprietary formats from that same era often don’t. Choosing .md is therefore less a technical preference and more an archival decision — the same logic archivists and librarians use when they favor open formats for long-term preservation.
What Files.md reveals is that the plain-text bet isn’t nostalgic minimalism. It’s a specific, defensible answer to a real risk: that the knowledge you build over a lifetime can be held hostage by a company’s survival, a subscription renewal, or an export format that quietly drops half your formatting. Owning your files means owning your thinking. The format just needs to be one that any computer, anywhere, can read without permission.
The LLM Angle Nobody Is Talking About
Plain text files are trivially easy to pipe into any LLM. Drop a folder of Markdown into Claude or GPT-4 and ask it to summarize your year, extract every open task, or reorganize your notes by theme. Try doing that with Notion’s proprietary database format or Roam’s EDN files. You can’t — at least not without exporting, converting, and hoping nothing breaks in translation.
Files.md markets itself explicitly as “LLM-friendly,” and that label is doing serious strategic work. It is not a feature. It is a architectural position. When your entire knowledge base lives in plain .md files on your own device, every AI tool ever built — present and future — can read it without permission from a vendor.
The project’s stated philosophy sharpens this further: “You grow your knowledge with your brain. You grow software around it with an LLM.” That sentence quietly dismantles the traditional product roadmap. Users no longer have to wait for Obsidian to ship a better calendar view or for Notion to add a feature that 4,000 people have upvoted for three years. With a codebase simple enough for one person to maintain, Files.md is designed so that a user and an LLM can extend it together — today, in an afternoon.
Most Obsidian-versus-alternatives coverage still judges apps on UI polish, plugin ecosystems, and sync reliability. Those comparisons are already obsolete. The real competitive question is whether your notes are legible to AI pipelines without friction. A beautifully designed app that locks knowledge into a proprietary schema actively degrades in value as LLM tooling matures. A folder of plain text files appreciates.
This is the dynamic that cloud-first incumbents cannot easily fix. Migrating a product’s data model to accommodate AI interoperability means rebuilding core architecture, not shipping a feature flag. Plain-text tools built this way from the start hold a structural advantage that no amount of product investment closes quickly.
The Trust Problem: Why ‘Open Source’ and ‘Local-First’ Matter More Than Ever
Trust is no longer a given in software — it has to be earned architecturally.
The supply-chain threat is real and accelerating. Attackers recently compromised element-data, a Python package pulling over one million monthly downloads, by exploiting a weakness in the developers’ account workflow to seize its signing keys. The hijacked version scoured infected machines for warehouse credentials, cloud provider keys, API tokens, and SSH keys before anyone noticed. It stayed live for roughly 12 hours — long enough to cause serious damage. The lesson is brutal: a package you trusted yesterday can be a credential-harvesting tool tomorrow, and download count offers zero protection.
Even well-resourced organisations running reputable open-source projects are not safe. Grafana Labs confirmed that hackers stole its source code after compromising a stolen GitHub token. The attackers then demanded a ransom to prevent releasing the codebase. Grafana refused to pay and invalidated the token, but the incident exposed the fragility of the authentication layer that guards most modern development pipelines. One stolen credential was all it took.
A Linux kernel vulnerability that exposed root-privileged files to unprivileged users reinforced a harder truth: being “secure by policy” is not enough. Architecture has to do the heavy lifting.
This is precisely where local-first tools like Files.md make a structural argument that no privacy policy can match. The app sends no data to a server. There is no server to breach, no GitHub token guarding a database of personal notes, no cloud storage bucket to misconfigure. The attack surface shrinks to the device in front of you. An attacker cannot exfiltrate what was never uploaded.
The Files.md codebase is intentionally kept small enough for a single person — or an LLM — to audit. That simplicity is a security feature. The more code a project carries, the more surface area exists for a supply-chain compromise to hide inside a dependency. When the software is minimal, open-source, and processes everything locally, the trust model becomes straightforward: read the code, run it offline, own the files. No intermediary required.
What Files.md Still Needs to Prove
Files.md carries the beta label for a reason, and that label represents real unfinished business. The app currently lives at app.files.md and runs entirely in the browser, which is elegant for onboarding but leaves the two questions power users ask first — reliable mobile access and a bulletproof sync workflow — without clear answers. Git and iCloud are obvious candidates for keeping files current across devices, but the project documentation does not specify how those pipelines behave under real daily use. Until they do, Files.md remains a promising experiment rather than a load-bearing tool.
The competitive gap with Obsidian is not a matter of philosophy — it is a matter of years. Obsidian has spent the better part of a decade accumulating a plugin ecosystem that now runs into the thousands, a graph view that visualizes relationships across an entire vault, and a community large enough to produce tutorials, templates, and third-party integrations at scale. Files.md, built by a single developer over five years, explicitly positions minimalism as a virtue. That is a coherent bet, but it does not make the feature gap disappear. Users who depend on Dataview queries, Templater automation, or community-built daily-note workflows will find nothing equivalent waiting for them.
The sharpest irony cuts at the project’s core identity. Files.md markets itself on the premise that you should own your files and the software that opens them. But open-source software is only as trustworthy as its supply chain. The element-data incident illustrates the problem precisely: a package with over one million monthly downloads was compromised when attackers exploited a vulnerability in the developers’ account workflow, gained access to signing keys, and pushed a malicious version that harvested SSH keys, API tokens, and cloud credentials before anyone caught it. The window was roughly twelve hours. As Files.md grows and its build pipeline accumulates dependencies, the same attack surface opens. A project whose entire pitch rests on privacy and local control cannot afford to treat supply-chain security as a future problem.
None of this disqualifies Files.md. It disqualifies complacency about what graduating from beta actually requires.
The Bigger Picture: Personal Knowledge as Infrastructure
Files.md is one data point in a shift that has been building for years. Developers and power users have started treating their personal knowledge base the way engineers treat critical infrastructure: versioned, portable, and owned outright — not licensed from a vendor who can change terms, raise prices, or shut down. The philosophy behind Files.md makes this explicit. “You should own your files, and the software that opens them,” the project states plainly. That is not a feature description. It is a political position about who controls your accumulated thinking.
The LLM angle accelerates everything. Plain-text Markdown files are natively readable by large language models. A user who has maintained a local archive of notes, journals, and project documents for five or ten years is sitting on a training-ready corpus of their own mind. Point a local or API-connected LLM at that archive and you get a genuinely personalised AI assistant — one that knows your actual projects, your actual decisions, your actual writing voice. Cloud-locked apps structurally cannot offer this. Their data lives in proprietary databases behind authentication walls, formatted for their own rendering engines, not for interoperability. Files.md describes the possibility directly: “You grow your knowledge with your brain. You grow software around it with an LLM. Both can last through the ages.”
For readers who do not follow developer tooling, the practical conclusion is blunt. The notes app you choose today is a decade-long bet. You are betting that the company behind it still exists, still operates on terms you accept, and has not been acquired, pivoted, or simply switched off. Evernote went from category-defining product to cautionary tale inside fifteen years. Google has killed more than two hundred products. Plain text stored locally carries none of that counterparty risk. A folder of Markdown files opened in Files.md today will open in any text editor in 2040 without any company’s permission.
The movement is not nostalgic. It is an infrastructure decision — the same logic that makes engineers prefer open standards over proprietary APIs. Personal knowledge is becoming too valuable, and too foundational to future AI workflows, to leave in someone else’s database.
