If you mean Komai specifically, I think that this characterization is unfair.
Komai is explicitly presented as a fork of Nheko. We credit the upstream project, major libraries (matrix-sdk) and assets (iconsets, etc.), and are open about using AI during development.
I’m not claiming sole authorship or pretending Komai was created from scratch. It's built on existing work (done by various humans over many years) and we're being transparent and thankful about it.
Disclosure: I've spent multiple months working on Komai (with AI and other humans).
The icons are not from Microsoft Teams. It's the Fluent System Icons (https://github.com/microsoft/fluentui-system-icons) free iconset by Microsoft, which Nheko (Komai's predecessor) also used and we continue to use. Because we found this iconset lacking in certain aspects, in Komai we also supplement it with Font Awesome.
Why double sidebars? Because Nheko established this pattern and I still think it's a good idea. On the desktop there's usually plenty of horizontal space to comfortably show everything without having to hide things away and require you to click multiple times. Still, both sidebars are collapsible to "just icons" for people who need the extra space.
In fact, most Matrix apps (Element, Discord, ..) have the same sort of "double sidebar" layout, but usually collapse the left-most sidebar to "icons only" by default. I think this makes it hard for new users to learn (icons are cryptic without a label) and there's no good reason to do it when you have enough horizontal space.
As for the padding, whether the defaults look good probably depends on screen size and personal preference. Komai is very configurable. There's a "Density" setting which offers 3 different options ("Spacious", "Compact" and "Dense"). "Spacious" is the default one, because it provides better ergonomics due to larger hit targets. Accessibility is important, but users who find the default padding too much can adjust it.
Disclosure: I've been working on Komai in my spare time for a few months now.
One person's "emoji vomit" classification is another person's "this looks good to me".
PRs for improvements are welcome, but:
- emojis are there intentionally. I asked for them and I personally think it's not too much. It's not something to clean up.
- I think the current AI-generated logo has character and is better than a stock SVG one can find online. The logo aims to represent a creature which is a mix between cat (nheko), lion & dog. See https://github.com/etkecc/komai/blob/main/docs/user-guide/id...
------
If you're choosing your software based on "has emojis in the README or not", then you'd be happy with many of the other Matrix clients. Most don't use emojis in their documentation (if they have much documentation at all).
It made me think: we don't have to suffer the brokenness of the old bot (https://github.com/matrixgpt/matrix-chatgpt-bot) anymore. Still, I wanted something more thread-based and more powerful than what you had built.. and I wanted a playground to learn some Rust.
To clarify for anyone that might get confused: baibot (https://github.com/etkecc/baibot) is not based on any of the chaz code, nor on the matrix-chatgpt-bot code. It's completely manually-built / independently-built (in Rust), by me, over multiple months of unpaid FOSS work.
This is a FOSS project with absolutely no funding.
There's no designer around to do a professional SVG logo, so we make use of what's there - AI to generate the (raster image) icon and then some tools to turn that into an SVG.
It turned out a little rough around some edges, but still good enough, I think. If anyone would like to polish it up, PRs are most welcome!
Icons may be a matter of taste. This one may be too detailed, but still scales well to small sizes. For now, I don't see why we should follow everyone else and go with an overly-simplistic icon.
As for the README emoji vomit: this may be a matter of taste as well. I find it makes it easier to scan through things, and I can assure you that each point on the README has been given much though and review by a human. Reducing it to "emoji vomit" is going too far.
Disclosure: I've been working on this Matrix chat app in my spare time over the past few months.
While AI was used for writing the code and large parts of the text (including in the blog post), I can assure you there's been a human author dedicating many days and sleepless nights on this alongside the AI.
Especially when it comes to the blog post, it's been human-reviewed and tweaked many times.
Still, if you don't like the content, it probably doesn't matter that there had been a human dedicating too much of his free time on this side project.
I'm sorry to hear that you got overwhelmed and gave up on Matrix!
Below, I'll try to explain why it can overwhelming and how one might navigate things better.
While the Ansible playbook's documentation is huge (which can be both good and bad), one does not necessarily need to read through everything to get started.
The playbook's documentation tries to guide you through the required steps to get started and always tries to suggest "skipping ahead" and staying with the recommended defaults. It does mention additional services, but branching off into reading about esoteric additional features from the very beginning is not necessary.
It's better to follow the steps and start with the basics. You can add additional services and tweak the existing ones later on at any time.
That said:
- just like a production-ready email system is complicated to deploy, so is Matrix (even with the Ansible playbook). Some learning and planning is necessary. Important decisions (with regard to domain names, etc.) need to be made upfront
- the playbook's documentation may benefit from a new and dedicated "quick-start guide" which would not even mention most or any of the additional services. This could help people get started quicker, instead of making them give up due to analysis paralysis
As for the latter, there are various articles (blog posts) online where people guide you through using the playbook (they act as a "quick start guide"). A downside to those is that some may be out of date and/or skip through steps which may turn out to be important later.
The playbook's documentation is extensive, because it not only aims to get you running, but to also instill knowledge as to how things work so that you're more capable of managing the deployment later on. It's a bit like the Arch Linux Wiki in this regard - it gives you more to read (and walls of text can be scary), but is also there for you for when you need help.
Having more deployment options and quick-start guides is always great!
That said, the Ansible playbook provides various benefits that you cannot currently get with any other Matrix deployment method. For one, it seems to be the only deployment method that supports hundreds of Matrix and related services which all tie together nicely.
Getting started quickly and easily is an important part, but is not the end. Most people will sooner or later need "that extra service" (bridge, bot, etc.) and it's always a hassle to get it added to a "quick & dirty" deployment.
Using the Ansible playbook, enabling an extra service is usually one extra line of configuration and you're up & running with a deployment that has been battle-tested and improved by hundreds/ thousands of others. You're not alone debugging a hand-made "Synapse worker configuration" or "Matrix Authentication Service" integration - there are many others iterating on the same exact setup.
Another compelling reason to go with the playbook is maintaining your deployment over time - handling major Postgres version upgrades, backups, uninstalling old/deprecated services (to replace them with newer alternatives), etc.
Yes, Ansible can be slow and clunky (and the YAML format is definitely annoying), but it seems like a reasonable tradeoff that provides plenty of benefits.
I'm happy to hear that my Ansible playbook for managing Matrix is helpful to people and is being appreciated!
Shameless plug - for people who'd rather not maintain their own server manually with Ansible, a few others and I are running https://etke.cc - a completely FOSS service service built on top of the Ansible playbook. Hopefully, this provides the best of both worlds - ease of getting started (on your own or on a rented server), everything built on top of FOSS, no vendor-lock-in (you can migrate to using the playbook yourself at any time, etc.).
Komai is explicitly presented as a fork of Nheko. We credit the upstream project, major libraries (matrix-sdk) and assets (iconsets, etc.), and are open about using AI during development.
I’m not claiming sole authorship or pretending Komai was created from scratch. It's built on existing work (done by various humans over many years) and we're being transparent and thankful about it.
Disclosure: I've spent multiple months working on Komai (with AI and other humans).