Just spent the morning fixing a frustrating test suite failure in OrbitOS, our open-source web-based operating system. The issue was classic - framer-motion components breaking Jest tests with the dreaded "Element type is invalid" error. For anyone building complex React UIs with animations, this might be useful.
We're building OrbitOS (https://github.com/codehubbers/OrbitOS) - essentially a desktop operating system that runs entirely in your browser. Think Windows 95 meets modern web tech. The project includes draggable windows, snap-to-edge functionality (like Windows Aero Snap), a taskbar with live clock, built-in apps (calculator, notes, file manager), and a full theming system. It's been a fun challenge pushing the boundaries of what's possible with React and modern browser APIs.
The window management system uses framer-motion for smooth animations - windows scale in/out when opening/closing, drag with momentum physics, and snap to screen edges with visual previews. Everything worked perfectly in development, but our CI pipeline was consistently failing because Jest couldn't understand framer-motion's custom components like motion.div and AnimatePresence. When Jest tries to render these in its JSDOM environment, it gets undefined instead of actual components.
The fix was creating proper Jest mocks that preserve the component structure while eliminating the animation complexity that Jest struggles with. Instead of just mocking framer-motion to return empty objects, I mapped motion.div to regular div elements and made AnimatePresence a transparent wrapper that just renders its children.
The interesting part was maintaining test coverage for the actual window management logic. Our tests simulate real user interactions - mousedown on title bars, mousemove to screen edges, mouseup to trigger snapping. We test all the snap zones (left/right halves, quarter-screen corners, maximize on top edge) and edge cases like rapid mouse movements and zero-dimension windows. The mocking strategy preserves all this functionality while just stripping away the animation layer.
The window snapping algorithm itself is pretty neat - we calculate snap zones based on cursor proximity to screen edges with different thresholds for corners vs edges. The state management uses React Context with a reducer pattern to handle multiple windows, z-index ordering, and position/size tracking.
One thing that surprised me was how well modern browser APIs work for desktop-class interactions. We're using ResizeObserver for responsive window content, IntersectionObserver for taskbar auto-hide, and the Pointer Events API for handling both mouse and touch interactions. The File System Access API (where supported) even lets us save/load actual files to the user's computer from our web-based apps.
The project is completely open source and we're actively looking for contributors. If you're interested in systems programming, UI/UX design, or just want to see how deep the rabbit hole goes with modern web APIs, check out the repo at https://github.com/codehubbers/OrbitOS. We have good first issues tagged for newcomers, and the codebase is well-documented with architectural decision records explaining why we chose certain approaches.
Would love to hear from anyone else working on desktop-class web applications or dealing with similar testing challenges around animation libraries. Also curious about performance optimization strategies for complex React UIs - we've learned some hard lessons about what works and what doesn't when you're trying to maintain 60fps with multiple draggable windows.
The testing infrastructure we built could probably be extracted into a separate library for anyone dealing with similar framer-motion + Jest issues. Let me know if there's interest in that or if you want to dive deeper into any of the technical details.
I’ve been working on a personal project called Dragon’s Vault, a web-based encrypted chat platform built from the ground up with zero-trust architecture. The core idea is simple but ambitious: even if the server or database is compromised, your messages should remain completely unreadable.
The system uses multi-layer client-side encryption: AES-256-GCM for the first layer, XChaCha20-Poly1305 for the second, and RSA/ECC for key exchange. Everything happens in the browser: the server only ever sees encrypted blobs. Even metadata like timestamps and usernames are encrypted, and encryption keys are stored securely in IndexedDB.
Fully responsive design for desktop, tablet, and mobile
From a development perspective, the project is built with Next.js, a MongoDB backend, and client-side cryptography libraries. There are clear abstractions for encryption, key storage, and authentication, making it easy for contributors to pick up and extend features.
I’m sharing this here because I’m looking for:
Feedback – on the security model, UX, and overall architecture
Feature ideas – are there ways to make encrypted social chat more usable without compromising security?
Contributions – anyone who wants to help improve code, add features, or enhance security documentation
I’ve put a lot of thought into balancing strong encryption with usable social features, but this is very much a work in progress. I’d love to hear from anyone interested in privacy-first messaging or client-side encryption. Even small contributions, security reviews, or suggestions are incredibly valuable.
I want to share everyutil-c, a C utility library aimed at filling in gaps beyond the C standard library, with performance, modularity, and cross-platform consistency as first-class requirements. Below are some of the technical design decisions, recent improvements, and open areas where I’d love feedback or contributions.
Everyutil-C is meant as a “standard library extension” for C projects — lightweight, dependency-minimal, and structured so you can pull in only what you need. Key subsystems include:
4. wrapping malloc/free with alignment options, optional debugging hooks, etc.
5. handling Windows vs POSIX differences, proper __declspec(dllexport) stuff, platform detection, conditional compilation.
Recent Technical Milestones
1. Improved performance of iteration (fewer bounds checks, perhaps more inlining).
2. clearer ownership semantics, avoidance of buffer overruns in growth/resizing.
3. cleaner internal structure, possibly splitting core and helper functions so that the minimal subset (e.g. fixed-size dynamic arrays) can be used without pulling in everything.
4. Support for Make, Autotools, and CMake so as to integrate with different build pipelines.
build.sh script to automate configuration, especially helpful on MSYS2/Windows, where toolchain quirks (path separators, runtime linking, DLL visibility, etc.) can be a headache.
Proper handling of DLL exports on Windows; ensuring symbols are exported appropriately, avoiding linker errors.
Testing & correctness
Full test suite covering edge cases (zero length, null pointers, huge sizes, overflow).
Cross-platform tests to verify behavior is consistent on Linux, macOS, Windows.
Automated CI likely (or recommended) to verify builds under different compilers (gcc, clang, MSVC or mingw).
Technical Trade-offs & Design Choices
Some of the tricky technical decisions/constraints and how I addressed (or plan to address) them:
Minimal dependencies vs feature richness. I avoid bringing in large external libraries; aim is to stay in “pure C99 (or close)” so users don’t have to link dozens of other libs.
Memory allocation strategies: resizing vs doubling, growth factors, freeing, fragmentation. Trying to keep it reasonable without over-engineering.
Symbol visibility & binary interfaces: ensuring that the API headers are stable, and that users who build shared libs / static libs get consistent behavior. Handling extern "C" for C++ usage, etc.
Portability quirks: Windows’ path handling, _snprintf vs snprintf, difference in size_t, alignment issues; ensuring macros / config headers detect and adapt.
What I’m seeking feedback on
Are there any missing utility subsystems people commonly need in C that would integrate well here (e.g. logging, formatting, serialization)?
How do people prefer safe vs unsafe APIs: do you want always safe, or ability to sacrifice safety for speed?
What patterns for versioning/stability are helpful: semantic versioning, API deprecation path, binary compatibility?
Experiences integrating similar libraries (stb, klib, GLib, etc.): what patterns or pitfalls do you want to avoid?
Suggestions around documentation / API specification style: inline comments, header docs, external reference, examples.
Regarding documentation, comments in tens of .h files in third level directories are very user unfriendly, regardless of their quality (which seems fairly good).
You need:
1) an overview of the available functionality, design choices, aspects that need feedback and contributions etc.
2) a guide of what headers every function or macro is located in (consider fragmenting headers less, possibly adding "umbrella" headers that just include a set of the current headers that is likely to be used together)
I’ve been working on a C utility library called everyutil-c over the past few months, and wanted to finally share it here. It's a lightweight but powerful collection of utility functions, designed with performance, clarity, and portability in mind.
A few things we focused on:
Clean, well-documented API
Modular components (pull in only what you need)
Full test coverage
Easy builds: works out of the box with Make, Autotools, or CMake
Cross-platform: Linux, macOS, and Windows (with proper DLL export handling)
New build.sh script for smoother setup, especially in environments like MSYS2
We recently rewrote the array utilities for better performance and maintainability, which felt like a good milestone to share this more broadly.
If you use C regularly (or even just occasionally), I’d really love to hear your feedback. What do you value most in a utility lib? Have you run into issues when integrating small C libraries into larger projects—especially when dealing with multiple platforms or compilers?
Also curious: if you’ve used other libraries like stb, klib, or GLib, what worked for you and what didn’t?
Feedback, ideas, bug reports, feature requests—all are welcome. Repo link is in the comments if you want to check it out or contribute.
The lack of API doc's for the c version is kind of frustrating. It makes it impossible for someone to evaluate whether or not your library is suitable for something they need. Or if it is, how to use properly.
everyutil-c is a modern, modular C utility library crafted to provide a wide collection of robust, reusable functions that simplify everyday low-level programming tasks across platforms. It acts as a “standard library extension,” bundling together well-tested logic for common needs such as array manipulation, string processing, number utilities, and more all with performance and portability in mind. The API is intentionally designed to be clean and intuitive, exposing clearly documented headers and consistent function signatures, making it easy to drop into existing projects. Under the hood, the implementation emphasizes speed and reliability, with careful memory handling and minimal external dependencies. The library is thoroughly tested using a dedicated test suite to ensure correctness and stability across use cases. everyutil-c supports multiple build systems Makefiles, Autotools, and CMake and provides an automated build.sh script that can even fetch dependencies and configure environments like MSYS2 on Windows. Recent enhancements include a major refactor of array utilities (e.g., more efficient iteration, memory-safe operations), improved build scripts, and better platform abstraction.
*everyutil-js is JavaScript version of it (identically clone)
Hey HN! Over the past few months, I’ve been building a C utility library called everyutil-c, aimed at providing a robust, high-performance set of logic and utility functions with an emphasis on clean design and cross-platform support. It includes a well-documented API, a comprehensive test suite, and flexible build options—Makefile, Autotools, and CMake are all supported out of the box. We also made sure to handle Windows builds via DLL export, alongside full support for Linux and macOS.
We recently hit a milestone with a refactor of our array utilities for better performance and maintainability, and rolled out a build.sh script to make getting started a lot smoother—especially for folks working in MSYS2 or on platforms where toolchains can get messy. The library is fully modular, with functions separated into reusable components, and we’ve put a lot of effort into keeping things simple without sacrificing flexibility or efficiency.
If you're a C developer (or even dabble in C occasionally), I’d love to get your thoughts. What do you usually look for in a utility library? Are there any pain points you run into when trying to integrate small helper libraries into bigger projects—especially across platforms? Also curious if you’ve had good or bad experiences with other utility libs like GLib, klib, or stb, and what we could learn from those. All feedback is welcome, and if you're up for it, PRs and issues are open too. Repo link in the comments!
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
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 suitable for:
IoT Messaging: Lightweight messaging for embedded systems
Enterprise Chat: Internal communication with security requirements
Educational Projects: Learning system programming and security
Microservices: Base for larger distributed systems
Performance Characteristics
Memory Usage: ~2MB base footprint
Concurrent Users: 100+ simultaneous connections
Response Time: <10ms for typical operations
Database Size: Efficient SQLite storage with encryption overhead
Lessons Learned
Security by Design
Implementing security from the ground up is easier than retrofitting. The encryption key generation and JWT implementation were built into the core architecture.
C for Web Services
While challenging, C provides unmatched control over system resources and security. The learning curve pays off in performance and understanding.
Clean Architecture Matters
Separating concerns into distinct layers made the codebase maintainable and testable, even in C.
Future Enhancements
WebSocket Support: Real-time messaging without polling
File Sharing: Encrypted file transfer capabilities
Group Messaging: Enhanced group management features
Mobile Clients: Native iOS/Android applications
Federation: Inter-server communication protocol
Conclusion
Hubbergram demonstrates that C remains relevant for modern web services, especially when security and performance are priorities. The project showcases: Modern security practices in systems programming. Clean architecture patterns in C. Cross-platform development techniques. Real-world application of cryptographic principles.
The complete source code and documentation are available on GitHub, providing a solid foundation for anyone interested in systems programming, security implementation, or building messaging systems from scratch.
Whether you're a student learning systems programming or a developer exploring low-level web services, Hubbergram offers practical insights into building secure, performant applications in C.
Technical Stack: C, SQLite, JSON-C, OpenSSL, JWT, SHA256, POSIX Threads
Platform Support: Windows (MSYS2), Linux, macOS
License: MIT
Repository: https://github.com/codehubbers/hubbergram
We're building OrbitOS (https://github.com/codehubbers/OrbitOS) - essentially a desktop operating system that runs entirely in your browser. Think Windows 95 meets modern web tech. The project includes draggable windows, snap-to-edge functionality (like Windows Aero Snap), a taskbar with live clock, built-in apps (calculator, notes, file manager), and a full theming system. It's been a fun challenge pushing the boundaries of what's possible with React and modern browser APIs.
The window management system uses framer-motion for smooth animations - windows scale in/out when opening/closing, drag with momentum physics, and snap to screen edges with visual previews. Everything worked perfectly in development, but our CI pipeline was consistently failing because Jest couldn't understand framer-motion's custom components like motion.div and AnimatePresence. When Jest tries to render these in its JSDOM environment, it gets undefined instead of actual components.
The fix was creating proper Jest mocks that preserve the component structure while eliminating the animation complexity that Jest struggles with. Instead of just mocking framer-motion to return empty objects, I mapped motion.div to regular div elements and made AnimatePresence a transparent wrapper that just renders its children.
The interesting part was maintaining test coverage for the actual window management logic. Our tests simulate real user interactions - mousedown on title bars, mousemove to screen edges, mouseup to trigger snapping. We test all the snap zones (left/right halves, quarter-screen corners, maximize on top edge) and edge cases like rapid mouse movements and zero-dimension windows. The mocking strategy preserves all this functionality while just stripping away the animation layer.
The window snapping algorithm itself is pretty neat - we calculate snap zones based on cursor proximity to screen edges with different thresholds for corners vs edges. The state management uses React Context with a reducer pattern to handle multiple windows, z-index ordering, and position/size tracking.
One thing that surprised me was how well modern browser APIs work for desktop-class interactions. We're using ResizeObserver for responsive window content, IntersectionObserver for taskbar auto-hide, and the Pointer Events API for handling both mouse and touch interactions. The File System Access API (where supported) even lets us save/load actual files to the user's computer from our web-based apps.
The project is completely open source and we're actively looking for contributors. If you're interested in systems programming, UI/UX design, or just want to see how deep the rabbit hole goes with modern web APIs, check out the repo at https://github.com/codehubbers/OrbitOS. We have good first issues tagged for newcomers, and the codebase is well-documented with architectural decision records explaining why we chose certain approaches.
Would love to hear from anyone else working on desktop-class web applications or dealing with similar testing challenges around animation libraries. Also curious about performance optimization strategies for complex React UIs - we've learned some hard lessons about what works and what doesn't when you're trying to maintain 60fps with multiple draggable windows.
The testing infrastructure we built could probably be extracted into a separate library for anyone dealing with similar framer-motion + Jest issues. Let me know if there's interest in that or if you want to dive deeper into any of the technical details.