15 ms·

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

241 points by OlaProis 9mo ago

Ferrite: Fast Markdown/Text/Code editor in Rust with native Mermaid diagrams 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 https://github.com/OlaProeis/Ferrite v0.2.2 coming soon with performance improvements for large files. Looking for feedback!

pbronez 9mo ago
Is mermaid rendering implemented in Rust, or are you running mermaid.js in a JS interpreter somewhere? 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.
- lkschubert8 9mo ago
  Looks like it’s currently a subset of mermaid natively in rust https://github.com/OlaProeis/Ferrite/blob/master/src/markdown/mermaid.rs https://github.com/OlaProeis/Ferrite/blob/master/src/markdow...
- jasonjmcghee 9mo ago
  (not associated, just looked at the code - no js interpreter) https://github.com/OlaProeis/Ferrite/blob/master/src/markdown/mermaid.rs https://github.com/OlaProeis/Ferrite/blob/master/src/markdow...
- OlaProis 9mo ago
  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!
Arubis 9mo ago
I happily paid money for Typora, which does roughly the same thing for just Markdown without support for JSON, Yaml (that I know of). This feels like a ripe space, especially with LLMs eagerly outputting reams of parseable text with embedded diagrams.
- vunderba 9mo ago
  +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.
  - danfoxley 9mo ago
    I like the editor, but Typora’s lineage is opaque, which worries me.
- gregman1 9mo ago
  The $15 price tag for Typora seems a bit steep considering the fundamental features it provides.
  - swiftcoder 9mo ago
    The price of a fancy burger doesn't seem all that unreasonable for a piece of software one finds even moderately useful (of course, depending on your local exchange rate that may be more or less true)
  - zen928 9mo ago
    Sometimes you're a patron of the arts more than an engineer on these types of purchases, I think
- OlaProis 9mo ago
  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!
huevosabio 9mo ago
Nice to see an egui project that doesn't have super obvious egui aesthetics. How did you find working with egui?
- koakuma-chan 9mo ago
  > How did you find working with egui? Claude Code would have preferred React.
  - GrowingSideways 9mo ago
    How would this have worked outside of catering to browsers?
    - steezeburger 9mo ago
      You can render React all over the place now!
  - echelon 9mo ago
    Native code and speed will be a differentiator. If the value of JavaScript programming goes down, Rust programming will probably hold value a little bit longer.
- OlaProis 9mo ago
  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
Levitating 9mo ago
Made with egui, if anyones wondering. I love the new era of graphical applications in Rust.
khimaros 9mo ago
seems like a promising alternative to obsidian, but missing [[wikilinks]] and back references
- bthallplz 9mo ago
  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!
- OlaProis 9mo ago
  Not yet! [[wikilinks]] and backlinks are natural additions. I will add it to the Roadmap? Love community input on what Obsidian features matter most!
adamnemecek 9mo ago
Consider adding support for Typst.
- GrowingSideways 9mo ago
  Or even better, TeX. I realize capital bought out even basic typesetting but let's not encourage this
  - regenschutz 9mo ago
    Typst is open-source.
    - GrowingSideways 9mo ago
      Open source doesn't mean relinquished from capital by any means. I also don't blame the author of typst. But TeX is truly free from capital, and that should mean far more than the aesthetics of a nicer interface.
      - adamnemecek 9mo ago
        Integration with typst will be more straightforward than latex.
        GrowingSideways 9mo ago
        Yes, at the cost of dragging people into subscription software. Fuck off
        adamnemecek 9mo ago
        How?
- OlaProis 9mo ago
  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.
dhruv3006 9mo ago
Building an api client based on markdown as well - https://voiden.md https://voiden.md
- random3 9mo ago
  And what's the connection with the thread?
dmitrygr 9mo ago
For those who, like me, read this and thought "what the hell is a mermaid diagram?", apparently it is a method to describe simple flow diagrams using markdown-like text. More here: https://mermaid.js.org/ https://mermaid.js.org/
- chaboud 9mo ago
  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/ https://nodecul.es/ if curious)
WillAdams 9mo ago
Made the fan in my Windows 11 laptop spin up.
- nurettin 9mo ago
  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.
  - corysama 9mo ago
    I’ve heard of people doing ambient performance profiling by instrumenting their code to insert clicks into an audio buffer based on a high precision clock and piping it out a speaker. You get to learn the sound of your code at 44.1KHz
    - vunderba 9mo ago
      This might be the most absurdly terrific thing I’ve read in a while - like a profiler equivalent of a Geiger counter.
      - bschwindHN 9mo ago
        We did something like that for a hiring project once: https://github.com/tonarino/acoustic_profiler https://github.com/tonarino/acoustic_profiler
      - 4k93n2 9mo ago
        *vibe coding sounds* "3.6 roentgen. not great, not terrible"
- OlaProis 9mo ago
  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!
bananaboy 9mo ago
Nice to see native markdown rendering rather than relying on spawning chromium and taking screenshots like some other libraries do!
- quintu5 9mo ago
  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.
  - bananaboy 9mo ago
    Yes that's true. For my use-case I want to render the diagram out to a png though and embed it in a confluence page.
    - OlaProis 9mo ago
      This is a perfect use case! The v0.3.0 crate will have: - parse() → AST - layout() → positioned elements - render_svg() → SVG string - render_png() → via resvg (no browser needed) CLI usage would be something like: mermaid-rs diagram.mmd -o diagram.png> # or pipe from stdin> cat diagram.mmd | mermaid-rs --format svg > output.svg> For your mark integration, you'd be able to call it as a subprocess or use it as a Rust library directly if you're building in Rust. If you want to follow progress or have input on the API, feel free to open an issue on the repo!
- OlaProis 9mo ago
  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.
