The Problem
Enterprises that need a self‑hosted, low‑latency chat platform often have to stitch together separate text, voice, and file‑transfer services. Maintaining consistency, end‑to‑end encryption, and a single client that works both as a standalone HTML page and on mobile adds operational overhead.
What This Does
lemon‑chat delivers a lightweight C++ server (under server-source-code/libdatachannel/) that speaks WebSocket for text/images and WebRTC data channels for audio. The client is a single client/client.html file that can be opened in any browser or packaged with Electron. An Android front‑end lives in client/android/, exposing the same functionality via a native UI.
Key files: Server entry points are CMake‑driven (server-source-code/libdatachannel/CMakeLists.txt). The core networking library lives in server-source-code/libdatachannel/ and pulls in the header‑only nlohmann/json dependency. Android build is defined in client/android/app/build.gradle and client/android/build.gradle.
How To Use It
Setup – Server
Clone the repo git clone https://github.com/azc5OQ/lemon-chat.git cd lemon-chat
Build the C++ server (requires CMake, a C++17 compiler, and libnice/libjuice) mkdir -p build && cd build cmake ../server-source-code/libdatachannel cmake --build . --config Release
The resulting binary is placed in build/ (exact name depends on the CMake target, typically libdatachannel or lemon-chat).
Setup – Android client
cd client/android ./gradlew assembleDebug # Generates an APK in app/build/outputs/apk/debug/
The Android project uses Gradle version catalogs (libs.versions.toml) and does not lock transitive versions, so reproducible builds depend on the remote Maven repositories at build time.
Configuration
Server: edit server-source-code/libdatachannel/README.md for port numbers and optional TLS settings. No separate config file is shipped; the binary reads command‑line flags (see source main.cpp in the libdatachannel folder). Android: update client/android/app/src/main/res/values/strings.xml for default server address or supply it at runtime via the UI.
Running – Server
./lemon-chat --port 1111 --enable-audio
(Exact flag names are defined in src/*.cpp; consult the source for the full list.)
Running – Client
Desktop: open client/client.html in a browser, enter the server IP/port, and click Connect. Android: install the generated APK and launch the app; it presents the same connection UI.
Real‑World Use
A small‑to‑medium team can deploy the server on a virtual private server (VPS) behind stunnel for WSS termination, as described in the README. The same client.html can be copied to an Apache web root, allowing users to join from any browser without installing software, while the Android app serves mobile workers who need push‑notification‑style alerts.
Code Health & Issues
Low – Missing lockfile – client/android/app/build.gradle declares dependencies without a Gradle lockfile; builds may vary across CI agents. Low – Sparse CI coverage – Travis config (.travis.yml) exists only for the C++ library; Android builds are not exercised automatically. Low – No top‑level license – The repository contains server-source-code/libdatachannel/LICENSE but lacks a root‑level license file, which may cause legal ambiguity for downstream users. Low – Incomplete build scripts – The README references windowsbuildscript.bat and linuxbuildscript.sh, but these files are not present; users must rely on manual CMake commands. Low – Limited automated tests – 31 test files belong to the bundled nlohmann/json library; the server itself has no unit or integration tests. Low – Documentation gaps – README.md explains high‑level usage but does not list the exact command‑line options or required runtime libraries (e.g., libnice, libjuice).
Overall, the code compiles cleanly on supported platforms, and the Android project builds without errors when the required SDKs are installed.
The Bottom Line
lemon‑chat provides a functional, self‑hosted chat stack with a single‑file web client and an Android wrapper, suitable for teams that can manage C++ dependencies and are comfortable handling missing build scripts and limited test coverage. It is best suited for small‑to‑medium deployments where the lightweight footprint outweighs the need for extensive CI or formal licensing.