POSIX C written telegram clone (github.com)

Introducing Hubbergram — a lightweight, secure messaging server with a CLI client, built using POSIX-compliant C.

Check it out: hubbergram GitHub Repository Huge thanks to Danyyil Serpokrylov for his external support in implementing POSIX compatibility. His contributions made it seamless to integrate the messaging server without encountering header-related build issues.

In an era where messaging security is paramount, I built Hubbergram - a lightweight, secure messaging server that demonstrates how to implement enterprise-grade security features in C. This isn't just another chat application; it's a comprehensive system showcasing modern security practices, encrypted storage, and clean architecture patterns.

Why C for a Messaging Server?

While most developers reach for Node.js, Python, or Go for web services, C offers unique advantages: Performance: Direct memory management and minimal overhead. Security: Full control over data handling and memory allocation. Learning: Understanding low-level networking and system programming. Portability: Runs efficiently on embedded systems and servers alike.

Architecture Deep Dive

The system follows a layered architecture pattern with clear separation of concerns:

Client Layer

CLI Client: Interactive command-line interface for users HTTP Client: Handles REST API communication and JWT token management Security Layer

CORS Protection: Prevents unauthorized cross-origin requests JWT Authentication: Stateless tokens with 24-hour expiry SHA256 Hashing: Secure password storage with salt Server Layer

Multi-threaded HTTP Server: Handles 100+ concurrent connections API Router: Clean endpoint routing (/api/register, /api/login, etc.) Controllers: Separate logic for authentication, messaging, and location services Data Layer

Database Encryption: Custom encryption with auto-generated keys SQLite Storage: Lightweight, embedded database Structured Tables: Users, messages, and groups with proper relationships Key Security Features

Database Encryption // Auto-generated encryption key per installation void generate_db_key() { unsigned char key[32]; RAND_bytes(key, sizeof(key)); // Obfuscated storage in header files }

JWT Token Management

24-hour automatic expiry

Secure token validation on every request

Role-based access control (user/admin)

Privacy-First Location Sharing

Explicit user consent required

Admin monitoring with proper authorization

GPS coordinates with consent management

Technical Implementation Highlights

Multi-threaded Server Architecture The server uses POSIX threads to handle concurrent connections efficiently:

// Simplified server structure void* handle_client(void* client_socket) { // Process HTTP requests // Route to appropriate controllers // Return JSON responses }

RESTful API Design Clean, intuitive endpoints following REST principles:

POST /api/register - User registration POST /api/login - Authentication POST /api/message - Send messages GET /api/messages - Retrieve message history POST /api/location - Update location (with consent) GET /api/locations - Admin location monitoring Cross-Platform Compatibility Supports multiple environments:

Windows: MSYS2 with MinGW Linux: Ubuntu, CentOS, RHEL macOS: Homebrew dependencies Building and Deployment

The build system uses Make with automatic dependency management:

One-command build with dependencies make all

Automatic library installation make install-libmingw32

CLI client build make -f Makefile_cli

Security Best Practices Implemented

Password Security: SHA256 hashing with proper salt handling Session Management: JWT tokens with automatic expiry Data Encryption: SQLite database with custom encryption Input Validation: Proper sanitization of all user inputs Rate Limiting: Protection against brute force attacks CORS Protection: Secure cross-origin request handling Real-World Applications

This architecture pattern is...