Show HN: Ferrite – Markdown editor in Rust with native Mermaid diagram rendering

This disclosure has been added today, after some users here called them out for hiding that they were using AI to build it.

Since you're an Obsidian user, can I please get your feedback on https://hyperclast.com/ which I'm building?

(I'm not quite ready to do a Show HN yet, so please don't post it, but I'm ready for some early feedback if you'll indulge me)

Thanks! The end-goal is a fast, native Markdown editor that "just works" - no Electron, no web tech, instant startup. v0.3.0 will extract Mermaid as a standalone crate and build a custom text editor widget to unlock features egui's TextEdit blocks (proper multi-cursor, code folding). Long-term: potentially extract the editor as a headless Rust library since that's missing in the ecosystem. See ROADMAP.md for details

What is Obsidian written in? Electron?

Wow, this looks awesome. Downloading now.

I missed this disclaimer about it being 100% AI-generated.

In one second I went from "looks cool" to "I don't want to touch it"

I'm trying to figure out why this post didn't get run out of town like several others recently, for starters it hit several favorite discussion topics.

You've basically described Ferrite's design goals! Let me check the boxes:

Single binary — ~15MB, point it at a directory with ferrite ./notes/ or open workspace via UI

Fast launch, low latency — Native Rust/egui, instant startup, no Electron

Cross platform — Windows/Linux/macOS

Tables & code blocks — GFM tables, syntax-highlighted code blocks (40+ languages)

WYSIWYG — This is where it gets nuanced. Ferrite has three modes:

- Rendered mode — Click-to-edit rendered Markdown (closest to WYSIWYG)

- Split view — Raw editor + live preview side-by-side

- Raw mode — Plain text editing

It's not pure "type and it formats inline" like Typora or Confluence. The Rendered mode lets you click elements to edit them, but it's not seamless WYSIWYG yet.

If you're looking for true inline WYSIWYG, Typora is probably closest. But if split view + rendered mode works for you, give Ferrite a try — it hits the other criteria well.

Good idea! A musl build would solve the glibc compatibility issues

Added to the v0.2.3 roadmap — will provide a statically-linked x86_64-unknown-linux-musl binary alongside the standard glibc one.

Great feedback, thank you! You're absolutely right — the screenshots are taken at high resolution, which makes them hard to read on smaller displays.

I'll retake them with a more focused window size and less dead space. Appreciate the specific guidance!

egui is fantastic for rapid prototyping - immediate mode makes state management simple. Main limitation: TextEdit isn't designed for code editors (no multi-cursor, can't hide folded text). v0.3.0 will replace it with a custom widget. The default styling does scream "egui" - spent time on custom theming to avoid that

> How did you find working with egui?

Claude Code would have preferred React.

Termimad author here: I’m always a bit afraid, when I see the popularity of this crate, that it might be undue and that people may lose time trying to use it when it’s probably not the tool they need.

Termimad isn’t a full-fledged TUI framework. It can be used to build TUIs (I made broot, bacon, safecloset, etc. with it), but if you want to quickly build a TUI and compose UI components and widgets, you’ll probably find it much easier to choose a real TUI framework (e.g. ratatui).

Termimad isn’t a generic Markdown viewer either. Markdown is mainly used as a language for the developer to describe parts of the interface—especially rich text—inside a TUI. People interested in rendering arbitrary Markdown files will find that it lacks features such as image rendering.

The $15 price tag for Typora seems a bit steep considering the fundamental features it provides.

+1 happy user of Typora. I really like its ability to auto-create a related assets folder for embedded media as it’s dragged into a doc.

Thanks! Typora is great - Ferrite aims for similar polish but with native Mermaid, structured data support (JSON/YAML/TOML tree viewer), and the pipeline feature for shell integration. And it's open source!

It's vibe coded. The entire project is only 10 commits, a few of them are giant with a bunch of markdown files full of emojis in the docs/ folder.

Fair point - I should be more transparent. Yes, Claude assisted significantly with development. The .gitignore excludes AI config files because they where not needed in the project and aren't useful to others. I'll add a note to the README about AI-assisted development. The code is reviewed and understood, not blindly accepted.

Good catch. For me its a red flag when the dev does not disclose AI usage

One major downside of native rendering is the lack of layout consistency if you’re editing natively and then sharing anywhere else where the diagram will be rendered by mermaid.js.

Valid point! Native rendering won't be pixel-perfect with mermaid.js. The trade-off is speed and no JS runtime. For documents staying in Ferrite, it's great. For sharing, we're adding SVG export in v0.3.0 so you can use mermaid.js for final renders if needed.

