Technology Behind mesibo

mesibo uses its own binary protocol optimized for ultra-low-overhead real-time communication. The networking stack is fully non-blocking and built around a custom lock-free epoll event loop designed for massive concurrency.

The engine uses modern Linux kernel features such as SO_REUSEPORT for multi-threaded high-performance socket handling, allowing worker threads to process connections independently with minimal synchronization overhead. Combined with lock-free data structures and CPU-local connection handling, this keeps per-connection overhead extremely low even at massive scale.

All networking is asynchronous. No thread blocks on socket I/O or inter-thread coordination in the critical path.

In addition to the mesibo protocol, mesibo supports HTTP/1.1, HTTP/2, WebSocket, and FastCGI for interoperability with external applications, webhooks, push notification services, APNs, and backend APIs. WebSocket traffic is automatically detected and multiplexed on the same port as native binary connections.

HTTP/2 support is provided through nghttp2, while HTTP/1.1 handling is mesibo's own. Earlier versions used libevent for parts of the asynchronous event layer, though the platform is progressively moving entirely to the native I/O engine.

TLS for all connections is handled by OpenSSL. For on-premise deployments, mesibo includes an integrated ACME client that automatically provisions and renews TLS certificates without requiring external tooling or manual intervention.

End-to-end encryption is implemented entirely in the client SDKs. Encryption keys are generated and stored on the device and never leave it. mesibo servers only transport encrypted payloads as opaque binary data and cannot decrypt message contents.

mesibo uses MariaDB and MySQL as the primary persistent storage layer. The database is used for account management, metadata, configuration, message persistence, and backend integrations, while latency-sensitive routing and session management remain entirely in-memory within the core engine.

The database layer is designed around asynchronous operation and minimal contention, with the messaging engine avoiding synchronous database access in the critical path wherever possible. mesibo also includes its own native MySQL/MariaDB client implementation optimized for non-blocking operation and tight integration with the internal event engine.

mesibo processes images server-side for profile pictures, thumbnails, and rich message previews. This uses a stack of established open source libraries rather than a mesibo implementation — the problem is well-solved and the risk/benefit of building alternatives is unfavorable.

libgd provides image creation and transformation. libpng and libjpeg-turbo handle their respective formats. FreeType is used for font rendering, under its permissive FreeType License (not GPL).

Most mesibo client SDKs are built on top of a common high-performance C++ runtime and API layer shared across platforms. Native platform bindings are then provided for Android (Java/Kotlin), iOS (Swift/Objective-C), Python, and direct C++ integration. JavaScript is the only major SDK that does not use the shared native runtime.

This architecture keeps most protocol handling, networking, encryption, synchronization, and messaging logic common across platforms while preserving native APIs and platform integration layers. As a result, API signatures remain highly consistent across platforms, and new features, protocol updates, performance improvements, and bug fixes propagate uniformly with minimal platform-specific divergence or maintenance overhead.

The client-side storage layer uses SQLite for local persistence, caching, and offline synchronization instead of MySQL/MariaDB used on the server side.