In the modern digital landscape, the concept of privacy has fundamentally shifted from a luxury to an absolute necessity. At Sendly, we built our entire technical infrastructure around a simple, uncompromising principle: we do not want your data. While traditional cloud storage providers and file-sharing networks construct elaborate databases to index, analyze, and frequently monetize user uploads, Sendly operates as a strictly ephemeral, zero-knowledge transit layer. A zero-knowledge architecture means that our servers, our databases, and our administrative personnel are mathematically incapable of reading, deciphering, or intercepting the payloads you transmit through our platform.

This paradigm is achieved by shifting the cryptographic burden away from centralized servers and pushing it directly onto the edge—specifically, into the secure sandbox of your local web browser. By leveraging the native Web Crypto API available in all modern browsers, Sendly transforms your computer into a localized encryption fortress. The moment you drag and drop a file into our interface, the data never immediately begins uploading. Instead, the raw bytes are buffered into your system's Random Access Memory (RAM), where they await local transformation. This foundational approach ensures that even if our servers were entirely compromised by a malicious actor, the data resting on our temporary storage drives would remain completely illegible.

The cornerstone of Sendly's security model is the implementation of Advanced Encryption Standard with Galois/Counter Mode (AES-GCM) utilizing 256-bit keys. When a user elects to secure a transfer with a custom password, our client-side JavaScript engine intercepts the file before network transmission occurs. We utilize the Password-Based Key Derivation Function 2 (PBKDF2) algorithm, combined with a cryptographically secure pseudo-random salt generated locally via crypto.getRandomValues(). This process iterates thousands of times to stretch the human-readable password into a formidable 256-bit cryptographic key.

Once the key is derived, the AES-GCM cipher gets to work. Unlike older block ciphers like CBC, GCM provides authenticated encryption. This means it not only scrambles the file into unreadable ciphertext but also appends an authentication tag to the payload. When the receiver attempts to decrypt the file, the Web Crypto API verifies this tag first. If a single bit of the encrypted file was altered in transit—whether through a corrupted download or an intentional man-in-the-middle attack—the authentication tag will fail, and the decryption process will violently abort, guaranteeing data integrity. Because this entire sequence executes within the volatile memory of the sender and receiver's browsers, the plaintext password and the derived 256-bit key never traverse the internet.

For standard cloud-routed transfers (files up to 1GB), Sendly acts as a temporary holding zone. We recognized that forcing simultaneous online presence for file transfers can be impractical for distributed teams working across different time zones. Therefore, we utilize an ephemeral caching architecture. When an encrypted payload reaches our infrastructure, it is written to a volatile storage volume mapped directly to temporary directories.

Our garbage collection and data retention protocols are ruthlessly aggressive by design. The lifecycle of a hosted file is governed by two immutable conditions. First, the instant a recipient successfully downloads the payload using the single-use 6-digit access code, an automated web-hook triggers a hard-delete command on our server. The file is unlinked from the filesystem, and the sectors are immediately marked for overwrite. Second, we enforce a strict 10-minute Time-To-Live (TTL) timeout. If a file is uploaded but the recipient fails to claim it within this brief window, automated cron schedulers execute the same purge protocol. This ultra-short retention policy minimizes our attack surface area to near zero, ensuring that Sendly can never be utilized as a permanent cloud storage repository or a host for malicious, long-standing payloads.

While ephemeral cloud storage serves a vital purpose for asynchronous sharing, power users frequently need to transfer massive assets—such as raw 4K video files, compiled operating system binaries, or sprawling database dumps—without being bottlenecked by internet upload speeds or arbitrary server constraints. To solve this, Sendly engineered Local Drop, a localized, serverless file transmission system built entirely on raw WebRTC data channels.

WebRTC (Web Real-Time Communication) is a revolutionary open-source protocol originally designed for ultra-low latency voice and video streaming. Sendly repurposes WebRTC's RTCDataChannel interface to push binary file blobs. When two devices connect to the same localized Wi-Fi or Ethernet network and open the Local Drop interface, our lightweight signaling server is utilized purely as an introduction mechanism. The devices exchange Session Description Protocol (SDP) offers and Interactive Connectivity Establishment (ICE) candidates. These tiny metadata packets allow the two computers to discover each other's internal local IP addresses.

Once the subnet handshake is completed, the signaling server bows out, and a direct, peer-to-peer TCP/UDP socket is established between the sender and receiver. Because the binary data streams directly across your local network router—never touching our external servers or traversing your ISP's wide-area network—Local Drop imposes absolutely zero file size limitations. Transfers execute at the maximum theoretical limit of your internal network hardware, frequently exceeding Gigabit speeds. This architecture ensures complete local sovereignty over massive payloads.

Sendly's Screen Mirroring application adopts the same WebRTC peer-to-peer philosophy to provide zero-latency collaborative viewing without the need for cumbersome desktop software installations or invasive browser extensions. By calling the navigator.mediaDevices.getDisplayMedia() API, we prompt the user's operating system to grant sandboxed, temporary access to a specific application window, browser tab, or the entire desktop monitor.

This raw video feed is instantly encoded by the browser's hardware-accelerated media engine (typically VP8 or H.264) and piped directly into an active RTCPeerConnection. Similar to the Local Drop architecture, our Socket.io servers are utilized strictly for the initial STUN/TURN negotiation phase. Once the connection is dialed in, the high-bandwidth video stream flows directly from the presenter's GPU to the viewer's screen. This decentralized approach eliminates the "middleman" servers utilized by corporate video conferencing tools, slashing latency to single-digit milliseconds and dramatically reducing the CPU overhead required to maintain the stream.

A zero-knowledge system is only as secure as the environment in which it executes. Because Sendly pushes the heavy lifting of encryption and peer-to-peer signaling to the client side, maintaining the integrity of the browser environment is paramount. We accomplish this through a defense-in-depth strategy centered around modern web security standards.

Our application is strictly served over HTTPS, utilizing TLS 1.3 to ensure that the JavaScript payload delivered to your browser has not been tampered with in transit. We implement rigorous Content Security Policies (CSP) to neutralize Cross-Site Scripting (XSS) vectors, ensuring that unauthorized third-party scripts cannot be injected into our DOM to scrape memory or hijack Web Crypto API calls. Furthermore, for our offline developer suite—which includes the Diff Checker and JSON Formatting tools—all string manipulations and syntax tree calculations run entirely locally within your browser's V8 or SpiderMonkey JavaScript engine. None of your pasted code snippets or JSON payloads are ever dispatched to an external API for formatting, ensuring that sensitive environment variables or proprietary source code remain securely isolated on your local hardware.