Real-time conversations can become unreliable when connectivity changes, and collaboration needs more than plain text delivery. FluxChat keeps a local pending-message queue, waits for server acknowledgements, and restores queued sends in order after reconnection while supporting rooms, direct messages, media, search, roles, and moderation.
Real-Time ApplicationLive
FluxChat
An offline-first real-time chat application with rooms, direct messages, media sharing, moderation, search, and browser-based delivery queues.
FluxChat
ConversationsPProduct team1AAlex2DDesign room3
Details6 members
About FluxChat
FluxChat combines public and password-protected rooms, one-to-one messages, rich message interactions, media sharing, moderation tools, and searchable conversation history. IndexedDB caches messages and pending sends in each browser so queued messages can be delivered automatically after connectivity returns.
Product thinking
Challenge and approach
Outgoing messages first enter IndexedDB with pending status. The Socket.IO server validates the current socket and membership, stores the message in memory, broadcasts it, and acknowledges delivery. Offline messages remain queued locally and are resent in order after reconnection.
Capabilities
Main features
Public or password-protected rooms and direct messages
Presence, typing indicators, unread badges, and read receipts
Replies, forwarding, editing, deletion, reactions, and pinned messages
Images, documents, voice messages, screen captures, and URL previews
Conversation and global search with paginated history
Owner, administrator, moderator, and member controls
Architecture
How the system is structured
- 01
Next.js and React provide the chat interface while a custom Node.js server attaches Socket.IO to the Next.js request handler.
- 02
Server memory holds users, profiles, rooms, memberships, and messages; the application does not currently require a database.
- 03
IndexedDB stores each browser's message cache and pending delivery queue.
- 04
Validated uploads are written to the application host's public/uploads directory.
Implementation
Technology and data
Technology stack
- Next.js
- React
- Node.js
- Socket.IO
- IndexedDB
- MediaRecorder
- getDisplayMedia
Engineering details
Technical considerations
SecurityAccess and validation safeguards
- Sender identity is derived by the server rather than trusted from message payloads.
- Membership checks protect history, search, forwarding, and direct-message operations.
- Frequently used Socket.IO events have per-socket rate limits and production origins are restricted.
- Upload endpoints validate extensions and MIME types, randomize filenames, and return hardened response headers.
ReliabilityRecovery and cleanup
- IndexedDB-backed pending queue with automatic ordered resend
- Socket acknowledgements distinguish pending and delivered messages
- Paginated history keeps initial room payloads bounded
- Inactive empty rooms are eligible for cleanup after a grace period
Current scopeKnown limitations
- Rooms, identities, roles, bans, pins, and messages are lost when the server process restarts.
- Local uploaded files require persistent writable hosting and may disappear on ephemeral deployments.
- Usernames are local identifiers rather than authenticated, durable accounts.
- Room passwords are in-memory access gates, and messages are not end-to-end encrypted.
- Multi-instance deployments require shared persistence and distributed rate limiting.
- Video-call invitations open the separate hosted WebRTC application.
Use cases
What the project supports
- Run real-time room and direct-message conversations
- Continue composing messages while temporarily offline
- Share documents, images, voice messages, and screen captures
- Moderate rooms with roles, bans, ownership transfer, and message controls