Ha! I appreciate the compliment (I think?). To be transparent: yes, AI tools were used during development — they're fantastic for boilerplate, documentation, and exploring unfamiliar APIs.

But this wasn't "2 sessions" — Ferrite has been in development for months with ~30,000 lines of Rust across 50+ modules. The Mermaid renderer alone is ~6000 lines of layout algorithms (Sugiyama-style graph layout, sequence diagram activation tracking, nested state machines, etc.).

AI helped ALOT, but there's no "generate full app" prompt that produces working text editors with native diagram rendering, rope-based text buffers, and custom window chrome. Still takes understanding the domain.

That said, you're right that the development velocity is higher than 5 years ago. Exciting times!

It can be vibe-coded quickly but can also be done rather quickly without ai - the heavy lifting is UI lib from Zed. That is the real unlock in apps like this.

Thanks for reporting! This is a packaging issue - need to create a proper .app bundle. On the roadmap for v0.3.0 (macOS signing & notarization). For now, running from terminal is the workaround.

This is exactly the plan for v0.3.0! Extracting the ~7000 line Mermaid renderer into a standalone crate with SVG/PNG output and CLI support. Pure Rust, WASM-compatible. Stay tuned!

Ferrite is privacy-focused in that it's fully offline — no telemetry, no cloud sync, no accounts, no network calls (even Mermaid diagrams render locally in pure Rust).

However, files are stored as plain text, same as Obsidian/VS Code/any text editor. Encryption at rest isn't currently on the roadmap.

For encrypted storage, you might consider: - Using Ferrite with an encrypted volume (VeraCrypt, LUKS, FileVault) - git-crypt for encrypted git repos

That said, if there's strong interest in built-in encryption (vault-style or file-level), I'd love to hear more about the use case. Would you want password-protected vaults? Per-file encryption? Something else?

This is why I prefer clunky hardware with heating cpus and a slow disk. You can easily feel that you wrote bad code from audio and tactile feedback.

Which view/file caused this? v0.2.2 (coming soon) has significant performance optimizations for large files - deferred syntax highlighting, galley caching. If you can reproduce, please open an issue with details!

Fair point about fragmentation! Ferrite uses Comrak which implements CommonMark + GitHub Flavored Markdown (GFM) — arguably the closest thing to a "standard" we have.

We chose Markdown because: - It's what most developers already use (README files, documentation, wikis) - Plain text files are portable, grep-able, git-friendly, and won't lock you in - GFM covers tables, task lists, strikethrough, and autolinks which handles 90% of use cases

We also support JSON, YAML, and TOML with native tree viewers. Wikilinks ([[links]]) and backlinks are planned for v0.3.0 for folks wanting Obsidian-style knowledge bases.

That said, I'd love to hear what format you'd prefer — always interested in expanding support!

This is one reason why I created TapirMD, which offers better specificity.

LaTeX support is a reasonable request! It's not on the immediate roadmap, but here's my thinking:

Options considered: - KaTeX/MathJax-style rendering (would need a Rust math renderer or JS bridge) - Typst integration (Rust-native, modern alternative to LaTeX) - External tool pipeline (render via pandoc/LaTeX CLI)

Typst is interesting since it's also Rust-based and simpler than full LaTeX. Would inline math ($x^2$) and display math ($$...$$) cover your use case, or do you need full document features?

Added to the roadmap consideration list. Thanks for the feedback!

Good question! A few reasons for egui over gtk-rs/iced/others:

- Immediate mode — egui redraws every frame, which makes state management simpler (no callback hell). Great for prototyping.

- Pure Rust, minimal deps — egui is self-contained. gtk-rs requires GTK installed on the system.

- Cross-platform out of the box — Same code runs on Windows/Linux/macOS/Web

- Rapid iteration — Hot reload-friendly, easy to experiment with layouts