random3 9mo ago
This is cool. I was hoping to see progress coming from Zed (e.g. because Tree-sitter → https://github.com/tree-sitter-grammars/tree-sitter-markdown https://github.com/tree-sitter-grammars/tree-sitter-markdown) but it's exciting to see this. I'm a heavy Obsidian user, and I love it, but I'd love to see real alternatives focused on foundations. It would be interesting to know more about the end-goal if any. Best of luck! I'll watch this.
- echelon 9mo ago
  What is Obsidian written in? Electron?
  - atlintots 9mo ago
    Yes; it's also not open source.
    - echelon 9mo ago
      I'm fine with that. Open source purity is problematic. The OSI was established by the hyperscalers, who are decidedly not open source either. Purely "OSI-approved open source" mandates having no non-commercial or non-compete clause, which means anyone can come in and bleed off profits and energy from the core contributors of open source projects. It prevents most forms of healthy companies from existing on top. We shouldn't be allergic to making money with the software we write - life is finite and it's more sustainable over the long term to maintain software as a job. The new "ethical source" / "fair source" licenses that have been popping up recently [1, 2] give customers 100% use of the code, but prevent competitors from coming in and stealing away the profits from running managed offerings, etc. (I wish Obsidian were this, but it's fully closed. Still, I do not admire them any less for this choice. We venerate plenty of closed creators - it's silly to hold software to a different standard.) AWS profits hundreds of millions a quarter off of open source developed by companies thinking they were doing the right thing. AWS turned these into a proprietary managed solutions and gave nothing back to the authors. The original wind up withering and dying. AWS isn't giving back, they're just hoovering up. Obsidian being closed means the core authors are hyper focused and can be compensated (even if it's not much). It's not like they can rug pull us - the files are text files, we can use old versions, and if they did piss us off I'm sure someone would write an open source version. [1] https://fair.io/ https://fair.io/ [2] https://faircode.io/ https://faircode.io/
fuddle 9mo ago
Whats the advantage of using Ferrite versus VS Code with a Mermaid extension?
- dcreater 9mo ago
  Rust + Native App I take it
- littlestymaar 9mo ago
  The VSCode markdown viewer kind of sucks tbh.
- OlaProis 9mo ago
  > - ~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.
  - fuddle 9mo ago
    Thanks. It might be worth highlighting this in the Readme.
FloatArtifact 9mo ago
Any interest in a plugin system similar to Obsidian?
- OlaProis 9mo ago
  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.
  - FloatArtifact 9mo ago
    > 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. 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.
silcoon 9mo ago
Why did you remove AI agent configurations and instructions from the repo? See .gitignore
- dcreater 9mo ago
  Good catch. For me its a red flag when the dev does not disclose AI usage
- WD-42 9mo ago
  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.
- OlaProis 9mo ago
  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.
  - Bishonen88 9mo ago
    Could you estimate how much was written by AI vs you? Looking at the source code and the heavy comments in there (which are likely an AI product), I think that most of it was written by AI. Same with the whole docs directory. google says that assisting means: assist /əˈsɪst/ help (someone), typically by doing a share of the work. So in this case... wouldn't the relationship be inverted, e.g. you assisting AI? (semi joking ;))
    - OlaProis 9mo ago
      You're right to push on this, let me be fully transparent. 100% of the code was generated by AI (Claude Opus 4.5(I am super impressed by the capabilities of Opus 4.5), via Cursor with MCP tools). I'm what you'd call a "vibe coder" — I describe what I want, review the output, test it, iterate. I haven't written Rust by hand for this project. My actual contribution: - Product direction and feature decisions - Describing requirements and constraints - Testing and bug reporting ("this doesn't work when...") - Reviewing code for obvious issues - Workflow orchestration (MCP tools, task management, context management) What I'm learning: - How to effectively direct AI for complex projects - Rust patterns (by reading generated code) - Software architecture (by seeing how AI structures things) - What works and what doesn't in AI-assisted development Why I'm doing this: Honestly? To learn and experiment. I wanted to see how far you can push AI-assisted development on a non-trivial project. Ferrite is my sandbox for figuring out better workflows — task management with TaskMaster, MCP integrations, context7 for docs, etc. Is this "real" software development? I don't know. It's definitely a new paradigm. The code compiles, runs, and does useful things. Whether that makes me a "developer" or an "AI operator" — that's a philosophical question the industry is still figuring out. The documentation and comments being AI-heavy was a fair tell. I probably should have been upfront about this from the start.
sean_pedersen 9mo ago
Like the idea but it spawns a terminal on startup on Mac and is not WYSIWYG (like Obsidian). Hope this project develops into usable state soon.
- OlaProis 9mo ago
  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.
msephton 9mo ago
Will need a magnifying glass to see the text on the screenshots. I find it makes sense to take screenshots in a window big enough to show what's going on, but no bigger. This means probably not full screen, or maximised, especially if you're running at a very high resolution. If there's a lot of dead/empty space in the window that's a signal it's too big. This way you guarantee the screenshots are readable without zooming in, on smaller displays than your own, for example mobile.
- OlaProis 9mo ago
  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!
  - msephton 9mo ago
    My pleasure! Thank you for being receptive and open minded to such constructive criticism.
listic 9mo ago
Doesn't install on Ubuntu 22.04 LTS due to dependecy problems. Filed a bug: https://github.com/OlaProeis/Ferrite/issues/6 https://github.com/OlaProeis/Ferrite/issues/6
- OlaProis 9mo ago
  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!
