KiwiTalk: a Rust and SolidJS reimplementation of KakaoTalk for Linux desktops

A research client for systems KakaoTalk does not serve

KiwiTalk is described as an unofficial cross-platform KakaoTalk client written in TypeScript and Rust, with SolidJS on the front end and Tauri on the outside. The repository carries a warning block, written in Korean, that states the project was created for research purposes for devices and operating systems where KakaoTalk is not provided, naming Ubuntu and Arch Linux as examples.

The same block says the source code was not made or authorized by Kakao Corp., that its use may be restricted at any time, and that all responsibility for activity carried out through KiwiTalk rests entirely with the user. That is not a footnote in this project. It is the constraint that governs every decision below, from whether to install it to whether to log in with a real account.

The stated purpose is therefore narrow: reimplement the KakaoTalk client for desktop platforms the vendor does not target. The chat and login screens are the visible surface of that work. The repository also carries a link to a Figma mockup for the front-end design and a second mockup for a redesign that was under way, plus an ARCHITECTURE.md for a fuller description of the project structure and a Discord server for contributors.

Tauri wraps a SolidJS front end around a Rust workspace

The architecture is a split between two ecosystems in one repository. The top-level entries show frontend/ and backend/ directories, a package.json and pnpm-lock.yaml on the JavaScript side, and Cargo.toml plus Cargo.lock on the Rust side, with ARCHITECTURE.md as the map and vite.config.ts driving the front-end build.

The Rust side is a Cargo workspace. Its members are declared as:

[workspace]
members = ["./backend/bin/*", "./backend/crates/*"]

That single line explains the whole backend layout: binaries live under backend/bin and libraries under backend/crates. The workspace declares version 0.5.1, edition 2021, rust-version 1.57, and shared dependencies including tokio, tauri 1.6.2, log, anyhow and serde with the derive feature.

Three workspace dependencies point at the crates that do the actual messaging work: headless-talk at version 0.6.1, talk-api-internal at 0.4.1, and talk-loco-client at 0.6.1. The names describe the layering. A headless implementation sits at the bottom, an internal API crate sits above it, and a client crate for the messaging protocol sits alongside. Keeping those crates separate is what allows the same protocol code to run without a UI, which is also why the project can offer headless-talk as a path rather than only the desktop app.

On the JavaScript side the scripts map the same split. tauri dev and tauri build drive the whole application, vite and vite-plugin-solid drive the front end alone, and storybook dev -p 6006 serves the component library on port 6006.

Three commands get a running development build

The development setup has two prerequisites, and both are external. Because the project uses Tauri, you need the Tauri development prerequisites in place first. And because the front end uses pnpm for package management, pnpm has to be installed according to its own installation guide.

With those in place, installing dependencies is one command:

pnpm install

Running the application is the next:

pnpm run dev

The documentation makes a specific point about that second command: a GUI window has to appear, so you need to confirm that a suitable GUI environment exists. For Linux users on the Windows Subsystem for Linux, the documentation points at Microsoft's own guide to running GUI applications under WSL. That warning is easy to skip and expensive to ignore, since a headless shell is the usual WSL setup.

A third command starts Storybook, which the project uses to build out its design system:

pnpm run storybook

Storybook here is not decoration. With a mockup-driven design and a redesign in progress, a component story harness is how the front end gets built at all, and the port 6006 configuration in the scripts is where you find that choice recorded.

Translations, linting and a design system built with vanilla-extract

The front end carries more tooling than a small chat client strictly needs, and each tool has a job. SolidJS drives the UI, @solidjs/router handles navigation, i18next with @jellybrick/solid-i18next handles translations, and @vanilla-extract/css with @vanilla-extract/dynamic provide zero-runtime styling. html-parse-string and filesize sit in the dependency list for message content rendering.

The lint script is unusual enough to be worth quoting, because it targets translation files specifically rather than source code:

    "lint": "prettier --write frontend/src/assets/translations/*.json"

Prettier is configured with prettier-plugin-sort-json, so the translation files are formatted and their keys sorted. That matters for a multilingual client: keeping every locale file in the same key order is what makes a missing translation visible in a diff instead of hidden in a reordering. The .eslintrc.json and .prettierrc files at the top level cover the rest of the source.

The versions are pinned tightly across the board. TypeScript sits at 5.4.5, Vite at 5.4.21, Storybook at 7.6.21, and eslint at 8.57.1, with storybook-solidjs still on a 1.0.0-beta tag. The renovate.json file at the root suggests dependency updates are handled by automation, while the .yarnrc.yml presence hints at legacy Yarn configuration left alongside the pnpm workflow.

Unreleased branch work behind a 2023 release tag

The maintenance picture here is unusual and worth stating plainly. The repository is not archived, and the last push was on 2026-10-16, on a default branch named dev. The three most recent releases are v0.5.1 from 2023-11-09, v0.5.0 from 2023-11-08 and v0.4.2 from 2023-11-07.

So there have been no tagged releases in almost three years while commits continue on dev. The Cargo workspace still declares version 0.5.1, which matches the last release tag, so the crates in the repository are versioned as though nothing after that release had happened.

For a user this means there is no packaged binary to install and no changelog to read between versions. You build from the branch tip, and what you run is whatever the dev branch held on the day you cloned it. The release.toml file at the top level is the kind of artifact used to drive automated release packaging, which suggests the pipeline exists even though it has not produced a tag recently.

That is a real cost of adoption. There is no supported version to pin, no upgrade path, and no way to tell which commit you are running unless you note the hash yourself. Contributors are pointed at CONTRIBUTING.md and a Discord server, and the repository also carries a CODE_OF_CONDUCT.md, so the project is organized as a community effort even though its packaging has gone quiet.

The licensing is permissive, the authorisation is not

The licence is Apache-2.0. Both the package.json and the Cargo workspace declare it, and the repository ships LICENSE-APACHE alongside the Cargo.toml, so the code is open source in the ordinary sense and a fork can be redistributed under the same terms with the usual notices and patent grant.

That is worth separating carefully from the authorisation question, because the two are commonly confused. The code is permissively licensed; the service it talks to is not the licence holder's to grant. The project's own warning says the source was not created or approved by Kakao Corp. and that use may be restricted at any time. Nothing in Apache-2.0 changes that, and the licence text does not need to be read to see it.

So the honest comparison with the official client is not about licence terms but about support. The official KakaoTalk client is offered for the platforms KakaoTalk supports, on operating systems where it exists, and it comes with the vendor behind it. KiwiTalk exists for the gap the vendor left, on systems such as Ubuntu and Arch Linux, and it comes with a disclaimer that says you answer for your own use. Anyone who needs a chat client that will still be there in two years, with account support and push notifications that behave as the service intends, is looking at the wrong project.

Anyone on a Linux distribution the vendor does not serve, who accepts that they are running unreleased code against a service they do not control, is looking at exactly the right one.

Editorial conclusion

KiwiTalk suits a developer on Ubuntu or Arch Linux who wants a KakaoTalk client and is willing to run unreleased work from the dev branch, since no release has been cut since v0.5.1 on 2023-11-09 while the last push was on 2026-10-16. It does not suit anyone who needs a supported client, because the project states it is unauthorized and that its use may be restricted at any time. Before building it, install the Tauri prerequisites and pnpm, and decide in advance whether an unreleased branch of an unofficial chat client fits your account and data policy.

Frequently asked questions

Official sources

1. Issues
2. KiwiTalk/KiwiTalk on GitHub
3. License: Apache-2.0
4. README
5. Releases