Chatty: a standalone Twitch chat client in Java that bundles its own dependencies

A desktop chat client for people who do not want a browser tab

Chatty is a Twitch Chat Client for Desktop written in Java, featuring many Twitch specific features. The project describes itself as a standalone application, and the topics attached to the repository name chat, java, standalone and twitch.

The problem it addresses is not that Twitch chat is missing, it is that the chat you get depends on where you view it from. A viewer watching in a browser is using one interface, a viewer watching through a streaming client is using another, and a viewer watching on a second monitor with the stream in a windowed application is using a third. Chatty is a single desktop client you can keep open regardless of what you are watching with.

The feature set is described as Twitch specific, and the README's own framing is that the developer learned most of the Java techniques and APIs used while building it, so many things won't be designed ideally. That is an unusual admission to make in a README, and it is worth taking at face value when judging the code. It is also a reason to read the project rather than skim it.

The distribution is a set of ready to use downloads on the project website at chatty.github.io, which the README points to for downloads and more information on the features. The project also has a contact e-mail, a Twitter account, a Mastodon account, a YouTube channel and a Discord server, which is a list of ways to reach one maintainer rather than a company.

The audience is therefore fairly narrow and quite clear: desktop Twitch viewers, and particularly the ones who want the chat separated from whatever is playing the video.

One jar tree, with the third party libraries already inside

The repository layout is the second thing to understand, because it says a lot about how the project is built and what a user receives.

The top level holds src/ and test/ directories, an assets/ directory and an assets-bundle/ directory, a build.gradle file, a gradle/ directory, gradlew and gradlew.bat wrapper scripts, a setup/ directory, and three licence files at the root: LICENSE, APACHE_LICENSE and LGPL. There is also a .gitattributes file and a .github/ directory.

The assets/ directory is where the dependencies live. The README's External Libraries section lists jar files under assets/lib/, and the entries are specific: json-simple jars and a source zip, JKeyMaster under a modified label, JTattoo jars and sources, Java-Websocket jars, txtmark, httpclient, httpcore and commons-codec jars, and WebPDecoderJN jars, with SLF4J noted as a requirement of the websocket library and JNA noted as a requirement of the image decoder.

Shipping dependencies as jars inside the repository rather than resolving them from a package manager is a deliberate choice with a clear purpose. A desktop application distributed as a zip to end users does not have a package manager to resolve dependencies, and if the resolution happened at first run the user would need a working network and a working Java. Bundling removes both failure modes and makes the download self-contained.

The build system is Gradle, with the wrapper scripts at the root, so building from source does not require a separately installed Gradle either.

The trade-off is that a vendored dependency tree is a maintenance burden of its own. When a library in assets/lib has a security fix, the update has to be pulled in by hand, and the bundled versions will lag whatever upstream published most recently.

A GPL shell around a MIT core, with three licence files in the root

The licensing arrangement is described in unusual detail, and it is the most interesting thing in the README.

Chatty as a whole is released under the GPLv3 or later, and the notice carries the copyright of tduva and contributors for 2017-2023, with the standard GPL text reproduced in full.

Then there is a second grant. The README states that the project is partly based on source code, with most files located in the src/chatty/ directory and subdirectories, licensed under the MIT license, with the 2014-2017 copyright of tduva and contributors and the full MIT permission text. So the code that was written first and lives under src/chatty/ carries MIT terms, and the work built on top of it is GPLv3.

Three licence files at the root, LICENSE, APACHE_LICENSE and LGPL, is consistent with that, because the third party libraries are bundled under their own terms: JSON-Simple under Apache 2.0, JKeyMaster under LGPL-3.0, JTattoo under GPLv2 or later, FlatLaf under Apache 2.0, Java-Websocket under MIT, Txtmark under Apache 2.0, Apache HttpComponents Client under Apache 2.0, and WebPDecoderJN under 3-Clause BSD, with SLF4J under MIT and JNA under Apache 2.0. The README also notes that additional external or modified libraries integrated under src/chatty/ have licence and source information in the file header.

There is one point in the README that deserves repeating because it is the kind of thing that causes friction in contributed code. Contributors are asked to make sure they adhere to whatever licence terms code they did not write themselves is under, for example by retaining copyright notices, and to detail that in the pull request.

The icons are documented too, down to individual file names, with the Tango icon theme released into the public domain and the Nuvola icons under LGPL.

This review does not interpret licence obligations, and the practical advice is simply to read the three files in the repository root before redistributing a build.

A single maintainer learning in public, and a beta-tagged release line

The project's history is unusual, and it shapes what you can expect from it.

The README says the developer learned about most of the Java techniques and APIs used in the project during its development, so many things won't be designed ideally, and that this was also the first time the developer released a project as open source, so if anything was missed or a licence was not adhered to correctly, the invitation is to say so. The contributions section reinforces the tone. The maintainer notes that not all contributions can be accepted, for example because they may already be working on something similar, and asks that anyone planning to put more than a little effort into a pull request consider asking first whether it has a chance of being added.

That is a candid description of a one-person project, and for a desktop application that people install to watch chat, that is a fair thing to weigh.

The version history shows the state of it. The recent tags are v0.29-b2, Version 0.29 Beta 2, from 2026-09-24, v0.29-b1, Version 0.29 Beta 1, from 2026-06-19, and v0.28 from 2025-12-19. The last push was on 2026-09-24, the same day as the beta 2 tag, and the default branch is master.

So the last non-beta release is 0.28 from December 2025, and the 0.29 line has been in beta for over three months, with two beta tags. The number itself is worth noting too: all three recent tags are below version 1.0, which in practice means the API and behaviour can still change between releases.

For a user, none of this is a blocker. For someone who wants to script against Chatty or build on it, it means the 0.29 betas are the current line and 0.28 is the conservative choice.

What the browser already does, and what Chatty adds

The honest comparison here is against the browser chat, because that is what a Twitch viewer already has and it is free and always up to date.

The browser tab opens with the page, updates in real time, needs no install, and follows whatever changes Twitch makes to the site. Its cost is that it shares space with the video, it is tied to the browser's tab lifecycle, and its feature set is whatever the site offers.

Chatty's approach is a separate window that stays open. The benefit is that the chat does not scroll away when the page does, that it can be placed on a second screen, and that the client can carry Twitch specific features rather than the general purpose behaviour of a web page. The cost is that it is a separate application you launch, you maintain a Java process for it, and you have to update it yourself when a new version is released, since the releases are downloads rather than something that updates in the background.

A third option exists in the middle, which is a browser extension or a streaming client overlay. Those share the browser's login session, so there is no separate authentication to manage, and they update with the client. What they do not give you is an independent window that survives page navigation, which is the thing people who use this kind of tool are usually after.

The README does not list the Twitch specific features item by item, which is a documentation gap worth noting, and it points to the website for more information on the features. For a decision, that means the project page rather than the repository is where you would go to find out whether the specific features you want are there.

Editorial conclusion

Chatty fits a Twitch viewer who wants a desktop chat client with Twitch specific features and does not want to install a browser extension or a streaming client, since the downloads come with the dependencies already in place. It is the wrong choice for someone who only needs the browser chat, for a team that needs the client to be auditable as a single artefact, since the project is a personal open source effort with a stated history of unfamiliarity with open source practice, and for anything that requires a stable release, because the current tag is v0.29-b2, a beta. Before you install, read the bundled licence notices for the third party libraries under assets/lib, and check the release notes for 0.29 since the 0.28 line was the last non-beta tag from 2025-12-19.

Frequently asked questions

Official sources

1. chatty/chatty on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases