Posted by OlaProis 1/11/2026
Built a Markdown editor using Rust + egui. v0.2.1 just dropped with major Mermaid improvements:
→ Native Mermaid diagrams - Flowcharts, sequence, state, ER, git graphs - pure Rust, no JS
→ Split view - Raw + rendered side-by-side with sync scrolling
→ Syntax highlighting - 40+ languages with large file optimization
→ JSON/YAML/TOML tree viewer - Structured editing with expand/collapse
→ Git integration - File tree shows modified/staged/untracked status
Also: minimap, zen mode, auto-save, session restore, code folding indicators.
~15MB binary, instant startup. Windows/Linux/macOS.
GitHub: https://github.com/OlaProeis/Ferrite
v0.2.2 coming soon with performance improvements for large files. Looking for feedback!
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.
Personally, I think there's two plugins I would really want.
1. Peer-to-peer syncing of notes. I do hope there will be a mobile version someday of your app. Most of my quick jotting of notes happens on mobile and heavy editing happens on traditional laptop/desktop. It would be nice just to scan a QR code to pair up devices and away we go. Optionally a small binary to be the sync server for self host for hub and spoke design. I love Git integration, but we want to take this at a level for those that aren't technically inclined.
2. A robust API for tool integration. Being able to plug in external tools is super helpful for streamlining workflows. In addition I've used it to make accessibility tools integrate for command and control.
I do like the fact that Obsidian has vaults that are essentially separate profiles that have separate vaults location settings and plugins.
For sync, I've been thinking about:
- Git-based sync for power users (already have git integration)
- Simple local network sync (mDNS discovery, no cloud required)
- Optional relay server, as you described — small binary for hub-and-spoke
The plain-file approach (no proprietary format) makes this tractable since any sync tool works today (Syncthing, Dropbox, etc.). But a native, frictionless solution would be better.
2. Tool Integration API
This aligns with v0.3.0's direction. The plan is:
- Mermaid crate extraction, establishes the modular pattern
- Editor widget as library, opens up embedding
- Command palette / IPC, could expose operations to external tools
For accessibility specifically, what interfaces work well for you? Shell commands? Named pipes? JSON-RPC? Knowing your workflow would help prioritize.
3. Vaults/Profiles
Good point — workspace settings are currently per-folder (`.ferrite/`), but there's no concept of isolated plugin configurations per vault. Added to the consideration list.
Thanks for the detailed feedback!
I recently switched from Obsidian to Zettlr due to some rendering and performance issues on Linux, and it's been a great experience. However, I always like to see new entrants in the arena.
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!
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.
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.
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?
The plan: use %% comments as layout hints. Something like:
%% @pos NodeA 100 200>
Mermaid.js ignores these, so the diagram stays portable. But Ferrite (and anyone using mermaid-rs) could parse them for manual positioning.
You'd be able to drag nodes around in Ferrite, have positions saved to the source, and still share with mermaid.js users (they'd get auto-layout).
If you want to follow progress or have input on the syntax, feel free to open an issue on the repo!
The challenge is Mermaid is declarative — layout is computed, not specified. Some options I'm considering:
1. layout hints/constraints in the syntax,
2. export to SVG then use a proper editor like Excalidraw for repositioning. For now, influencing layout via subgraphs and edge ordering is the best workaround."
3. separate system for that, maybe to be included in the crate, would only work in Ferrite in the start
*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!
Thanks for posting the GitHub issue!
On other systems I’ve run into challenges rendering markdown documents with many mermaid diagrams in them. It would be nice to have a more robust way to do this.
https://github.com/OlaProeis/Ferrite/blob/master/src/markdow...
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.