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!

You are right, my bad.

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!

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)

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.

Done! I just published the full workflow documentation today:

AI Development Workflow: Complete explanation of the process, handover system, how I manage context between sessions

Historical PRDs: The actual Product Requirements Documents used to generate tasks (v0.1.x through v0.3.0)

Task JSON files: How requirements were broken down into implementable tasks via Task Master

Handover templates: The reusable prompts I use to maintain context between AI sessions

Thanks for pushing on transparency, your comment about "open weights vs open source" is a useful framing. The goal is to share enough that someone could reproduce and learn from the approach.

> "Open source" to me is sharing the input required [...]

I don't disagree with your sentiment, I am also more interested in human-written projects, but I'm curious about how this works. Would a new sorting network not be open source if found by a closed source searching program, like AlphaDev? Would code written with a closed source LSP (ie. Pylance) not be open source even if openly licenced? Would a program written in a closed source language like Mojo then be closed source, no matter what the author licences it under? The line between input and tool seems arbitrary at best, and I don't see what freedoms are being restricted by only releasing the generated code.

the line is blurry for shure. Code generated by a closed-source compiler (or LSP) is still 'your' code. Maybe the difference is whether humans can reproduce and learn from the process? With traditional code, you can read commit history and understand the author's thinking. With AI-generated code, that context is lost unless explicitly shared. Food for thought.

Great point about sharing the 'how' not just the 'what'. I'll consider adding prompt history or a development log showing the AI interactions, just have to figure out how to present all the data i guess. The commit messages could definitely include more context about what was requested vs generated. Thanks for the thoughtful framing,'open weights vs open source' is a useful distinction

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.

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!

My pleasure! Thank you for being receptive and open minded to such constructive criticism.

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

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

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

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

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

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

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

> 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.

Mobile is definitely a long-term goal, the lightweight binary and native performance would translate well. Your QR-code pairing idea is elegant for non-technical users.

For sync, I've been thinking about:

- Git-based sync for power users (already have git integration)

- Simple local network sync (mDNS discovery, no cloud required)

- Optional relay server, as you described — small binary for hub-and-spoke

The plain-file approach (no proprietary format) makes this tractable since any sync tool works today (Syncthing, Dropbox, etc.). But a native, frictionless solution would be better.

2. Tool Integration API

This aligns with v0.3.0's direction. The plan is:

- Mermaid crate extraction, establishes the modular pattern

- Editor widget as library, opens up embedding

- Command palette / IPC, could expose operations to external tools

For accessibility specifically, what interfaces work well for you? Shell commands? Named pipes? JSON-RPC? Knowing your workflow would help prioritize.

3. Vaults/Profiles

Good point — workspace settings are currently per-folder (`.ferrite/`), but there's no concept of isolated plugin configurations per vault. Added to the consideration list.

Thanks for the detailed feedback!

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?

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 :)

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!

The TODO list cursor behavior is exactly the kind of polish detail that matters. I'll add this to the issue tracker — cursor should respect line start position, not jump past the checkbox syntax.

These "many small details" are what v0.3.0's custom editor widget will unlock. egui's TextEdit doesn't give us fine-grained cursor control, but replacing it will.

Awesome, initially it looked like a quick AI-generated project but I see you care about it and plan investing the effort into it. Will be following on Github!

Main priority would be the editor itself to be similar to Obsidian (with links etc.) but maybe better, Obsidian is annoying for example when you edit a TODO list (which is 99% of the time for me), go to the beginning of the line, then press down to go to the next item -- Obsidian jumps into position between "- [ ] " and "item text", instead of staying at line beginning. Long story short, many small details to make this right.

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!

asciidoc or rst/sphinx, are tools which are much better suited to build software documentation with cross-references etc.

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.

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

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

Thanks for 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!

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!