Trade-offs: egui's TextEdit isn't designed for code editors (no multi-cursor, can't hide folded text), which is why v0.3.0 will replace it with a custom widget.

Interesting use case! Mermaid doesn't have native AWS icons, but for v0.3.0's standalone crate, we could potentially support custom shapes/icons. D2 has better icon support if you need that now.

What specific diagram types do you need — network topology, service flows, infrastructure layout?

Currently Mermaid doesn't support manual positioning — the layout is algorithmic (Sugiyama-style for flowcharts). Some workarounds: - Use subgraph blocks to cluster related nodes - Adjust edge order in source to influence layout - D2 (another diagram language) has better manual positioning

For v0.3.0's standalone crate, I'm considering whether to expose layout hints. What specific use case do you have — documentation, architecture diagrams?

Great catch! Mermaid styling syntax (style and classDef directives) is on the roadmap for v0.3.0. Currently the diagrams render with Ferrite's theme colors (light/dark).

For privacy, you're in the right place — Ferrite's Mermaid rendering is 100% native Rust, no JavaScript, no external services, no network calls. All ~6000 lines of diagram rendering happen locally. We're even planning to extract this as a standalone crate so others can use it.

Thanks for flagging this! You're right — Wooji-Juice's Ferrite is a well-known iOS audio recording app.

The name collision is unfortunate. We picked "Ferrite" for the magnetic/persistent storage connotation (ferrite cores were early computer memory). Different domain (text editor vs audio), different platforms (desktop vs iOS), but I understand the SEO/discoverability concern.

Open to suggestions if the community feels strongly about a rename! Though at this stage, with GitHub issues, releases, and now HN discussion, there's some established presence.

Definitely interested in the concept! Though it's not on the immediate roadmap.

A few thoughts: - Obsidian's plugin system is JavaScript-based, which makes sense for Electron. For a native Rust app, we'd likely want something like WASM plugins or Lua scripting. - v0.3.0 includes plans to extract the Mermaid renderer as a standalone crate and potentially the editor widget as a library — this modular architecture would be a foundation for future extensibility.

What kinds of plugins would you want? Knowing specific use cases would help prioritize. Custom renderers? File format converters? External tool integrations?

In the meantime, Ferrite has a "Live Pipeline" feature that lets you pipe JSON/YAML through shell commands (jq, yq, etc.) — not a full plugin system, but useful for custom transformations.

Thanks for reporting! This is a build environment issue - v0.2.1 was built on Ubuntu 24.04 which has newer glibc (2.39) and libssl3t64.

*Fix:* I've updated the CI to build on Ubuntu 22.04, which will make the .deb compatible with 22.04+.

This will be included in v0.2.2. For now, workarounds: 1. Use the `ferrite-linux-x64.tar.gz` (standalone binary) instead of .deb 2. Build from source: `cargo build --release`

Sorry for the inconvenience!

This is my only public Rust repo — I have some ongoing private projects in Rust, so I'm familiar with the ecosystem (cargo, crates, the borrow checker experience, etc.).

That said, to be fully transparent: as I disclosed elsewhere in this thread, the Ferrite codebase is 100% AI-generated (Claude via Cursor). I direct the development, test, and iterate, but I haven't written the Rust by hand for this project.

So my Rust experience is more "ecosystem familiarity + reading AI-generated code" than "battle-hardened Rustacean." This project is partly a learning exercise — seeing how far AI-assisted development can go while picking up Rust patterns along the way.

Not yet! [[wikilinks]] and backlinks are natural additions. I will add it to the Roadmap? Love community input on what Obsidian features matter most!

Yes! I was looking at it and hoping they had that feature already. I so want an Obsidian alternative to exist just in case.

Thanks for posting the GitHub issue!

And what's the connection with the thread?

> - ~15MB vs ~300MB+ (no Electron) > - Instant startup vs seconds > - Native Mermaid rendering (no extension juggling) > - Built-in JSON/YAML tree viewer with pipeline shell integration > - Session restore, minimap, zen mode baked in > > If you live in VS Code already, an extension might be fine. Ferrite is for those wanting a focused, fast Markdown environment.

Rust + Native App I take it

The VSCode markdown viewer kind of sucks tbh.

Interesting idea! Typst is compelling (Rust-based too). Not on immediate roadmap but could be a future addition. TeX is heavier but possible via external tools + pipeline feature.

Or even better, TeX. I realize capital bought out even basic typesetting but let's not encourage this

Looks like it’s currently a subset of mermaid natively in rust https://github.com/OlaProeis/Ferrite/blob/master/src/markdow...

(not associated, just looked at the code - no js interpreter)

https://github.com/OlaProeis/Ferrite/blob/master/src/markdow...

100% pure Rust! No JS interpreter. Parses Mermaid syntax directly and renders via egui drawing primitives. Supports 11 diagram types: flowchart, sequence, state, class, ER, pie, mindmap, timeline, user journey, git graph, gantt. Much faster than spawning headless Chrome!

Next time you're vibe coding something, have the system generate a mermaid diagram to show its understanding. Though visual generation can be hard for models, structure/topology in formats like mermaid is pretty gettable.

I've even found sonnet and opus to be quite capable of generating json describing nodes and edges. I had them generate directed acyclic processing graphs for a GUI LLM data flow editor that I built (also with Claude - https://nodecul.es/ if curious)