# marka.md lists signed updates as a feature and unsigned Windows as an install note

> A Tauri markdown editor built around one loop, collect notes, write, copy them out as an AI-ready bundle, with token counts shown before you copy. The privacy scoping is careful and the cross-platform story is unusually wide at seven artifacts. Three things do not line up: the signing claim, a roadmap three releases out of date, and a runtime dependency the documentation never mentions.

**mattenarle10/markamd** — local-first markdown editor with live preview, reading mode, diagrams, themes, and context bundles.

- Repository: https://github.com/mattenarle10/markamd
- Website: https://markamd.vercel.app
- Stars: 489 · Forks: 34
- Language: TypeScript
- License: MIT
- Published: 2026-09-20 · Updated: 2026-09-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/mattenarle10-markamd

## The feature table promises signed updates and the Windows note denies it

One of the five capability rows lists, among grouped themes, transparency controls, platform-aware shortcuts, session restore and external file watching, the item signed updates.

The Windows installation section says something incompatible with that:

```text
### Windows (10+, x64)
grab `marka.md_*-setup.exe` → run. Windows SmartScreen may ask for confirmation
because the Windows build is unsigned.
```

And the macOS section says the in-app signed updater still works alongside Homebrew, which locates signing on the Apple side specifically.

So the picture is that signed updates are a real capability and are scoped to at least macOS, while the Windows artifact is unsigned. What the feature table does is state the capability without the platform qualifier, in a table whose other rows are all cross-platform. A reader scanning that table and installing on Windows gets a worse answer than the table promised, and the qualification lives several sections down in an install note about SmartScreen.

This is the sort of thing that matters more than usual for an application that reads and writes your notes and can run a process on your machine. The Windows guidance does say what to expect, which is more than most projects say, and it does offer a Homebrew-style out-of-band updater on macOS as an alternative path. But the headline claim is unqualified and the caveat is not.

The wider picture on platforms is worth stating plainly, because only one of the three covers both architectures. macOS ships as a universal binary for Apple silicon and Intel. Windows is Windows 10 or later, x64 only. Linux is x86_64 only. So an ARM Windows machine has no build, and an ARM Linux machine has no build, while an Intel Mac does.

## The roadmap stops at 1.7.2 and skips six version numbers in the middle

The roadmap is a checked list of shipped versions, and it has two gaps.

The entries run 1.5 for the core loop, then 1.5.12 and 1.5.18 as polish, then 1.6.0 and 1.6.1 as workflow work, then 1.7.1, then 1.7.2 as a patch with its own release-notes document linked.

So between 1.6.1 and 1.7.1 there is nothing. No 1.6.2 through 1.7.0 entry exists.

And the shipped version is 1.7.5. The three most recent releases are 1.7.3, 1.7.4 and 1.7.5, published on 2026-09-01, 2026-09-14 and 2026-09-25. None of those three has a roadmap entry. The list is three releases behind and has a hole in the middle of it.

The reason is visible one line above the list, which says per-release detail lives on a changelog hosted on the project website. So the detail moved to the site and the README's copy of the list was left where it was. The result is two places for release information, neither of which is complete on its own: the website changelog has the recent history and the README has the intent, and the one document a reader is most likely to consult has silently stopped being accurate.

The open items are current, though. Two remain unchecked: native and silent PDF generation, and context handoff presets for bring-your-own-ai workflows starting with markdown and XML-tag bundle formats.

The PDF item is worth reading against the shipped feature list, which already claims mermaid-aware PDF export and stable print margins. So PDF export exists and native generation is the planned improvement to it. The phrase about print margins is the tell: what ships prints rather than writes a PDF, and the plan is to stop going through the printer.

## Six names for one app and four Linux packages for one binary

The naming is consistent within each channel and inconsistent across channels.

The repository is markamd. The package manifest name is marka-md, and the manifest is marked private so nothing is published to a registry. The heading on the page is marka.md. The website is markamd.vercel.app. The Homebrew cask is mattenarle10/tap/marka-md, in a personal third-party tap rather than homebrew-core. The AUR packages are markamd-appimage. The artifacts are marka.md.dmg, marka.md_intel.dmg, marka.md_*-setup.exe, marka.md_*.AppImage, marka.md_*_amd64.deb and marka.md-*.x86_64.rpm.

Every one of those has to be typed or searched for correctly, and the AUR name in particular shares nothing with the artifact it installs.

Linux is where the count is heaviest. One binary ships in four formats: a self-contained AppImage that needs only a chmod, a deb for Debian-family distributions, an rpm for the Red Hat family and openSUSE, and an AUR package that is itself the AppImage again. The AppImage, the deb and the rpm are the same program in three wrappers, and choosing between them is a distribution-packaging decision rather than a technical one.

macOS gets three paths for the same universal binary: the cask, the Apple silicon disk image, and a separate Intel disk image with an underscore-suffixed filename. The split into two images for one universal build is the one part of the matrix that looks like it could be simplified.

