SoloMD's install section says v4.0.0 and the latest release is v4.14.7

The install section says 4.0.0 and the newest release is 4.14.7

The install section opens by naming the latest release, and links it to the moving target rather than to a fixed tag. The label on that link says 4.0.0.

The release list tells a different story. The three most recent tags are 4.14.5, 4.14.6 and 4.14.7, and the last of those was published on the same day this was written. Three patch releases in three days is a fast cadence for a desktop application, which tells you something about how the project ships as well as about how its documentation ages.

The version number is not confined to that one label. The feature section is headed with what is new in 4.6, and the direct download links each carry a filename with 4.0.0 baked into it while pointing at the latest release path: a universal disk image, a Windows installer, and a portable archive.

A filename that encodes one version, served by a path that resolves to another, is a broken link the moment the next release ships. Anyone who copies the direct disk image URL out of the readme will get a 404 rather than a download.

The pattern is consistent across the readme, which suggests it was written once at the 4.0 release and edited around rather than revised. It is a small thing, and it is the kind of small thing that costs a first-time user an afternoon.

The code and the issue replies are both written by a model

There is a callout near the top of the readme that is more unusual than anything else in the file, and it deserves to be read rather than skimmed.

It says the project is written, tested and released almost entirely by a coding agent, working under a human maintainer who sets the direction and decides what ships. It says issues and pull requests are triaged and answered by the same agent, and that the replies you get are written by an AI rather than typed by a person.

Then it gives two reasons for saying so out loud. One is that you should know what you are trusting with your notes, and the answer to that is to read the code, because it is MIT licensed and all of it is public. The other is that when a reply is confidently wrong, which the text concedes happens, you should say so in the thread, and that correction is the mechanism.

That second reason is the interesting one. It reframes the issue tracker as part of the development loop rather than a support channel, and it asks users to audit replies the same way they would audit a diff.

For a notes application it is a real consideration rather than a curiosity. The vault is the one thing most people would not want mangled, which is why the frontmatter handling matters as much as the disclosure does.

No network port, path traversal guarded, and the example commits

The security claims are short and specific, and they are worth separating from the marketing around them.

The readme states that path traversal is guarded, that there is no network port, and that the model only sees what you point the workspace argument at. Those three together are the right shape for a local tool: no listener, an explicit root, and traversal checks on the root.

The bundled server also does not require the editor. The documentation says the server runs against any folder of markdown files, so you can drive a vault from an AI client without installing the application itself. That is the design decision that makes the tool useful as a bridge rather than as an editor with a plugin.

There is one thing to weigh against the security framing. One of the four documented ways to use it is to hand a prompt to a command line coding agent directly, and the example given asks the agent to rewrite a week of daily notes into a weekly review and commit it:

solomd agent "rewrite this week of dailies into a weekly review and commit it"

So the example is not a read. It rewrites content and invokes version control. Combined with the claim that git history stays on your machine, the agent has write access to your files and to your history, and the only boundary is which folder you named.

The same page documents the opposite direction, a command that prints the configuration snippet for an AI client, with the server binary invoked by absolute path and the vault passed as an argument. That is a two-line integration rather than a setup wizard, and it is also why the snippet has to be edited before it works, since the paths in it are examples.

Three of the install routes pipe a remote script into an interpreter

The install section is thorough, and the platform floor is argued rather than asserted.

macOS gets a package manager cask, a direct disk image, and a one-line shell installer that pipes a remote script into a shell. Windows gets an installer, a portable archive, a PowerShell one-liner that pipes a remote script into an interpreter, and a package manager entry. Linux gets three archive formats across two architectures plus an Arch user repository package. Mobile gets app store listings, including a tablet entry described as the same engine with a native interface.

Three routes therefore fetch a script from the vendor's own domain and execute it immediately, with no checksum in the command. That is the standard convenience trade, and the alternative routes in the same section are the reason it is not worse: a package manager cask, a signed disk image, a package manager entry for Windows, and a user repository package for Arch all leave a reviewable artefact.

The Windows floor is the best-reasoned paragraph in the file. Older Windows versions are excluded for two stated reasons: the toolchain the project builds with has required Windows 10 for a while now, and the rendering engine the application embeds was frozen by Microsoft on the old versions with no further security updates. It also notes that no legacy build exists, which closes the obvious question.

Linux is the quiet one: a system development package is needed at build time for keychain access, which is the kind of dependency that trips up a first source build.

The knowledge graph section is framed as catching up to two named editors

The most recent feature section is written as a gap being closed, and it names its comparators.

The framing is that the structural half that two named competitors had, and this project did not, is now built, on the project's own design system. So the structural work is positioned as parity rather than novelty.

