This is an Ansible role and playbook collection that automates the hardened installation of the OpenClaw messaging gateway on Debian/Ubuntu Linux systems. It provisions a dedicated system user, installs Docker CE with UFW-based firewall and DOCKER-USER chain isolation, configures fail2ban and unattended-upgrades, sets up Node.js and pnpm, and installs OpenClaw either from npm (release mode) or from a Git checkout (development mode). The role does not configure the application or install its systemd service—those steps are left to the operator via `openclaw onboard --install-daemon`. It supports remote deployment via inventory and includes CI tests for syntax, linting, and integration. The codebase is well-structured, security-conscious, and actively maintained, though it does not contain independently extractable components suitable for reuse outside this project.
This repository is a JavaScript library providing a BroadcastChannel polyfill with leader election capabilities. It enables cross-tab/window/node-process communication through multiple fallback mechanisms (native BroadcastChannel, IndexedDB, localStorage, Node.js sockets, and a simulate method). The library implements leader election algorithms to coordinate multiple instances, ensuring only one acts as leader at a time. It supports diverse environments including old browsers, modern browsers, WebWorkers, Node.js, Deno, and iframes. The architecture centers around a core BroadcastChannel class with pluggable method implementations, a method chooser for fallback selection, and separate leader election utilities. Key entry points are the exported BroadcastChannel class and createLeaderElection function from src/index.js.
Berty is a full-stack, privacy-focused, peer-to-peer messaging application. The system consists of a Go backend implementing the Wesh protocol (based on IPFS, libp2p, and OrbitDB) that provides core messaging, push notifications, authentication, replication, and directory services. The backend is exposed via gRPC and consumed by multiple clients: a React Native mobile app (with both a legacy JS variant and a newer Expo-based variant), a Go CLI with a terminal UI (mini) and a desktop GUI (Fyne), and native bridges for iOS and Android. The architecture is modular, with separate packages for error handling, authentication, push relay, and bot framework. Key entry points include the `berty daemon` CLI command, the mobile app entry points (`App.tsx` in both `js/packages` and `berty-bridge-expo/mobile`), and the bridge framework (`go/framework/bertybridge`). Data flows involve gRPC streams from the Go backend to the mobile clients, with event-driven state management and local encrypted storage via SQLCipher. External dependencies include libp2p, OrbitDB, gRPC, protobuf, and various platform-specific native modules for BLE, mDNS, and push notifications. The repository also contains auxiliary tools for infrastructure testing, rendezvous servers, and debugging (Tyber).
Linphone Desktop is a production-grade, cross-platform SIP softphone built on the Linphone C++ SDK and wrapped in a Qt6/QML user interface. It delivers audio/video calls, instant messaging (including group chat, file transfer, reactions, and ephemeral messages), conference scheduling, call recording, and presence management across Windows, macOS, and Linux. The architecture follows a strict MVVM split: model classes run on the Linphone SDK thread and expose Qt signals, while GUI-facing 'Core' classes live on the main thread and communicate with models via a custom SafeConnection template that enforces thread affinity. QML views bind directly to these cores, with list proxies (e.g., ListProxy, SortFilterProxy) providing paginated, filterable models for contact lists, call history, and chat logs. The codebase also integrates advanced features like OIDC/OAuth authentication, LDAP/CardDAV address book sync, end-to-end encryption (LIME/DTLS/SRTP), and system-level integrations (toast notifications, tray icons, screen-sharing, autostart) with per-platform backends. The repository is actively maintained with a modern build system (CMake), comprehensive GitLab CI pipelines (Linux, macOS, Windows, Squish GUI tests), and a substantial localization effort (multiple .ts files).
This is the OCA/social repository, a collection of 15 Odoo addon modules for Odoo 18.0 that extend the Odoo Discuss and mail systems with external messaging integrations and social profile features. The core module, `mail_gateway`, provides an abstract framework for integrating external chat platforms (Telegram, WhatsApp, Instagram) into Odoo Discuss via webhooks, enabling bidirectional communication. Concrete gateway modules (`mail_gateway_telegram`, `mail_gateway_whatsapp`, `mail_gateway_instagram`, and `mail_gateway_telegram_standalone`) implement provider-specific APIs, including message sending, template management (WhatsApp), and webhook verification. Additional modules add social media profile fields to partners and companies (LinkedIn, Mastodon), audit activity cancellations and unlinks, control mention suggestions, route unhandled emails to a default thread, and extend marketing campaigns with budget tracking. The repository follows standard OCA addon structure with Python models, XML views, OWL/JavaScript component patches, wizards, security rules, and translations. It is not a standalone application but a set of modules designed to be installed in an Odoo instance.
This is a monorepo for the Ember.js-based encrypted chat application 'emberclear', which provides end-to-end encrypted messaging with no server-side message storage. The architecture is modular, consisting of multiple Ember addons (crypto, networking, local-account, UI, test-helpers, tracked-local-storage) and a separate card game app (pinochle) that reuses the same networking and crypto infrastructure. The chat app uses public-key cryptography (tweetnacl, libsodium) via web workers, relays messages through Phoenix WebSocket relays, and persists data locally via IndexedDB and localStorage. It includes features like QR code identity sharing, channel voting with cryptographic chains, and a state-machine-driven setup wizard. The codebase is well-tested with QUnit, acceptance tests, and smoke tests, but shows signs of technical drift with outdated dependencies (Node 14, Ember 3.26.1), many TODO comments, and incomplete features (e.g., voting, QR login transfer). The pinochle game app appears experimental but demonstrates sophisticated state machine usage and animation systems.
GoBelieveIO/im_service is an instant messaging (IM) server infrastructure implemented in Go. It provides real-time peer-to-peer messaging, group chat (including super groups for large audiences), and chat rooms. The system is designed for clustered deployment and consists of three separate processes: `im` (access server handling client TCP/WebSocket connections), `ims` (storage server using append-only file logs with in-memory indexes), and `imr` (router server coordinating message delivery between access servers). Authentication is token-based (Redis or JWT). Message storage is per-user file-based with efficient offline message synchronization via sync keys. The codebase includes a custom binary protocol over TCP/WebSocket, a Redis-backed pub/sub mechanism for group events and relationship changes, and MySQL for group and friend data. This is a production-grade system (as indicated by its star count) with comprehensive benchmark tools and Python integration tests. However, the repository appears to be in a maintenance-stale state with no recent commits and some deprecated message types.
This repository implements a Windows DLL (version.dll) that uses DLL proxy injection to hook into the WeChat desktop client (x64, version 4.1.x). Once injected, it launches a local HTTP server on port 30001 that exposes a REST API for automating WeChat operations: sending text/image/XML messages, forwarding messages, decoding encrypted image caches, querying the user's profile, and executing arbitrary SQL on WeChat's internal SQLite databases (e.g., MicroMsg.db). The architecture is a monolithic DLL with several layers: a proxy DLL loader (version_proxy.cpp), a custom x64 hooking framework (Hook_Method.cpp) using MinHook and assembly trampolines, a set of WeChat interface implementations (wx_send.cpp, wx_send_xml.cpp, etc.) that construct internal WeChat objects using known memory offsets, and an HTTP server (http_server.cpp) built on the vendored cpp-httplib library. The project also includes a database access module (xdb/db_mgr.cpp) that scans WeChat's memory for SQLite3 API routines and executes queries directly, bypassing the need for external database drivers. External dependencies include MinHook (bundled), cpp-httplib (vendored), LZ4 compression library, and nlohmann/json. The code is heavily tied to specific WeChat version offsets and memory layouts, making it fragile across WeChat updates, but the project's update log shows active adaptation to new versions.
Franz is a desktop messaging aggregator that consolidates multiple chat services (WhatsApp, Slack, Telegram, etc.) into a single Electron application. It uses a plugin-based 'recipe' system to integrate each service via webviews or BrowserViews. The architecture is a monorepo with Lerna, containing reusable packages for UI components, forms, and theming. The main application is built with React 16, MobX 5, and JSS for styling, with a MobX store layer managing state and API calls. Features include service management, workspaces, todos, subscription tiers (freemium), and a feature toggle system. The codebase is well-structured but shows signs of age: it uses deprecated React lifecycle methods, @electron/remote, and outdated dependencies. The README explicitly states this is the predecessor of Franz 6 and is no longer actively developed, making it a legacy codebase.