The install method is uniform though, and that is a real strength. Every platform section is a download and a single command or a drag, with no installer wizard and no runtime prerequisites. For anyone whose notes are already on disk, that is the shortest path from the website to an editor.

## The shortcut table's cross-platform rule breaks on its own fullscreen row

The keyboard section prints every binding with macOS modifiers and then gives one substitution rule for the other two platforms: command for Ctrl, option for Alt, shift for Shift.

That is a sensible way to present twenty bindings once instead of three times, and it covers almost everything. Twenty-one rows span opening files and folders, new buffers and tabs, save and save-as, sidebar toggle, direct tab switching by number, reading mode, editor-only mode, zoom from 50 to 300 percent with persistence, find and replace, find-next, undo of the last sidebar file operation, copy markdown to clipboard, PDF export, fullscreen, a help overlay, settings, and escape to close any popup.

One row does not follow the rule. Fullscreen is documented as the control key plus command plus F on macOS and as F11 on Windows and Linux. Under the stated substitution that row would become Ctrl plus F, which is not what it says. So the rule is an approximation, and the row that violates it is the one that also documents its own exception inline.

That is a minor thing on its own. It becomes worth noticing because of what it implies about the rest of the table. Everything else is a faithful one-to-one mapping of the same logical action onto different modifier keys, which means the author has verified the bindings rather than assumed them. The fullscreen row is the exception because fullscreen is genuinely not the same logical action on Windows and Linux, it is a distinct key the platform expects.

The zoom row is the other one to read carefully. Zooming the whole application from 50 to 300 percent and persisting the level is application chrome, not editor content, which is the kind of detail that a webview shell either does for free or does not do at all.

## The source path needs bun, rust and webkit development headers

The binary path and the source path differ by an order of magnitude in difficulty, and the README is honest about the second one.

Building from source requires bun, rust, and platform build tools, with the Linux case spelled out: install the WebKitGTK and libsoup development packages and the related Tauri dependencies. Then three commands:

```sh
bun install
bun run tauri dev      # native window with hmr
bun run tauri build    # produces .dmg / .exe / .AppImage / .deb / .rpm under src-tauri/target/release/bundle/
```

So a contributor needs a JavaScript runtime, a systems toolchain, and C development headers for a browser engine. On a Linux distribution that means installing WebKitGTK development packages before anything compiles, which is the step that turns a five-minute clone into an afternoon.

The output line is the useful part, because it confirms the seven-artifact count is produced by one build rather than seven. A single build command emits the macOS disk image, the Windows installer, the AppImage, the deb and the rpm, all under one bundle directory. Whoever is doing release packaging runs that once and publishes the results.

The editor's hot-reload path is worth noting as a developer affordance: the dev command gives a native window with hot module replacement, so the React and TypeScript layer iterates without a rebuild cycle.

Everything above the native layer is ordinary. A React frontend on Vite, CodeMirror 6 with the markdown language and search extensions, markdown-it with mark and task-list plugins, Shiki for highlighting with its themes and grammars loaded lazily, and Mermaid loaded lazily as well. Styling is CSS variables with no framework, and icons come from a single icon package. Nothing in the web layer is exotic; the complexity budget was spent on the native shell.

## One runtime dependency is undocumented and it is the one that touches a network

The manifest declares twenty-six runtime dependencies. Twenty-five of them map onto something in the documentation: the CodeMirror packages, the Tauri API and its five plugins, the markdown parser and its two plugins, Shiki, Mermaid, React and React DOM, the icon set, the translation runtime, the two bundled fonts, and the Vite build tooling on the development side.

One does not. The dependency list includes a PlantUML encoder, and the string appears nowhere in the feature table, the stack table, the roadmap or the privacy section.

That matters more than an ordinary undocumented dependency, because of what the library is for. A PlantUML encoder turns diagram source into a compressed identifier that a rendering server turns into a diagram. Unlike every other dependency here, its function involves contacting something outside the machine when the result is followed.

The privacy section makes a specific and carefully worded claim: local-first, no telemetry, no accounts, no cloud sync, files stay on disk, and clipboard transfers happen only when you copy. The one-line summary above the feature table goes further and says nothing leaves your machine until you copy.

Those two statements can both be true of an editor that never fetches a PlantUML image, and they are true of an editor that embeds one as a link. The documentation does not say which one this is, because it does not mention the dependency. So this is the one item to check against the source before trusting the claim, and it is checkable: find where the encoder is called and see whether the result is rendered locally, embedded as a remote image, or written out as a link.

The lazy loading is the other thing worth noting. Both the highlighter and the diagram renderer load on demand, which is the right call for both, since a highlighter needs a grammar and theme per language and a diagram renderer is a large bundle that most notes never need.

## Token counts are shown before you copy, with no tokenizer named

The feature that distinguishes this editor from a generic one is the context tray, and the specific detail that makes it useful is a count.

You stage files from the sidebar, and the tray shows file counts and token counts, and then you copy one bundle with relative paths. The two other routes to the same output are a keyboard shortcut to copy markdown and a command-palette entry for copying the context bundle.