What is in the list is genuinely the missing half of a notes app. A properties inspector for editing frontmatter with pickers for type, date, status and relations. A sidebar that turns a note's type into a first-class collapsible section, described as types as lenses. Typed relationships using three frontmatter keys with automatic inverses, resolved on the server for large vaults. A relationship explorer called Neighborhood, showing outgoing and inverse links per note, with click to navigate and a modified click to pivot. Saved sidebar views stored as files in a per-project directory, with a filter builder that combines conditions recursively over type, status, date and regular expressions. An inbox workflow with a mark-organised action that advances to an empty inbox.

The whiteboards are the interesting case. They are markdown-backed, stored behind a fenced block, and stated to be cross-compatible with a named competitor's on-disk format, and lazy-loaded so the core stays small.

Matching another tool's file format while competing with it is a deliberate strategy, and it means those boards will open in both applications.

The frontmatter writer promises to leave your comments alone

One line in the features list is worth pulling out on its own, because it addresses the failure mode that makes people stop trusting note editors.

The properties inspector is described as doing line-surgical writes, preserving comments, inline arrays and quoting byte-for-byte. That is a claim about a rewrite that changes only the keys you touched and leaves everything else exactly as written, including the parts a YAML round trip would normalise away.

YAML round trips are famously lossy in the ways that annoy: comments disappear, a quoted date comes back unquoted, a multi-line block reflows, a list changes shape. For a tool whose entire value proposition is that your files stay plain markdown you can open anywhere, a frontmatter writer that reformats the file is a data-loss bug even though no bytes of your prose were touched.

The typed relationships feature builds on the same assumption. Three frontmatter keys with automatic inverses, meaning writing one side of a relation is enough, and resolution happening server-side so a large vault does not stall the editor.

Server-side resolution is a real engineering decision with a real trade: the editor becomes a client of a local service for part of its behaviour, which sits oddly next to the claim that there is no network port. The two are compatible if the service is local-only, but the readme does not say which is which for this feature.

The size is quoted three different ways

How big the application is gets three different answers, and the spread is more than a rounding difference.

The repository description says about fifteen megabytes. The overview paragraph says the universal macOS disk image is about thirty-two megabytes. The feature section, which is describing the version that added the knowledge graph layer, says it is still about fifteen to thirty-two megabytes.

The fifteen figure is presumably the smaller platform build and the thirty-two the disk image, and quoting the range in the third place suggests the author knew the two numbers did not agree. The description is the one that gets read first, on the repository listing and in search results, and it is the one carrying the optimistic end of the range.

None of this matters much for a desktop application, where thirty-two megabytes is not a constraint anyone feels. It matters as a pattern, because the same document also disagrees with itself about the version number in three places, and the pair of them suggests a readme updated in patches rather than revised.

For a tool whose pitch includes being lighter than the alternatives, though, the size figure is doing some of the arguing. It would be better to state one number per platform.

Thirteen translated readmes and four distribution manifests

The repository root is large for a desktop application, and reading the entry list explains why.

There are fourteen readme files, one per language, all at the root. Each of them contains the same version numbers and the same download filenames, so the version drift described earlier exists fourteen times over, and fixing it means fourteen edits.

There are also separate directories for the app store submission, the mobile packaging, the Arch user repository package, the brand assets, the design icons, the development harness for the model protocol server, the distribution pipeline, the documentation, a F-Droid listing, an iOS shortcut, two marketing directories in two languages, a plugin marketplace directory, the model protocol server crate itself, the scripts, and a web clipper.

Four manifest files at the root point at plugin and server directories elsewhere in the tree, which means the project is distributed through at least three marketplace channels in addition to the release page, and there is a second code host mirror committed as a directory for faster downloads from one region.

Two things in that list are quietly notable. The project commits agent configuration directories, which means the tool ships instructions for the same agents it integrates with. And the end-to-end test entry point is a script named for a version family that has long since moved past its second digit, with flags for running it against a release build, a local model server, and the interface.

Editorial conclusion

SoloMD is for someone whose notes are already plain markdown files and who wants an assistant to read and write them without giving up a text editor. The parts that make it credible are the MIT licence with everything public, the no-server claim, the workspace flag that decides what the model can see, and a frontmatter writer that promises to leave your comments and quoting untouched. Two things to check before you point an agent at a vault. The documentation is behind: it names a version fourteen patch releases old, in three places, and the direct download links encode that old number, so use a package manager or the release page rather than the pasted URLs. And read the disclosure that the code and the issue replies are both written by a model, because for a tool you keep personal notes in, that is a fact you get to weigh rather than a footnote.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes