feat: WebRTC P2P File Sharing & Chat Application (ShareIt) at /shareit

[Abhay2133]

Feature Request: WebRTC P2P File Sharing & Chat Application (ShareIt)

Summary

Implement a secure, direct peer-to-peer file sharing and chat feature within the application. Users should be able to access this at the /shareit path. Peer discovery and signaling will occur via WebSockets (with no backend database persistence), and the actual data/file transfer will happen directly between browsers using WebRTC. Chats and contact logs will be stored locally on the client using in-browser storage.

---

Core Requirements & Specifications

1. Routing & Layout

• Path: Implement under the /shareit path.
• Access: Accessible without authentication (no login required for now).
• Interface: A clean, responsive, WhatsApp-like interface featuring:
  • A sidebar list of discovered/connected peers.
  • A main chat window for the selected peer.
  • File sharing action buttons (drag-and-drop or select file) integrated directly into the chat interface.

2. Peer Discovery & Signaling (WebSocket)

• No Database Persistence: The backend should run purely in-memory (ephemeral) for tracking online sockets.
• WebSocket Signaling: Use WebSockets to announce presence and exchange WebRTC connection offers, answers, and ICE candidates between peers.
• Automatic Matching: Automatically show peers connected on the same server, or enable room-based matching.

3. Direct File Sharing (WebRTC)

• WebRTC Data Channel: Use RTCDataChannel to send data directly between browsers.
• Online Restriction: Transfers should occur only when both peers are online.
• STUN/TURN Fallback: Configure standard public STUN servers (e.g., Google's public STUN servers) and prepare a configuration slot for a TURN server in case of symmetric NATs.

4. Local Chat & History (In-Browser Storage)

• Chats Persistence: Messages and chat histories must be saved locally per peer using in-browser storage (e.g., IndexedDB via Dexie.js or localForage) so that chat histories remain accessible across browser refreshes.
• No User Login: Use generated ephemeral user names (or custom display names) and store the local peer identity in LocalStorage.

---

Suggested & Good-to-Have Features (Research-Backed)

To make the P2P experience premium and robust, the following features are suggested for implementation:

1. Chunked File Transfer & Progress Tracking

• Chunking: Chunk large files (e.g., in 16KB/64KB blocks) during transfer over RTCDataChannel to avoid browser buffer overflow.
• Progress UI: Display real-time progress indicators (progress bar, transfer speed in MB/s, and ETA) for both sending and receiving files.

2. Remote Peer Connections (Room Links & QR Codes)

• QR Code/Link sharing: In addition to automatic local matching, allow users to generate a temporary link/QR code to share with remote peers. Scanning the QR code or clicking the link joins the matching room immediately.

3. File Previews & Metadata

• Previews: Render image thumbnails, audio player previews, or document type icons (PDF, ZIP, etc.) inside the chat bubbles before or during download.
• Metadata Exchange: Send metadata (filename, size, MIME type) first and prompt the recipient to accept/decline the file transfer before starting the download.

4. Ephemeral Message Controls (Ghost Chat)

• Self-Destructing Messages: Option to enable self-destructing/ephemeral messages that delete themselves from the local IndexedDB after being viewed or when the session ends.

5. Desktop Notifications & Sound Alerts

• Alerts: Trigger subtle sound effects or standard browser push/desktop notifications when a new peer connects, a message is received, or a file transfer completes successfully.

6. Multiple Files Transfer Queue

• Queuing: Support selecting and queuing multiple files at once, transmitting them sequentially to prevent channel congestion.