The token count is the part with a gap. Nothing in the documentation says which tokenizer produces it, which model's context window it is being compared against, or how the number is rounded. Token counts differ substantially between tokenizer families, so a figure that is accurate for one provider can mislead for another. Displaying it is clearly more useful than not displaying it, and the tray also shows per-file counts so you can see which note is the expensive one, which is the actionable half of the feature.

The relative paths are the other detail. Making them relative rather than absolute is what makes a copied bundle portable, since the recipient can drop it into a similar folder structure. The documentation does not describe what happens to those paths when the recipient's layout differs, so a bundle assembled on one machine and pasted into a conversation that an agent then acts on depends on the agent's working directory.

The list of targets is unversioned prose: it works with Claude, ChatGPT, Gemini, local agents, and anything that reads plain markdown. No model names, no versions, no indication of what was actually tested. That is honest phrasing for a clipboard workflow, since the output is plain text and any model can read it, but it does mean there is no compatibility claim to check.

The two planned roadmap items both extend this area: context handoff presets, and XML-tag bundle formats as an alternative to markdown.

## No changelog file, a stale roadmap, and a privacy notice that scopes itself

Three closing observations about how the project documents itself.

The repository has no changelog file. The tree contains a release checklist under docs, a release-notes document for one specific patch, a security policy, a contribution guide, an agent-instructions file and a shared editor configuration. The changelog itself is a page on the website, and the roadmap section of the README exists only to list versions up to 1.7.2 while the shipped version is 1.7.5. So release history is split across a website page and a documentation subdirectory, with no single file that a tool could read.

The privacy notice, by contrast, is the best-scoped claim in the document. The app-level promise is specific: no telemetry, no accounts, no cloud sync, files stay on disk, clipboard transfers only when you copy. And then it discloses that the website itself runs Vercel Speed Insights, described as cookieless, with a link to the full notice. A marketing page claiming nothing leaves your machine is technically untrue of the marketing page, and this one says so itself.

The fonts are worth noticing for the same reason. Inter and JetBrains Mono are both installed as package dependencies rather than loaded from a font CDN, which is what a local-first claim requires in practice and is the kind of detail that is easy to get wrong in a webview application.

The remaining funding and governance signals are all present and unremarkable: a personal third-party Homebrew tap, an AUR package maintained separately, an Open Collective link in the page header, MIT licensing, and a contributing section that asks for one behaviour change per pull request, screenshots for interface changes, copy updates when the user-facing surface moves, and a specific three-command check before opening one.

The last push was 2026-09-28, four days before 2026-10-02, so the branch is current.

## Conclusion

Use marka.md if your workflow is writing notes and then handing them to a model by clipboard, since that loop is what the token counts and the relative-path bundle are built for, and the fonts are bundled rather than fetched. Do not rely on the signing claim until you check which platform you are on, because the Windows installer is documented as unsigned while signed updates appear unqualified in the feature table. Verify first that the plan-uml encoder dependency does not send diagram source anywhere, since it is the one runtime dependency whose purpose involves a remote service and the documentation is silent on it.

## FAQ

### What is marka.md and what is the context tray for?

It is a Tauri-based markdown editor for macOS, Windows and Linux built around a collect, write, share loop. The context tray is the AI-specific part: you stage files from the sidebar, see file and token counts, and copy a single bundle with relative paths ready to paste into a conversation.

### Is the marka.md Windows build signed?

No. The Windows section states the Windows build is unsigned, which is why SmartScreen may ask for confirmation, and it requires Windows 10 or later on x64. The feature table nonetheless lists signed updates among desktop polish without a platform qualifier, while the macOS section says the signed in-app updater works there.

### How do I install marka.md on Linux?

Four ways, all x86_64: an AppImage that needs only chmod plus and runs self-contained, a deb via dpkg for Debian-family distributions, an rpm via dnf for the Red Hat family and openSUSE, or an AUR package which is the AppImage again. Windows is a single unsigned setup executable and macOS ships a universal disk image plus a third-party Homebrew cask.

### What do I need to build marka.md from source?

bun, rust and platform build tools, plus the WebKitGTK and libsoup development packages on Linux. Then bun install, bun run tauri dev for a native window with hot module replacement, or bun run tauri build, which produces the disk image, installer, AppImage, deb and rpm under the Rust bundle directory.

### Does marka.md send anything to a server?

The privacy section claims no telemetry, no accounts and no cloud sync, with clipboard transfers only when you copy, and separately discloses that the project website runs cookieless speed analytics. One runtime dependency, a PlantUML encoder, is not mentioned anywhere in the documentation, and it is the only dependency whose function involves an external rendering service, so it is the item to check against the local-first claim.

## Sources

- [License: MIT](https://github.com/mattenarle10/markamd/blob/main/LICENSE)
- [mattenarle10/markamd on GitHub](https://github.com/mattenarle10/markamd)
- [Project website](https://markamd.vercel.app)
- [README](https://github.com/mattenarle10/markamd/blob/main/README.md)
- [Releases](https://github.com/mattenarle10/markamd/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mattenarle10-markamd