maximgeorge 9mo ago
[dead]
Bishonen88 9mo ago
Looking at the Screenshots, this would've taken days/weeks e.g. 5 years ago. Now this seems to be vibe coded in 2 sessions. Crazy world we live in.
- OlaProis 9mo ago
  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!
  - risyachka 9mo ago
    Yep, it always seems easy from the outside until you start doing it. Then unless you are doing a crud web app you quickly run into issues where unless you know what you are doing- Claude Code won’t help you.
    - OlaProis 9mo ago
      Exactly. The AI is great at "write me a function that does X" or "convert this to async." It struggles with: - Graph layout algorithms (crossing minimization, layer assignment) - State machine interactions (how does undo interact with sync scroll when switching view modes?) - Performance debugging (why is syntax highlighting slow on scroll?) The domain knowledge still matters. AI just compresses the boilerplate time.
  - password4321 9mo ago
    I want to see the work done by human beings, not just the AI output. "Open source" to me is sharing the input required, idealistically as much as possible. Without including at least prompts and separating AI output from manual revisions this GitHub repo feels more like publishing "open weights" does, definitely useful but for the most part only for its intended purpose instead of also teaching how to do something similar myself. (See also recent discussion about Android publishing source less often: https://news.ycombinator.com/item?id=46524379 https://news.ycombinator.com/item?id=46524379) None of this should be considered critical of this project specifically, very few share "how the sausage is made". You're breaking new ground with a comment about being AI generated prominent in the README, I hope that catches on.
_flux 9mo ago
Seems like Mermaid parsing and layout would be a useful crate as by itself. I would enjoy a fast mermaid layout command line tool with svg/pdf/png support, which I think would be quite feasible to implement with such a crate.
- OlaProis 9mo ago
  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!
  - bananaboy 9mo ago
    That's great! I'm pretty interested in that. I hooked up `mark` [1] at work to upload md files to our internal confluence and would love to integrate a native tool to convert Mermaid diagrams to a png rather using mark's built-in system which calls out to mermaid.js and thus needs us to vendor chromium, which I'd rather avoid! [1] https://github.com/kovetskiy/mark https://github.com/kovetskiy/mark
mgaunard 9mo ago
The main issue is that Markdown remains a pretty primitive language to write documents in, with dozens of incompatible extensions all over the place. I don't know if it's the best format to focus on.
- OlaProis 9mo ago
  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!
  - mgaunard 9mo ago
    asciidoc or rst/sphinx, are tools which are much better suited to build software documentation with cross-references etc.
    - OlaProis 9mo ago
      AsciiDoc and RST/Sphinx are definitely more powerful for structured documentation with cross-references, includes, and admonitions. For now Ferrite is focused on Markdown since that's the most common format for notes and quick docs. But the architecture could support other formats — the parser layer is modular. If there's demand, AsciiDoc would be the easier addition (cleaner syntax than RST). Would be curious how many folks would use it as their primary format vs. Markdown.
- tapirl 9mo ago
  This is one reason why I created TapirMD, which offers better specificity.
k_bx 9mo ago
We need privacy-focused Obsidian alternative (which doesn't store unencrypted text files on disk), excited to see a potential player written in my tech stack, meaning it should be easy to extend!
- OlaProis 9mo ago
  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?
  - k_bx 9mo ago
    I want cold storage encryption which is cross-platform and doesn't require FUSE and such. Current solutions are all either non-cross-platform or overkill, so I'm still using Obsidian non-encrypted. It's a matter of default and ease of use. That said, I've checked Ferrite out – unfortunately there's a very long way to go before it becomes Obsidian-ish (left and right panel, add tabs, hide the top formatting bar), better focus on those features. If it becomes close enough – I'll implement the encryption myself :)
    - OlaProis 9mo ago
      Fair feedback! You're right — Ferrite isn't Obsidian-complete. Those are reasonable additions: - Left panel already exists (file tree + outline), but could use polish - Right panel (backlinks?) would come with v0.3.0 wikilinks work - Hiding toolbar is a quick settings addition — I'll add that to the list What's your priority order for those? And if you do implement encryption later, I'd love to see the approach!
nico_h 9mo ago
It’s a cool name but there is already another project called ferrite, related to audio recording. https://www.wooji-juice.com/products/ferrite/ https://www.wooji-juice.com/products/ferrite/
- OlaProis 9mo ago
  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.
napoleongl 9mo ago
Looks interesting! I’m discouraged from using mermaid and D2’s online playground for privacy reasons and have hand on my roadmap to get a local editor. This might be it! Does it support theming of mermaid diagrams, I noted the style keywords were in the roadmap still.
- OlaProis 9mo ago
  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.
nkmnz 9mo ago
Slightly off topic: is there any editor (and data format) that supports re-arranging mermaid charts? I often find myself wanting to slightly tweak the way the chart is rendered, e.g. moving around boxes so that some of them are clustered in a specific area etc.
- OlaProis 9mo ago
  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?
  - nkmnz 9mo ago
    Mostly clustering and sorting, but most importantly, I use diagrams not only as a tool for communication, but also as a tool to think visually. Moving boxes around would be a huge benefit for that use case, while I still want to have the diagram as code for version control etc pp
    - OlaProis 9mo ago
      Visual thinking use case makes sense! 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
    - OlaProis 9mo ago
      Actually, this is going on the v0.3.0 roadmap. I've been looking for ways to make the standalone mermaid-rs crate genuinely better than just 'mermaid.js but Rust.' 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!
bovermyer 9mo ago
Very cool. The one thing that prevents me from trying this out as a potential note-taking daily driver is the lack of support for LaTeX. 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.
- OlaProis 9mo ago
  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!
  - bovermyer 9mo ago
    I only need inline+display math, I don't need the full document features.
    - OlaProis 9mo ago
      Good to know! Inline + display math is a more tractable scope. Typst or a Rust KaTeX port could handle that without needing full LaTeX. Added to the consideration list with that clarification.
- fmichel42 9mo ago
  Agreed. Having an open-source alternative to (the otherwise excellent) Typora would be fantastic; as far as I can tell the main feature Ferrite is currently lacking to be used for most (all?) applications where I use Typora is a way to easily write and render maths formula. (As far as I am concerned, support for TeX math would be ideal due to wide support from the existing ecosystem; but Typst would work too.)
endorphine 9mo ago
Hey OP, curious how much experience you have with Rust, given that this is the only rust repo I see in your profile.
- OlaProis 9mo ago
  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.
deviation 9mo ago
AI generated code, AI generated HN post, AI generated comments…
- djvdq 9mo ago
  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"
  - JCattheATM 9mo ago
    Why? It's not like LLMs can't generate solid code, and it's not like people don't guide them carefully to produce the code they want. I guess you're assuming he just gave a simple prompt to build an app that wasn't checked in any way, but why?
    - djvdq 9mo ago
      Then you are assuming it wrong. I just don't like AI generated stuff, that's it
      - JCattheATM 9mo ago
        So you have an irrational anti-progress bias. OK.
        AlexeyBelov 9mo ago
        Let's not disingenuously put words in people's mouths. What if the bias is rational? What if it's not "anti-progress" but something else?
        JCattheATM 9mo ago
        I'm not putting words in anyone's mouth, I'm stating my conclusion. What else would the bias be? AI is a useful tool, to blanket 'not like' anything generated by AI seems ludditesque.
rkagerer 9mo ago
> Platform Note: Ferrite has been primarily developed and tested on Windows. While it should work on Linux and macOS, these platforms have not been extensively tested. Neat! Lately on Windows I've felt like a 2nd class citizen. > AI Disclosure: This project is 100% AI-generated code. Oh. Well, at least they're up front about it.
- dystroy 9mo ago
  This disclosure has been added today, after some users here called them out for hiding that they were using AI to build it.
  - rkagerer 9mo ago
    Thanks for clarifying. That deflates the last of any excitement I had about this. Moving on...
OlaProis 9mo ago
v0.2.2 just released — addressing several issues raised in this thread: - CJK font support 1 — Korean/Chinese/Japanese characters now render properly - CLI improvements (#9, #10) — ferrite file.md now works, plus --version and --help flags - Undo/redo fixes 2 — Fixed scroll reset and focus issues - Default view mode setting 3 — Can now set split/preview as default - Configurable log level 4 — Reduce stderr noise - Ubuntu 22.04 compatibility 5 — .deb now works on 22.04+ Thanks to everyone who reported issues! Download: https://github.com/OlaProeis/Ferrite/releases/tag/v0.2.2 https://github.com/OlaProeis/Ferrite/releases/tag/v0.2.2
rajatkulk 9mo ago
Shamelessly plugging my app Octarine (https://octarine.app https://octarine.app) for users that may want a more WYSIWYG editing experience while storing all notes on device in markdown, which is also written in Rust (Tauri), and NOT vibe coded :)
- weakfish 9mo ago
  Wow, this looks awesome. Downloading now.
  - rajatkulk 9mo ago
    Thank you! Open to any and all feedback!
cat-whisperer 9mo ago
I don't know much about the GUI space. I would love your take on why did you went with egui instead of guirs
- OlaProis 9mo ago
  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.
cat-whisperer 9mo ago
also, on the markdown front, I saw this cool library https://github.com/Canop/termimad https://github.com/Canop/termimad gaining popularity
- dystroy 9mo ago
  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.
hendry 9mo ago
Wish there was something like Mermaid for typical AWS Architecture diagrams. Something that doesn't suck like draw.io!
- OlaProis 9mo ago
  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?
  - hendry 9mo ago
    More service flows aimed at security audits
    - OlaProis 9mo ago
      Service flows for security audits — that's a specific and useful use case! A few thoughts: What might work today: - Sequence diagrams can model service-to-service flows (API calls, auth handoffs) - Flowcharts with subgraphs can represent VPC boundaries, security groups - C4-style (context, container, component) is sometimes modeled with flowcharts What would make it better: - Custom shapes/icons (AWS service icons) - Annotations for security boundaries, trust zones - Data flow direction markers Alternative you might try now: D2 (https://d2lang.com https://d2lang.com) has better icon support and was designed for architecture diagrams. It has an AWS icon pack. Structurizr also does C4 well. That said, if there's demand for architecture-specific diagrams in Ferrite's Mermaid renderer, I could look at: 1. Custom icon/shape support via external SVGs 2. A dedicated "architecture" diagram type with security-relevant annotations Would a template or example for modeling security flows in Mermaid's current syntax help as a starting point?
      - hendry 9mo ago
        Yeah, an example would be good. Tbh the examples on https://d2lang.com/ https://d2lang.com/ don't seem to fit the bill of a typical AWS Architecture diagrams! https://aws.amazon.com/architecture/reference-architecture-diagrams/ https://aws.amazon.com/architecture/reference-architecture-d...
kmfrk 9mo ago
Markdown and Mermaid support, you have my attention!
mickdarling 9mo ago
This looks cool! And, to add to the list of shameless plugs for OSS markdown editors/renderers With mermaid support, I will add mine to the list: https://merview.com https://merview.com with full source code at https://github.com/mickdarling/merview https://github.com/mickdarling/merview
porjo 9mo ago
I don't want to diminish the effort put into this project, but it's a reminder to me of just how many markdown editors there are out there! And yet I'm still searching for the holy grail: - wysiwyg editor (not live preview) - simplicity: single binary that can be pointed at a directory of markdown files - fast launch time, low latency UI - cross platform - comes with basic 'extras' like tables & code block support I actually really like the Confluence editor experience. If I could get that in an FOSS 'offline' package, my needs would be met.
- OlaProis 9mo ago
  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.
JCattheATM 9mo ago
Would you maybe consider adding a musl version to your releases?
- OlaProis 9mo ago
  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.
  - JCattheATM 9mo ago
    Thanks, I'll look forward to trying it then :)
    - OlaProis 9mo ago
      I tried to add it for this release but hit a wall with the font rendering dependencies (freetype, fontconfig). GUI apps need these for text display, and they don't play well with fully static musl linking - the build system wants a musl C++ cross-compiler and static versions of system libraries that aren't readily available in CI. We'll keep looking into options - possibly a Docker-based build with a proper musl toolchain, or investigating if we can make fontconfig use dlopen at runtime. For now the glibc build (Ubuntu 22.04) should run on most Linux distros. If anyone has experience with static musl builds for Rust GUI apps, we'd love to hear what's worked!

241 points by OlaProis 9mo ago

pbronez 9mo ago

Is mermaid rendering implemented in Rust, or are you running mermaid.js in a JS interpreter somewhere? 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.

lkschubert8 9mo ago
Looks like it’s currently a subset of mermaid natively in rust https://github.com/OlaProeis/Ferrite/blob/master/src/markdown/mermaid.rs https://github.com/OlaProeis/Ferrite/blob/master/src/markdow...
jasonjmcghee 9mo ago
(not associated, just looked at the code - no js interpreter) https://github.com/OlaProeis/Ferrite/blob/master/src/markdown/mermaid.rs https://github.com/OlaProeis/Ferrite/blob/master/src/markdow...
OlaProis 9mo ago
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!

Arubis 9mo ago

I happily paid money for Typora, which does roughly the same thing for just Markdown without support for JSON, Yaml (that I know of). This feels like a ripe space, especially with LLMs eagerly outputting reams of parseable text with embedded diagrams.

vunderba 9mo ago
+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.
- danfoxley 9mo ago
  I like the editor, but Typora’s lineage is opaque, which worries me.
gregman1 9mo ago
The $15 price tag for Typora seems a bit steep considering the fundamental features it provides.
- swiftcoder 9mo ago
  The price of a fancy burger doesn't seem all that unreasonable for a piece of software one finds even moderately useful (of course, depending on your local exchange rate that may be more or less true)
- zen928 9mo ago
  Sometimes you're a patron of the arts more than an engineer on these types of purchases, I think
OlaProis 9mo ago
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!

huevosabio 9mo ago

Nice to see an egui project that doesn't have super obvious egui aesthetics. How did you find working with egui?

koakuma-chan 9mo ago
> How did you find working with egui? Claude Code would have preferred React.
- GrowingSideways 9mo ago
  How would this have worked outside of catering to browsers?
  - steezeburger 9mo ago
    You can render React all over the place now!
- echelon 9mo ago
  Native code and speed will be a differentiator. If the value of JavaScript programming goes down, Rust programming will probably hold value a little bit longer.
OlaProis 9mo ago
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

Levitating 9mo ago

Made with egui, if anyones wondering. I love the new era of graphical applications in Rust.

khimaros 9mo ago

seems like a promising alternative to obsidian, but missing [[wikilinks]] and back references

bthallplz 9mo ago
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!
OlaProis 9mo ago
Not yet! [[wikilinks]] and backlinks are natural additions. I will add it to the Roadmap? Love community input on what Obsidian features matter most!

adamnemecek 9mo ago

Consider adding support for Typst.

GrowingSideways 9mo ago
Or even better, TeX. I realize capital bought out even basic typesetting but let's not encourage this
- regenschutz 9mo ago
  Typst is open-source.
  - GrowingSideways 9mo ago
    Open source doesn't mean relinquished from capital by any means. I also don't blame the author of typst. But TeX is truly free from capital, and that should mean far more than the aesthetics of a nicer interface.
    - adamnemecek 9mo ago
      Integration with typst will be more straightforward than latex.
      - GrowingSideways 9mo ago
        Yes, at the cost of dragging people into subscription software. Fuck off
        adamnemecek 9mo ago
        How?
OlaProis 9mo ago
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.

dhruv3006 9mo ago

Building an api client based on markdown as well - https://voiden.md https://voiden.md

random3 9mo ago
And what's the connection with the thread?

dmitrygr 9mo ago

For those who, like me, read this and thought "what the hell is a mermaid diagram?", apparently it is a method to describe simple flow diagrams using markdown-like text. More here: https://mermaid.js.org/ https://mermaid.js.org/

chaboud 9mo ago
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/ https://nodecul.es/ if curious)

WillAdams 9mo ago

Made the fan in my Windows 11 laptop spin up.

nurettin 9mo ago
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.
- corysama 9mo ago
  I’ve heard of people doing ambient performance profiling by instrumenting their code to insert clicks into an audio buffer based on a high precision clock and piping it out a speaker. You get to learn the sound of your code at 44.1KHz
  - vunderba 9mo ago
    This might be the most absurdly terrific thing I’ve read in a while - like a profiler equivalent of a Geiger counter.
    - bschwindHN 9mo ago
      We did something like that for a hiring project once: https://github.com/tonarino/acoustic_profiler https://github.com/tonarino/acoustic_profiler
    - 4k93n2 9mo ago
      *vibe coding sounds* "3.6 roentgen. not great, not terrible"
OlaProis 9mo ago
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!

bananaboy 9mo ago

Nice to see native markdown rendering rather than relying on spawning chromium and taking screenshots like some other libraries do!

quintu5 9mo ago
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.
- bananaboy 9mo ago
  Yes that's true. For my use-case I want to render the diagram out to a png though and embed it in a confluence page.
  - OlaProis 9mo ago
    This is a perfect use case! The v0.3.0 crate will have: - parse() → AST - layout() → positioned elements - render_svg() → SVG string - render_png() → via resvg (no browser needed) CLI usage would be something like: mermaid-rs diagram.mmd -o diagram.png> # or pipe from stdin> cat diagram.mmd | mermaid-rs --format svg > output.svg> For your mark integration, you'd be able to call it as a subprocess or use it as a Rust library directly if you're building in Rust. If you want to follow progress or have input on the API, feel free to open an issue on the repo!
OlaProis 9mo ago
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.

random3 9mo ago

This is cool. I was hoping to see progress coming from Zed (e.g. because Tree-sitter → https://github.com/tree-sitter-grammars/tree-sitter-markdown https://github.com/tree-sitter-grammars/tree-sitter-markdown) but it's exciting to see this. I'm a heavy Obsidian user, and I love it, but I'd love to see real alternatives focused on foundations. It would be interesting to know more about the end-goal if any. Best of luck! I'll watch this.

echelon 9mo ago
What is Obsidian written in? Electron?
- atlintots 9mo ago
  Yes; it's also not open source.
  - echelon 9mo ago
    I'm fine with that. Open source purity is problematic. The OSI was established by the hyperscalers, who are decidedly not open source either. Purely "OSI-approved open source" mandates having no non-commercial or non-compete clause, which means anyone can come in and bleed off profits and energy from the core contributors of open source projects. It prevents most forms of healthy companies from existing on top. We shouldn't be allergic to making money with the software we write - life is finite and it's more sustainable over the long term to maintain software as a job. The new "ethical source" / "fair source" licenses that have been popping up recently [1, 2] give customers 100% use of the code, but prevent competitors from coming in and stealing away the profits from running managed offerings, etc. (I wish Obsidian were this, but it's fully closed. Still, I do not admire them any less for this choice. We venerate plenty of closed creators - it's silly to hold software to a different standard.) AWS profits hundreds of millions a quarter off of open source developed by companies thinking they were doing the right thing. AWS turned these into a proprietary managed solutions and gave nothing back to the authors. The original wind up withering and dying. AWS isn't giving back, they're just hoovering up. Obsidian being closed means the core authors are hyper focused and can be compensated (even if it's not much). It's not like they can rug pull us - the files are text files, we can use old versions, and if they did piss us off I'm sure someone would write an open source version. [1] https://fair.io/ https://fair.io/ [2] https://faircode.io/ https://faircode.io/

fuddle 9mo ago

Whats the advantage of using Ferrite versus VS Code with a Mermaid extension?

dcreater 9mo ago
Rust + Native App I take it
littlestymaar 9mo ago
The VSCode markdown viewer kind of sucks tbh.
OlaProis 9mo ago
> - ~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.
- fuddle 9mo ago
  Thanks. It might be worth highlighting this in the Readme.

FloatArtifact 9mo ago

Any interest in a plugin system similar to Obsidian?

OlaProis 9mo ago
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.
- FloatArtifact 9mo ago
  > 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. 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.

silcoon 9mo ago

Why did you remove AI agent configurations and instructions from the repo? See .gitignore

dcreater 9mo ago
Good catch. For me its a red flag when the dev does not disclose AI usage
WD-42 9mo ago
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.
OlaProis 9mo ago
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.
- Bishonen88 9mo ago
  Could you estimate how much was written by AI vs you? Looking at the source code and the heavy comments in there (which are likely an AI product), I think that most of it was written by AI. Same with the whole docs directory. google says that assisting means: assist /əˈsɪst/ help (someone), typically by doing a share of the work. So in this case... wouldn't the relationship be inverted, e.g. you assisting AI? (semi joking ;))
  - OlaProis 9mo ago
    You're right to push on this, let me be fully transparent. 100% of the code was generated by AI (Claude Opus 4.5(I am super impressed by the capabilities of Opus 4.5), via Cursor with MCP tools). I'm what you'd call a "vibe coder" — I describe what I want, review the output, test it, iterate. I haven't written Rust by hand for this project. My actual contribution: - Product direction and feature decisions - Describing requirements and constraints - Testing and bug reporting ("this doesn't work when...") - Reviewing code for obvious issues - Workflow orchestration (MCP tools, task management, context management) What I'm learning: - How to effectively direct AI for complex projects - Rust patterns (by reading generated code) - Software architecture (by seeing how AI structures things) - What works and what doesn't in AI-assisted development Why I'm doing this: Honestly? To learn and experiment. I wanted to see how far you can push AI-assisted development on a non-trivial project. Ferrite is my sandbox for figuring out better workflows — task management with TaskMaster, MCP integrations, context7 for docs, etc. Is this "real" software development? I don't know. It's definitely a new paradigm. The code compiles, runs, and does useful things. Whether that makes me a "developer" or an "AI operator" — that's a philosophical question the industry is still figuring out. The documentation and comments being AI-heavy was a fair tell. I probably should have been upfront about this from the start.

sean_pedersen 9mo ago

Like the idea but it spawns a terminal on startup on Mac and is not WYSIWYG (like Obsidian). Hope this project develops into usable state soon.

OlaProis 9mo ago
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.

msephton 9mo ago

Will need a magnifying glass to see the text on the screenshots. I find it makes sense to take screenshots in a window big enough to show what's going on, but no bigger. This means probably not full screen, or maximised, especially if you're running at a very high resolution. If there's a lot of dead/empty space in the window that's a signal it's too big. This way you guarantee the screenshots are readable without zooming in, on smaller displays than your own, for example mobile.

OlaProis 9mo ago
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!
- msephton 9mo ago
  My pleasure! Thank you for being receptive and open minded to such constructive criticism.

listic 9mo ago

Doesn't install on Ubuntu 22.04 LTS due to dependecy problems. Filed a bug: https://github.com/OlaProeis/Ferrite/issues/6 https://github.com/OlaProeis/Ferrite/issues/6

OlaProis 9mo ago
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!

maximgeorge 9mo ago

[dead]

Bishonen88 9mo ago

Looking at the Screenshots, this would've taken days/weeks e.g. 5 years ago. Now this seems to be vibe coded in 2 sessions. Crazy world we live in.

OlaProis 9mo ago
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!
- risyachka 9mo ago
  Yep, it always seems easy from the outside until you start doing it. Then unless you are doing a crud web app you quickly run into issues where unless you know what you are doing- Claude Code won’t help you.
  - OlaProis 9mo ago
    Exactly. The AI is great at "write me a function that does X" or "convert this to async." It struggles with: - Graph layout algorithms (crossing minimization, layer assignment) - State machine interactions (how does undo interact with sync scroll when switching view modes?) - Performance debugging (why is syntax highlighting slow on scroll?) The domain knowledge still matters. AI just compresses the boilerplate time.
- password4321 9mo ago
  I want to see the work done by human beings, not just the AI output. "Open source" to me is sharing the input required, idealistically as much as possible. Without including at least prompts and separating AI output from manual revisions this GitHub repo feels more like publishing "open weights" does, definitely useful but for the most part only for its intended purpose instead of also teaching how to do something similar myself. (See also recent discussion about Android publishing source less often: https://news.ycombinator.com/item?id=46524379 https://news.ycombinator.com/item?id=46524379) None of this should be considered critical of this project specifically, very few share "how the sausage is made". You're breaking new ground with a comment about being AI generated prominent in the README, I hope that catches on.

_flux 9mo ago

Seems like Mermaid parsing and layout would be a useful crate as by itself. I would enjoy a fast mermaid layout command line tool with svg/pdf/png support, which I think would be quite feasible to implement with such a crate.

OlaProis 9mo ago
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!
- bananaboy 9mo ago
  That's great! I'm pretty interested in that. I hooked up `mark` [1] at work to upload md files to our internal confluence and would love to integrate a native tool to convert Mermaid diagrams to a png rather using mark's built-in system which calls out to mermaid.js and thus needs us to vendor chromium, which I'd rather avoid! [1] https://github.com/kovetskiy/mark https://github.com/kovetskiy/mark

mgaunard 9mo ago

The main issue is that Markdown remains a pretty primitive language to write documents in, with dozens of incompatible extensions all over the place. I don't know if it's the best format to focus on.

OlaProis 9mo ago
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!
- mgaunard 9mo ago
  asciidoc or rst/sphinx, are tools which are much better suited to build software documentation with cross-references etc.
  - OlaProis 9mo ago
    AsciiDoc and RST/Sphinx are definitely more powerful for structured documentation with cross-references, includes, and admonitions. For now Ferrite is focused on Markdown since that's the most common format for notes and quick docs. But the architecture could support other formats — the parser layer is modular. If there's demand, AsciiDoc would be the easier addition (cleaner syntax than RST). Would be curious how many folks would use it as their primary format vs. Markdown.
tapirl 9mo ago
This is one reason why I created TapirMD, which offers better specificity.

k_bx 9mo ago

We need privacy-focused Obsidian alternative (which doesn't store unencrypted text files on disk), excited to see a potential player written in my tech stack, meaning it should be easy to extend!

OlaProis 9mo ago
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?
- k_bx 9mo ago
  I want cold storage encryption which is cross-platform and doesn't require FUSE and such. Current solutions are all either non-cross-platform or overkill, so I'm still using Obsidian non-encrypted. It's a matter of default and ease of use. That said, I've checked Ferrite out – unfortunately there's a very long way to go before it becomes Obsidian-ish (left and right panel, add tabs, hide the top formatting bar), better focus on those features. If it becomes close enough – I'll implement the encryption myself :)
  - OlaProis 9mo ago
    Fair feedback! You're right — Ferrite isn't Obsidian-complete. Those are reasonable additions: - Left panel already exists (file tree + outline), but could use polish - Right panel (backlinks?) would come with v0.3.0 wikilinks work - Hiding toolbar is a quick settings addition — I'll add that to the list What's your priority order for those? And if you do implement encryption later, I'd love to see the approach!

nico_h 9mo ago

It’s a cool name but there is already another project called ferrite, related to audio recording. https://www.wooji-juice.com/products/ferrite/ https://www.wooji-juice.com/products/ferrite/

OlaProis 9mo ago
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.

napoleongl 9mo ago

Looks interesting! I’m discouraged from using mermaid and D2’s online playground for privacy reasons and have hand on my roadmap to get a local editor. This might be it! Does it support theming of mermaid diagrams, I noted the style keywords were in the roadmap still.

OlaProis 9mo ago
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.

nkmnz 9mo ago

Slightly off topic: is there any editor (and data format) that supports re-arranging mermaid charts? I often find myself wanting to slightly tweak the way the chart is rendered, e.g. moving around boxes so that some of them are clustered in a specific area etc.

OlaProis 9mo ago
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?
- nkmnz 9mo ago
  Mostly clustering and sorting, but most importantly, I use diagrams not only as a tool for communication, but also as a tool to think visually. Moving boxes around would be a huge benefit for that use case, while I still want to have the diagram as code for version control etc pp
  - OlaProis 9mo ago
    Visual thinking use case makes sense! 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
  - OlaProis 9mo ago
    Actually, this is going on the v0.3.0 roadmap. I've been looking for ways to make the standalone mermaid-rs crate genuinely better than just 'mermaid.js but Rust.' 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!

bovermyer 9mo ago

Very cool. The one thing that prevents me from trying this out as a potential note-taking daily driver is the lack of support for LaTeX. 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.

OlaProis 9mo ago
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!
- bovermyer 9mo ago
  I only need inline+display math, I don't need the full document features.
  - OlaProis 9mo ago
    Good to know! Inline + display math is a more tractable scope. Typst or a Rust KaTeX port could handle that without needing full LaTeX. Added to the consideration list with that clarification.
fmichel42 9mo ago
Agreed. Having an open-source alternative to (the otherwise excellent) Typora would be fantastic; as far as I can tell the main feature Ferrite is currently lacking to be used for most (all?) applications where I use Typora is a way to easily write and render maths formula. (As far as I am concerned, support for TeX math would be ideal due to wide support from the existing ecosystem; but Typst would work too.)

endorphine 9mo ago

Hey OP, curious how much experience you have with Rust, given that this is the only rust repo I see in your profile.

OlaProis 9mo ago
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.

deviation 9mo ago

AI generated code, AI generated HN post, AI generated comments…

djvdq 9mo ago
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"
- JCattheATM 9mo ago
  Why? It's not like LLMs can't generate solid code, and it's not like people don't guide them carefully to produce the code they want. I guess you're assuming he just gave a simple prompt to build an app that wasn't checked in any way, but why?
  - djvdq 9mo ago
    Then you are assuming it wrong. I just don't like AI generated stuff, that's it
    - JCattheATM 9mo ago
      So you have an irrational anti-progress bias. OK.
      - AlexeyBelov 9mo ago
        Let's not disingenuously put words in people's mouths. What if the bias is rational? What if it's not "anti-progress" but something else?
        JCattheATM 9mo ago
        I'm not putting words in anyone's mouth, I'm stating my conclusion. What else would the bias be? AI is a useful tool, to blanket 'not like' anything generated by AI seems ludditesque.

rkagerer 9mo ago

> Platform Note: Ferrite has been primarily developed and tested on Windows. While it should work on Linux and macOS, these platforms have not been extensively tested. Neat! Lately on Windows I've felt like a 2nd class citizen. > AI Disclosure: This project is 100% AI-generated code. Oh. Well, at least they're up front about it.

dystroy 9mo ago
This disclosure has been added today, after some users here called them out for hiding that they were using AI to build it.
- rkagerer 9mo ago
  Thanks for clarifying. That deflates the last of any excitement I had about this. Moving on...

OlaProis 9mo ago

v0.2.2 just released — addressing several issues raised in this thread: - CJK font support 1 — Korean/Chinese/Japanese characters now render properly - CLI improvements (#9, #10) — ferrite file.md now works, plus --version and --help flags - Undo/redo fixes 2 — Fixed scroll reset and focus issues - Default view mode setting 3 — Can now set split/preview as default - Configurable log level 4 — Reduce stderr noise - Ubuntu 22.04 compatibility 5 — .deb now works on 22.04+ Thanks to everyone who reported issues! Download: https://github.com/OlaProeis/Ferrite/releases/tag/v0.2.2 https://github.com/OlaProeis/Ferrite/releases/tag/v0.2.2

rajatkulk 9mo ago

Shamelessly plugging my app Octarine (https://octarine.app https://octarine.app) for users that may want a more WYSIWYG editing experience while storing all notes on device in markdown, which is also written in Rust (Tauri), and NOT vibe coded :)

weakfish 9mo ago
Wow, this looks awesome. Downloading now.
- rajatkulk 9mo ago
  Thank you! Open to any and all feedback!

cat-whisperer 9mo ago

I don't know much about the GUI space. I would love your take on why did you went with egui instead of guirs

OlaProis 9mo ago
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.

cat-whisperer 9mo ago

also, on the markdown front, I saw this cool library https://github.com/Canop/termimad https://github.com/Canop/termimad gaining popularity

dystroy 9mo ago
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.

hendry 9mo ago

Wish there was something like Mermaid for typical AWS Architecture diagrams. Something that doesn't suck like draw.io!

OlaProis 9mo ago
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?
- hendry 9mo ago
  More service flows aimed at security audits
  - OlaProis 9mo ago
    Service flows for security audits — that's a specific and useful use case! A few thoughts: What might work today: - Sequence diagrams can model service-to-service flows (API calls, auth handoffs) - Flowcharts with subgraphs can represent VPC boundaries, security groups - C4-style (context, container, component) is sometimes modeled with flowcharts What would make it better: - Custom shapes/icons (AWS service icons) - Annotations for security boundaries, trust zones - Data flow direction markers Alternative you might try now: D2 (https://d2lang.com https://d2lang.com) has better icon support and was designed for architecture diagrams. It has an AWS icon pack. Structurizr also does C4 well. That said, if there's demand for architecture-specific diagrams in Ferrite's Mermaid renderer, I could look at: 1. Custom icon/shape support via external SVGs 2. A dedicated "architecture" diagram type with security-relevant annotations Would a template or example for modeling security flows in Mermaid's current syntax help as a starting point?
    - hendry 9mo ago
      Yeah, an example would be good. Tbh the examples on https://d2lang.com/ https://d2lang.com/ don't seem to fit the bill of a typical AWS Architecture diagrams! https://aws.amazon.com/architecture/reference-architecture-diagrams/ https://aws.amazon.com/architecture/reference-architecture-d...

kmfrk 9mo ago

Markdown and Mermaid support, you have my attention!

mickdarling 9mo ago

This looks cool! And, to add to the list of shameless plugs for OSS markdown editors/renderers With mermaid support, I will add mine to the list: https://merview.com https://merview.com with full source code at https://github.com/mickdarling/merview https://github.com/mickdarling/merview

porjo 9mo ago

I don't want to diminish the effort put into this project, but it's a reminder to me of just how many markdown editors there are out there! And yet I'm still searching for the holy grail: - wysiwyg editor (not live preview) - simplicity: single binary that can be pointed at a directory of markdown files - fast launch time, low latency UI - cross platform - comes with basic 'extras' like tables & code block support I actually really like the Confluence editor experience. If I could get that in an FOSS 'offline' package, my needs would be met.

OlaProis 9mo ago
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.

JCattheATM 9mo ago

Would you maybe consider adding a musl version to your releases?

OlaProis 9mo ago
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.
- JCattheATM 9mo ago
  Thanks, I'll look forward to trying it then :)
  - OlaProis 9mo ago
    I tried to add it for this release but hit a wall with the font rendering dependencies (freetype, fontconfig). GUI apps need these for text display, and they don't play well with fully static musl linking - the build system wants a musl C++ cross-compiler and static versions of system libraries that aren't readily available in CI. We'll keep looking into options - possibly a Docker-based build with a proper musl toolchain, or investigating if we can make fontconfig use dlopen at runtime. For now the glibc build (Ubuntu 22.04) should run on most Linux distros. If anyone has experience with static musl builds for Rust GUI apps, we'd love to hear what's worked!