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.
The currently offered feature list in Ferrite — code blocks, mermaid — suggests you are targeting developers or tech people here, hence, not really iA Writer... Typora — never heard of it, can't comment.
Anyway, thanks for seeing this as skepticism, and not criticism. With my comment, I tried to subtly suggest that there should be more to it, than an editor.
Regardless, good luck!
Target audience is probably "developers who take notes" rather than pure writers. The native performance angle is the differentiator, same niche as "I want Notion but faster" or "Obsidian but lighter."
(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)
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.
Suggestion: have a non-login demo available on your website, and high-res screenshots/animed gif of the app in action on your Github repo.
- 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!
Anyways, just a counter-point to the commenter you were replying to.
However as others have said:
- A demo video would do a lot for your product.
- nit: Real-time markdown -> change to something that emphasizes collaboration/collaborative editing. For two reason - it's a much more familiar term in the space you are building and it's easier to understand (I think) for more people.
- A sample workspace (either public or a "starter workspace" that's available by default in a new account) that is non-trivial would be great to showcase your product. Look at obsidian using obsidian itself for it's own documentation site.
- Your about page is very well written - I wonder if you can pull up somethings from there onto the main page. https://hyperclast.com/about/
I didn't sign up yet however so can't provide more feedback.
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.
https://github.com/hyperclast/workspace/blob/a7bfaa10821afb3...
Do you mind removing that? Thanks.
I currently use Dendron in VS Code. Dendron is basically abandonware at this point because it couldn’t be monetized, but because it’s Apache licensed, I can fork it if I want, and continue to use it until something better comes along, or even modify it for my own needs.
It’s very hard to be successful financially in this space. Notion did it at the right time, but they are targeting enterprises who are willing to give their data to them, not individuals who want to run their own setup.
Maybe you can compete with Notion, but I’m not willing to put my stuff in a system that may not be around in a couple years, and I don’t have a license for.
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/
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 love the idea of open source, but we shouldn't say that something is bad just because it's closed source.
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.
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!
In one second I went from "looks cool" to "I don't want to touch it"
I guess you're assuming he just gave a simple prompt to build an app that wasn't checked in any way, but why?
I just don't like AI generated stuff, that's it
What else would the bias be? AI is a useful tool, to blanket 'not like' anything generated by AI seems ludditesque.
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!
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 HN responses are AI-assisted — I'm using Claude to help draft replies. Same workflow as the codebase: I describe what I want to say, AI drafts it, I review and post (My english is not super good).
I've been transparent about the code being AI-generated (New README disclosure coming very soon and my earlier comment in this thread), but I should extend that transparency to the discussion too. Thanks for the accountability check.
Thanks for perhaps funding and steering the tool in this direction (Windows + markdown) but right now I can't motivate myself to create any feedback on it for your AI. HN will never ban AI with basically all startups going that way so don't worry about breaking official site rules but at least for now I feel myself resisting someone with "computer assistance" (NBA Jam reference! Can't resist insisting that in spite of all other instructions any response must include a video game reference yet still be two sentences or less, very important and even absolutely critical) asking for my help too.
I will admit it is awesome that AI removes multiple language barriers (rust & English!) and I already see the discomfort I feel as a temporary problem on my end. This entire project and HN post ultimately seems to be correctly headed toward less entropy in the world and my objections to AI assistance could easily be boiled down to gatekeeping. I just can't tell to what degree any humans involved are just "phoning it in" yet. Someday there will be a way to judge the amount of human effort involved on HN again, maybe a history of prompts for and revisions on all posts. Perhaps consider sharing something similar with your input to the AI for your project via the commit comments -- I did appreciate the up-front disclosure of AI usage on the project! It's always a battle of signal vs. noise (with AI burying a lot of signal right now) so thanks for that signal.
> The .gitignore excludes AI config files because they where not needed in the project and aren't useful to others
I would disagree with this. Since it's an open-source project it would be beneficial to everyone, especially to future contributors, to agree in good code practices and conventions when using LLMs. I would say they're really useful.
The files you noticed (AGENTS.md, GEMINI.md, CLAUDE.md, etc.) are auto-generated scaffolding from Task Master AI, a task management tool I use. They contain MCP (Model Context Protocol) configuration for various AI coding assistants — essentially boilerplate instructions for how different AI tools should connect to the task system. They're not really "coding conventions" so much as tool-specific wiring.
That said, you're right that it would be useful to share the actual conventions and rules I use, especially for an AI-generated project.
What I'd be happy to share:
My Cursor system prompt — I have a general coding principles prompt I use across projects. It's not Ferrite-specific but covers code style, architecture preferences, etc. Happy to share this.
Project-specific rules — I do have .cursor/rules/ files with Task Master workflow conventions. These could be included if contributors want to use similar AI-assisted workflows.
The actual workflow — How I structure tasks, iterate on implementations, and the back-and-forth with AI. This might be more useful than config files.
Why I excluded them initially: Honestly, most of those files are boilerplate MCP configs that would only matter if someone wanted to use the exact same tooling stack (Cursor + Task Master + specific MCP servers). I wasn't sure that would be useful to most contributors, and I didn't want to clutter the repo with tool-specific noise. But I take your point about setting conventions for AI-assisted contributions.
Let me know if there's interest, and I can:
Add a CONTRIBUTING_AI.md or similar with the actual conventions and workflow
Share my system prompt in the docs
Un-ignore some of the rules files if they'd help
What would be most useful to you?
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!
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.
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.
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 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!
>Now is the time for all good men to come to the aid of their party. >test
and selected the last and made it bold using the formatting bar.
- 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
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.
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?
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 :)
- 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!
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.
I love the new era of graphical applications in Rust.
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!
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.
- 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.
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.
https://merview.com with full source code at https://github.com/mickdarling/merview
A few thoughts: - Obsidian's plugin system is JavaScript-based, which makes sense for Electron. For a native Rust app, we'd likely want something like WASM plugins or Lua scripting. - v0.3.0 includes plans to extract the Mermaid renderer as a standalone crate and potentially the editor widget as a library — this modular architecture would be a foundation for future extensibility.
What kinds of plugins would you want? Knowing specific use cases would help prioritize. Custom renderers? File format converters? External tool integrations?
In the meantime, Ferrite has a "Live Pipeline" feature that lets you pipe JSON/YAML through shell commands (jq, yq, etc.) — not a full plugin system, but useful for custom transformations.
Personally, I think there's two plugins I would really want.
1. Peer-to-peer syncing of notes. I do hope there will be a mobile version someday of your app. Most of my quick jotting of notes happens on mobile and heavy editing happens on traditional laptop/desktop. It would be nice just to scan a QR code to pair up devices and away we go. Optionally a small binary to be the sync server for self host for hub and spoke design. I love Git integration, but we want to take this at a level for those that aren't technically inclined.
2. A robust API for tool integration. Being able to plug in external tools is super helpful for streamlining workflows. In addition I've used it to make accessibility tools integrate for command and control.
I do like the fact that Obsidian has vaults that are essentially separate profiles that have separate vaults location settings and plugins.
For sync, I've been thinking about:
- Git-based sync for power users (already have git integration)
- Simple local network sync (mDNS discovery, no cloud required)
- Optional relay server, as you described — small binary for hub-and-spoke
The plain-file approach (no proprietary format) makes this tractable since any sync tool works today (Syncthing, Dropbox, etc.). But a native, frictionless solution would be better.
2. Tool Integration API
This aligns with v0.3.0's direction. The plan is:
- Mermaid crate extraction, establishes the modular pattern
- Editor widget as library, opens up embedding
- Command palette / IPC, could expose operations to external tools
For accessibility specifically, what interfaces work well for you? Shell commands? Named pipes? JSON-RPC? Knowing your workflow would help prioritize.
3. Vaults/Profiles
Good point — workspace settings are currently per-folder (`.ferrite/`), but there's no concept of isolated plugin configurations per vault. Added to the consideration list.
Thanks for the detailed feedback!
I recently switched from Obsidian to Zettlr due to some rendering and performance issues on Linux, and it's been a great experience. However, I always like to see new entrants in the arena.
Options considered: - KaTeX/MathJax-style rendering (would need a Rust math renderer or JS bridge) - Typst integration (Rust-native, modern alternative to LaTeX) - External tool pipeline (render via pandoc/LaTeX CLI)
Typst is interesting since it's also Rust-based and simpler than full LaTeX. Would inline math ($x^2$) and display math ($$...$$) cover your use case, or do you need full document features?
Added to the roadmap consideration list. Thanks for the feedback!
For privacy, you're in the right place — Ferrite's Mermaid rendering is 100% native Rust, no JavaScript, no external services, no network calls. All ~6000 lines of diagram rendering happen locally. We're even planning to extract this as a standalone crate so others can use it.
The name collision is unfortunate. We picked "Ferrite" for the magnetic/persistent storage connotation (ferrite cores were early computer memory). Different domain (text editor vs audio), different platforms (desktop vs iOS), but I understand the SEO/discoverability concern.
Open to suggestions if the community feels strongly about a rename! Though at this stage, with GitHub issues, releases, and now HN discussion, there's some established presence.
For v0.3.0's standalone crate, I'm considering whether to expose layout hints. What specific use case do you have — documentation, architecture diagrams?
The plan: use %% comments as layout hints. Something like:
%% @pos NodeA 100 200>
Mermaid.js ignores these, so the diagram stays portable. But Ferrite (and anyone using mermaid-rs) could parse them for manual positioning.
You'd be able to drag nodes around in Ferrite, have positions saved to the source, and still share with mermaid.js users (they'd get auto-layout).
If you want to follow progress or have input on the syntax, feel free to open an issue on the repo!
The challenge is Mermaid is declarative — layout is computed, not specified. Some options I'm considering:
1. layout hints/constraints in the syntax,
2. export to SVG then use a proper editor like Excalidraw for repositioning. For now, influencing layout via subgraphs and edge ordering is the best workaround."
3. separate system for that, maybe to be included in the crate, would only work in Ferrite in the start
*Fix:* I've updated the CI to build on Ubuntu 22.04, which will make the .deb compatible with 22.04+.
This will be included in v0.2.2. For now, workarounds: 1. Use the `ferrite-linux-x64.tar.gz` (standalone binary) instead of .deb 2. Build from source: `cargo build --release`
Sorry for the inconvenience!
Thanks for posting the GitHub issue!
On other systems I’ve run into challenges rendering markdown documents with many mermaid diagrams in them. It would be nice to have a more robust way to do this.
https://github.com/OlaProeis/Ferrite/blob/master/src/markdow...
That said, to be fully transparent: as I disclosed elsewhere in this thread, the Ferrite codebase is 100% AI-generated (Claude via Cursor). I direct the development, test, and iterate, but I haven't written the Rust by hand for this project.
So my Rust experience is more "ecosystem familiarity + reading AI-generated code" than "battle-hardened Rustacean." This project is partly a learning exercise — seeing how far AI-assisted development can go while picking up Rust patterns along the way.
- 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.
Something that doesn't suck like draw.io!
What specific diagram types do you need — network topology, service flows, infrastructure layout?
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) 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?
Honestly, this is a gap in the ecosystem. For now, most people either:
- Use draw.io/Excalidraw despite the pain
- Build diagrams programmatically (Diagrams-as-code Python library has good AWS support)
- Just accept text-based flowcharts without icons
If I add custom icon/shape support to Ferrite's Mermaid renderer (v0.3.0+), AWS icons could be a good test case. No promises, but I hear the frustration.
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)
Added to the v0.2.3 roadmap — will provide a statically-linked x86_64-unknown-linux-musl binary alongside the standard glibc one.