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) 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.
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
My impression was that everyone uses their $EDITOR and integrates languages support via plugins. The only exception to this rule I know is Emacs (org mode). I really doubt a standalone md editor will get traction, no matter how good it is.
Market exists: Obsidian has 1M+ users, Typora is popular, iA Writer has a loyal following. These aren't VS Code users who wandered off — they're writers, PKM enthusiasts, and note-takers who find IDE-style editors overwhelming for prose.
Different audience: Developers might prefer VS Code + Markdown Preview Enhanced. But Ferrite targets people who want a focused writing tool, not a general-purpose editor that happens to support Markdown. Think "writing app" vs "code editor with Markdown support."
Native advantage: Most Markdown tools are Electron (Obsidian, Typora, Mark Text). Ferrite offers instant startup, lower RAM, and native performance — appeals to the "I want my tools to feel fast" crowd.
You might be right that it won't achieve mass adoption. But there's a niche for "Obsidian but native and lighter" that I think is underserved.
Completely non-accusatory, just wondering. Did you write this post using an LLM? I sort of feel the typical "voice" if LLM writing here and wondering if I should calibrate myself a bit in this.
I use Obsidian a lot, but very few extra features or plugins. My first impression is that I don’t get what you’re making from the website. Any tool worth using in this space (which I vaguely understand to be using large collections of Markdown and/or realtime multiediting) is fast. Obsidian is fast. Zed is fast. It’s table stakes for the kind of person who would use this already.
Is it just Zed + Obsidian? A good knowledge base that scales well and uses plain markdown, but has the fancy multi edit stuff?
Disclaimer: I'm not your target audience, I don't care about collaboration or performance.
- There's a heavy emphasis on performance. Are you sure customers care about that more than real time collaboration and self hosting? (I don't think they care about CRDTs.)
- If I am experiencing pain because eg my Notion wiki is too big and is having serious performance issues, what I want to hear immediately is how you are going to help me migrate from Notion to your solution. Notion has a feature to export an entire workspace; can you ingest that and get me spun up with your product?
- If I hear something is open source I expect to be able to try it out immediately without logging in. It looks like you can do that but when you hit "Get Started" it puts you into a registration flow.
- You might take a look at how Zed is marketing themselves, they have a similar pitch (performance + realtime collaboration). The first thing they try to show you is a video where they demo the product and show how fast it is. (I think they focus too much on performance though.)
- The frontend is a web app right? If possible rather than a video, embed the interface in your landing page. If possible, let them share their document and try out collaborating on it with someone or with another browser tab. Give them an opportunity to be impressed.
I respect anyone who posts their work. Best of luck.
> There's a heavy emphasis on performance. Are you sure customers care about that more than real time collaboration and self hosting?
- Good point, I'll find out
> Notion has a feature to export an entire workspace; can you ingest that and get me spun up with your product?
Yes, I'm almost done with this feature
> If I hear something is open source I expect to be able to try it out immediately without logging in. It looks like you can do that but when you hit "Get Started" it puts you into a registration flow.
I link to that elsewhere in the page: https://hyperclast.com/dev/ I'll look into making this more prominent.
> You might take a look at how Zed is marketing themselves
You need something "more" on the website before you ask people to create an account. "Team workspace that stays fast" isn’t clear enough for me, at least. What is a workspace? What does the interface look like? Is it in the browser? Is it an app?
People will go "what is this?", "huh, I’m not gonna make a user for this, can’t tell what it is". Those are my 2 cents.
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.
Fully agree that pushing OSI is just posturing. After all, Amazon/Google/Facebook have made literal billions by commercializing open source software. I release stuff on MIT all the time (for things I'm okay with people poaching) but I'd argue the only "pure" OSS license is GPL, which comes with its own problems (and, as we all know, it infects everything it touches).
The problem with FSL is that it hasn't been tested in the courts yet (afaik), so it's a bit of a gamble to think it'll just "work" if some asshole does try to clone your repo and sell your work. Maybe it's a decent gamble for a funded startup with in-house counsel, but if you're just one guy, imo keep stuff you want to sell closed-source, it's not that big of a deal. We've been doing just that since the 70s.
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.
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.
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.
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?
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!
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
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.
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!
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!
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.
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.
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.
Small correction: Ferrite uses egui (by Emil Ernerfeldt), not anything from Zed. Different ecosystem entirely.
- Zed uses their own gpui framework
- Ferrite uses egui — an immediate-mode GUI library
egui is great for rapid development but has limitations. The v0.3.0 custom editor widget is specifically because egui's built-in TextEdit blocks features like proper multi-cursor and code folding. We're not getting much "for free" there — the Mermaid renderer, syntax highlighting integration, and view synchronization are all custom.
That said, egui definitely accelerated the initial UI work. Credit where due!
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.
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!
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)
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.
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!
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!
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.
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.
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.
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 ;))
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.
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.
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!
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?
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!
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
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`
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.
> - ~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.
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.
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/
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)
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.
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.
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.
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!
It would be interesting to know more about the end-goal if any.
Best of luck! I'll watch this.
My impression was that everyone uses their $EDITOR and integrates languages support via plugins. The only exception to this rule I know is Emacs (org mode). I really doubt a standalone md editor will get traction, no matter how good it is.
Market exists: Obsidian has 1M+ users, Typora is popular, iA Writer has a loyal following. These aren't VS Code users who wandered off — they're writers, PKM enthusiasts, and note-takers who find IDE-style editors overwhelming for prose.
Different audience: Developers might prefer VS Code + Markdown Preview Enhanced. But Ferrite targets people who want a focused writing tool, not a general-purpose editor that happens to support Markdown. Think "writing app" vs "code editor with Markdown support."
Native advantage: Most Markdown tools are Electron (Obsidian, Typora, Mark Text). Ferrite offers instant startup, lower RAM, and native performance — appeals to the "I want my tools to feel fast" crowd.
You might be right that it won't achieve mass adoption. But there's a niche for "Obsidian but native and lighter" that I think is underserved.
(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)
Is it just Zed + Obsidian? A good knowledge base that scales well and uses plain markdown, but has the fancy multi edit stuff?
Obsidian and Zed are desktop apps, whereas Hyperclast is web-based. Obsidian isn't multi-player, and not really meant for teams.
- There's a heavy emphasis on performance. Are you sure customers care about that more than real time collaboration and self hosting? (I don't think they care about CRDTs.)
- If I am experiencing pain because eg my Notion wiki is too big and is having serious performance issues, what I want to hear immediately is how you are going to help me migrate from Notion to your solution. Notion has a feature to export an entire workspace; can you ingest that and get me spun up with your product?
- If I hear something is open source I expect to be able to try it out immediately without logging in. It looks like you can do that but when you hit "Get Started" it puts you into a registration flow.
- You might take a look at how Zed is marketing themselves, they have a similar pitch (performance + realtime collaboration). The first thing they try to show you is a video where they demo the product and show how fast it is. (I think they focus too much on performance though.)
- The frontend is a web app right? If possible rather than a video, embed the interface in your landing page. If possible, let them share their document and try out collaborating on it with someone or with another browser tab. Give them an opportunity to be impressed.
I respect anyone who posts their work. Best of luck.
> There's a heavy emphasis on performance. Are you sure customers care about that more than real time collaboration and self hosting?
- Good point, I'll find out
> Notion has a feature to export an entire workspace; can you ingest that and get me spun up with your product?
Yes, I'm almost done with this feature
> If I hear something is open source I expect to be able to try it out immediately without logging in. It looks like you can do that but when you hit "Get Started" it puts you into a registration flow.
I link to that elsewhere in the page: https://hyperclast.com/dev/ I'll look into making this more prominent.
> You might take a look at how Zed is marketing themselves
Thanks, will do
> embed the interface in your landing page
Great idea, I'll do that!
People will go "what is this?", "huh, I’m not gonna make a user for this, can’t tell what it is". Those are my 2 cents.
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/
[2] https://faircode.io/
The problem with FSL is that it hasn't been tested in the courts yet (afaik), so it's a bit of a gamble to think it'll just "work" if some asshole does try to clone your repo and sell your work. Maybe it's a decent gamble for a funded startup with in-house counsel, but if you're just one guy, imo keep stuff you want to sell closed-source, it's not that big of a deal. We've been doing just that since the 70s.
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.
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.
I'll retake them with a more focused window size and less dead space. Appreciate the specific guidance!
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?
I don't know if it's the best format to focus on.
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!
How did you find working with egui?
Claude Code would have preferred React.
If the value of JavaScript programming goes down, Rust programming will probably hold value a little bit longer.
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!
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!
The domain knowledge still matters. AI just compresses the boilerplate time.
- Zed uses their own gpui framework - Ferrite uses egui — an immediate-mode GUI library
egui is great for rapid development but has limitations. The v0.3.0 custom editor widget is specifically because egui's built-in TextEdit blocks features like proper multi-cursor and code folding. We're not getting much "for free" there — the Mermaid renderer, syntax highlighting integration, and view synchronization are all custom.
That said, egui definitely accelerated the initial UI work. Credit where due!
[1] https://github.com/kovetskiy/mark
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.
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 ;))
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.
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.
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?
https://github.com/tonarino/acoustic_profiler
*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!
I love the new era of graphical applications in Rust.
Thanks for posting the GitHub issue!
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.
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)
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...