Project Goals

• March 2021, stuck at home during Covid-19 government lock-down, looking for an interesting project.
• Wanted an IRC webclient for for iPhone Plus (375 px) using Chrome IOS browser.

Program Structure

The overall architecture consists of a web server located in the middle between an IRC server and a web browser

The connection to the IRC server is a simple TCP socket wrapped in TLS to pass conventional RFC 2812 messages.

The connection to the web browser is more complex. The primary challenge was addressing disconnect of any socket connections during smartphone screen lock. It is assumed that smartphone is doing this to place radios into power-save idle state to conserve battery.

This has been addressed by utilizing two independent routes for IRC messages to reach the browser. The browser will establish a websocket connection to the web server, wrapped in TLS. The websocket is used to asynchronously pass messages from the IRC server, having been forwarded by the web server, onward toward the browser. The websocket, when connected, is a real time 1 for 1 pass-through of IRC server messages. Therefore, if a smartphone screen lock causes the websocket to disconnect, some messages are potentially lost.

The intermittent websocket issue has been addressed by providing a standard web API, wrapped in TLS, capable of using a POST request to retrieve the contents of a message cache located on the web server. This allows the browser to clear the contents of any open windows and re-populate the display from data in the API response.

Websocket traffic to the browser passes only in one direction, from IRC server to IRC Client. The return side of the websocket is not used. All outgoing IRC message from the IRC client toward the IRC server are sent using a POST request to a message API on the web server.

With this configuration, IRC windows on the web browser page will show real time IRC messages as they arrive. Scroll features allow backwards review of messages. However, if the websocket disconnects from the web server, only messages in the message cache are restored. The current message cache is 100 IRC server messages per IRC channel up a maximum limit of 5 IRC channels. This seems to be a reasonable size for general smartphone use. This is not intended to be a long term offline IRC client.

Coding Goals

• Single HTML page
• Concurrent logins (mobile/desktop/tablet) with synchronized displays.
• Hybrid: browser frontend javascript --> integrated to --> backend web server.
• Backend: IRC connections, IRC channel membership, and IRC message cache.
• Backend: HTTP Username/password login and session cookies.
• Frontend: Displays IRC messages, touch controls, and IRC text commands.
• Frontend: Compatible with voice dictation on smartphone (IOS).
• Frontend is native JavaScript using only browser APIs (No web frameworks)
• Browser Content Security Policy (CSP) enforced
• Implementation of CSRF tokens.
• TLS support for both Web Server and IRC server. Compatible with Lets Encrypt certificates.
• IRC server configuration JSON files are remotely configurable from the web interface.
• Capability to fall back to alternate nickname, option to auto-recover primary nickname
• Capability to auto-reconnect and/or rotate servers after disconnect
• Reference RFC 2812 However, not all features are implemented.

Program Limitations

• Color text not supported within chat (Color codes filtered to clean text)
• Message cache limited to 100 lines per IRC channel up to 5 channels (enough to ride out a smartphone screen lock)
• Message cache limited to 100 lines of private message (PM) combined for all active PM.
• Limited to one IRC user per nodejs/express instance. (i.e. Personal web server).
• This is a chat application, not a channel protection bot (no kick/ban enforcement)
• Development done in Chrome for Linux, and Chrome for IOS. Other browsers not tested.
• Development performed on DALnet, other IRC networks not tested.
• No automated tests are included.

Version v2.0.0 Upgrade (Sept 2023)

• Scope: Rewrite web browser HTML, JavaScript, CSS
• Reason: After 2.5 years of use, frustrating UI issues were identified.
• Previous browser code was difficult to edit. It was one very large JavaScript file, one HTML file.
• Coding goal: Split into modular web components, custom elements, shadow DOM
• Limits: No changes to backend API, or remote IRC client (Browser only change)
• Result: approximately 30 custom web components written, no framework used.
• General look and feel of the UI was maintained.
• More Info: See CHANGELOG.md v2.0.0 2023-09-12