Chitchatter: peer-to-peer chat with no operator on the other end

Room names are the only secret in the design

Chitchatter's security model reduces to one idea: a room is a random UUID generated in your browser, and that name is the key. The README describes the flow as joining a randomly generated room and sharing the URL through a secure channel of your choosing, naming Burner Note and Yopass as examples of services designed for that job. The copy button in the top bar is what produces the link.

Because the key is the room name, file transfer works the same way: files are encrypted before sending and decrypted by the receiver, and the README states plainly that the key is the room name. The feature list also claims unlimited file size transfers, which is a consequence of routing bytes directly between browsers rather than through a server with a body size limit. File transfer is powered by a separate library, `secure-file-transfer`, which sits in the dependency list at version 0.0.8, which tells you it is young.

The README also asks you to share your username in advance over that same secure channel, so the person on the other end knows who is talking to them. This is the weak point of the whole design and it is not a bug: anyone holding the link is in the room, and the room name is the only thing separating members from visitors.

What the anti-features list rules out

The README has a section headed anti-features, which is a more useful thing to read than a feature list because it defines the ceiling. Messages are never persisted to disk, and when you leave a room they are cleared from memory and cannot be retrieved. There is no analytics, tracking or telemetry of any kind. And the project takes no money, which the README treats as a structural guarantee rather than a boast: with no revenue there is no customer to serve ahead of the user.

The peer count limit is stated just as concretely. Multiple peers per room are supported, limited only by the number of peer connections your browser supports. That is a browser constraint, not an application one, and it means the practical room size on a given machine is smaller than the feature list implies. A full mesh is quadratic in connection count, so four or five people in a call with video is comfortable and twenty is not.

Conversation backfilling is worth noting as a design consequence of the mesh: when someone new joins, existing peers supply the recent history. That is a genuinely nice property of having no central store, and it is also why ephemeral messaging does not mean a stranger joining sees an empty screen.

Running the app from a clone with Vite

The README names Vite as the build tool and describes the project as client-side, so the development setup is an ordinary Node and Vite workflow. Get the source, install, and start the dev server:

git clone https://github.com/jeremyckahn/chitchatter.git
cd chitchatter
npm install
npm run dev

The repository is a TypeScript React project, and the dependency list is unusually large for a chat app because it covers the whole feature surface: React 18, react-router-dom 7, MUI 5 with its icon set, react-markdown with remark-gfm and react-syntax-highlighter for formatted messages, react-qrcode-logo for room sharing, web-vitals, and webrtc-adapter plus sdp for WebRTC compatibility work.

The testing and CI scaffolding suggests this is maintained like a real project rather than a weekend demo. There is an `e2e/` directory and a `playwright.config.ts`, `__mocks__/` for unit tests, a `.husky/` directory for git hooks, `.prettierrc.json`, `.eslintrc.json` and `.eslintignore`. The default branch is `develop`, and the tree includes an `AGENTS.md`, a `scripts/` directory, `manifest.ts` and a `vercel.json` for deployment.

The architecture claim and what the tree shows

The README is emphatic that no API server is required, and explains the mechanism: all communication happens directly between browsers, with public WebTorrent servers used to establish peer connections and TURN relays when a direct connection cannot be made. The security link it points to is WebRTC's, and the networking layer comes from Trystero, which appears in the dependencies alongside its `@trystero-p2p/torrent` and `@trystero-p2p/core` packages at version 0.25.4.

The repository layout complicates that story in a way worth naming rather than glossing over. There is an `api/` directory at the top level, a `simple-api-server.js` file, and a `vercel.json` for serverless deployment. So an optional API server is not hypothetical; the code is in the repository and the compose-free `vercel.json` is the deployment target. The README's claim that users can always choose to run without it is consistent with all of that, since the API is an enhancement for connectivity rather than a requirement, but the practical reading is that the app has two deployment shapes and you pick one.

There is also an `sdk/` directory, which is not mentioned in the README at all. Its purpose is not documented anywhere in the visible documentation, so treat it as an undocumented surface rather than guessing at it. What the README does document is that the app is embeddable in other web apps through an `iframe`, and that `react-git-info` is in the dependency list, which is how the app can display build information about itself.

Licensing reads two ways, and only one is binding

Two license identifiers appear for the same project. GitHub reports the repository license as GPL-2.0, and `package.json` declares `GPL-2.0-or-later`. These are not the same grant, and the difference is not pedantic: an or-later notice lets a downstream author relicense the work under a later GPL version if the licensee's own circumstances call for it, while the bare 2.0 reading pins the grant to that version alone.

The practical question is whether you intend to fork. The README says outright that if you disagree with the project's direction you are welcome to fork it, and it invites compensated feature work through issues while promising to support pull requests from others. If you take that invitation and ship a modified build, the copyleft obligation to release your changes under compatible terms travels with it. The LICENSE file at the repository root is the document that governs; the SPDX string in `package.json` is metadata that package tooling reads.

For anyone embedding the app rather than forking it, note that the README lists iframe embedding as a supported feature, which is a different relationship from the one copyleft governs, and the licenses of the bundled dependencies are a separate question you would need to answer per package.

Where maintenance mode actually bites

The maintainer's note is unusually direct and worth reading before you depend on this. Chitchatter is described as feature complete in the sense that it does everything the author personally needs, with no specific plans to add significant functionality, while a commitment to fix significant bugs that get reported. The README then uses the phrase effectively in maintenance mode for the foreseeable future.

That framing has consequences you can plan around. There are no GitHub releases at all for this repository, so there is no changelog to check and no version to pin to; `package.json` carries version 0.0.0, which means the project is versioned by commit rather than by release. The last push was on 2026-09-17, so commits are still arriving, which is consistent with bug fixing and dependency upkeep rather than new capability.

Set against that, the feature list is complete enough that maintenance mode is a rational position rather than abandonment: video and audio, screen sharing, direct messaging, encrypted unlimited file transfer, markdown with syntax highlighting, public and private rooms, dark and light themes, multiline messages via shift and enter, and automatic peer verification using client-side public-key cryptography. What you will not get is a feature you did not ask for, and the README's answer to that is a paid issue or a pull request.

Editorial conclusion

Chitchatter is a good fit for the specific job of talking to people you already know without routing the conversation through a company that can be compelled to hand it over. Video, audio, screen sharing, direct messaging and unlimited-size encrypted file transfer are all present, and nothing is persisted. The trade is explicit in the README's own words: the maintainer considers it feature complete and in maintenance mode, and the practical consequence is that improvements arrive when someone is motivated rather than on a schedule. Verify your threat model first, because the WebTorrent and TURN relays in the connection path are public and third party, which is a different guarantee from a self-hosted server you control.

Frequently asked questions

Official sources

1. Issues
2. jeremyckahn/chitchatter on GitHub
3. License: GPL-2.0
4. Project website
5. README