FastFileLink Technical FAQ

Posted on 週一 20 十月 2025 in Blog

Welcome to our Technical FAQ section!

Here you can find answers to technical questions about our service. If you’re looking for common information, please check out our FAQ.

Content

Q1. What is P2P (Peer-to-Peer), Device-to-Device, or "Directly Share" in FastFileLink?

P2P (Peer-to-Peer), or Device-to-Device, is a method of sharing files directly between two computers over the internet without needing to upload the file to a central server first. When you use FastFileLink's "Directly share file (P2P) by local" option, your computer connects directly to the recipient's computer.

WebRTC

This process often utilizes web technologies like WebRTC (Web Real-Time Communication), which enables browsers and applications to establish direct communication channels. This means the file data travels from your device to the recipient's device, making the transfer potentially faster and more private as it doesn't rely on an intermediary server storing the file.

For more information on WebRTC, you can visit the WebRTC project website or its Wikipedia page. A key security feature of FastFileLink is that your own computer acts as its own signal server to establish the connection (see Q7 for more details), meaning no third-party server is involved in brokering the initial P2P handshake, further enhancing your privacy.

Q2. What is Relayed P2P? How does FastFileLink handle connection issues?

Sometimes, a direct P2P connection isn't possible. This can happen due to network configurations like certain types of NAT (Network Address Translation) or restrictive firewalls/ports that block direct connections.
In such cases, FastFileLink uses a fallback mechanism called Relayed P2P. Instead of your file going through a generic WebRTC TURN server, FastFileLink will use its own dedicated relay server. This server acts as a go-between:

  • It uses port 443, the standard port for HTTPS/SSL traffic. This port is rarely blocked, ensuring a very high connection success rate even in restricted network environments.
  • The relay server only forwards data (socket-to-socket) between your computer and the recipient's.
  • Crucially, our relay server does not store any intermediate data or your files. It also keeps no logs of the transfer content, ensuring your privacy is maintained during the relay process.

Q3. What is NAT (Network Address Translation) and how does it affect FastFileLink?

NAT (Network Address Translation) is a method used by routers to allow multiple devices on a private network (like your home or office) to share a single public IP address when accessing the internet. You can think of it as a receptionist for your network, directing internet traffic to the correct device.

For more details, see the Wikipedia article on NAT. While NAT is essential, it can sometimes make direct P2P connections tricky because devices are hidden behind this shared IP. Technologies like WebRTC (used in our P2P sharing) have built-in mechanisms (like STUN/ICE) to discover the public IP address and attempt to establish direct connections even through many types of NAT. However, some NAT configurations are more restrictive. This is where FastFileLink's Relayed P2P feature becomes vital. By using our relay servers on port 443, we can achieve a very high connection reliability (e.g., around 99.9%), bypassing most NAT-related P2P connection issues.

Q4. What is "Resuming Download" or Continuation Transfer?

FastFileLink supports "Resuming Download" or Continuation Transfer, and we've put significant effort into making this robust.

  • During P2P Transfers: If a direct WebRTC connection becomes unstable, FastFileLink will attempt to fall back to our Relayed P2P connection. During this fallback, it uses standard HTTP Range requests to try and continue the download from where it left off, saving time and bandwidth.
  • In a Browser: Due to browser security restrictions, a browser cannot access partially saved files on your disk. This means if you completely close the browser tab or shut down your computer, the download cannot be resumed from scratch. However, as long as the connection is active (even if temporarily lost), our system will try to resume.
  • Using the FastFileLink CLI: For maximum reliability, the FastFileLink CLI supports a --resume flag. This allows you to continue a transfer at any time, even if the program was completely closed.
  • During Server Uploads: We also support resuming uploads for our Server Upload Mode. This is ideal for extremely large files (hundreds of GBs or even TBs) where P2P is impractical (requiring both users to be online for a very long time). You can upload a file in parts, even across several days, and it's fully compatible with End-to-End Encryption (E2EE). Our CLI even supports a --pause command to interrupt the upload at a specific percentage.

Q5. How does FastFileLink handle privacy and file security?

We prioritize your privacy and the security of your files:

  • During Direct P2P or Relayed P2P transfers: The connection established for transferring data is encrypted by default (using WebRTC's built-in DTLS). For maximum security, you can optionally enable End-to-End Encryption (E2EE). This adds a second layer of encryption, ensuring that even if the transfer falls back to our Relayed P2P server, the data is unreadable to us (making us a "Zero-Knowledge" server). As mentioned, our relay servers do not store your files or log transfer contents. The link generated for sharing is also protected by a random code, making it difficult for attackers to guess or use brute-force methods to access your download link. (See Q6 for more details on E2EE).

  • When using Server Upload Mode: If you choose to upload your file to the FastFileLink server, you can optionally enable End-to-End Encryption (E2EE). This ensures your privacy, making our server a Zero-Knowledge Server—we cannot see the contents of your file, guaranteeing your privacy. The connection itself is also encrypted. Files are stored only for the temporary retention period you select and are protected by our storage protocols before being periodically removed.

  • Application Security: The FastFileLink application itself is designed to be safe. We guarantee it contains no malware or malicious code.

    • Certified Applications: Our Windows application is certified and available through the Microsoft Store. Files downloaded from the MS Store are signed directly by Microsoft, indicating they have passed their security review. Our macOS version is also signed by Apple.
    • Transparency: The source code for our FastFileLink CLI is fully open-source. Anyone can audit the code to verify its security implementation and confirm there are no backdoors.

Q6. What is End-to-End Encryption (E2EE) and "Zero-Knowledge" in FastFileLink?

End-to-End Encryption (E2EE) is a security method that encrypts data on the sender's device and only decrypts it on the recipient's device. No one in between, including the service provider, can read the data.

Why is this important? FastFileLink already uses DTLS (Datagram Transport Layer Security) by default to encrypt all WebRTC traffic. However, we provide an optional, additional E2EE layer that you can enable for both P2P and Server Upload modes.

When you enable E2EE: - Your file is encrypted on your device before any data is sent. - This provides multiple layers of protection. Even if the underlying DTLS encryption were somehow compromised, your data would still be secure. - This ensures that even if your connection falls back to our Relayed P2P server, or if you use the Server Upload Mode, the data passing through our servers is encrypted, and we cannot see its contents.

This makes FastFileLink a Zero-Knowledge Server. We only manage the connection but have zero knowledge of the content you are transferring.

The only trade-off: Standard FastFileLink links can be downloaded using any HTTP tool (like curl or wget). However, when E2EE is enabled, these tools will only download the encrypted file (ciphertext). To successfully download and decrypt the file, the recipient must use a supported browser or the FastFileLink CLI: https://github.com/nuwainfo/ffl.

Q7. What is FastFileLink's core technology, and why isn't it a web-based tool?

Many P2P file-sharing tools (like ToffeeShare, Snapdrop, or Send Anywhere) operate primarily within a web browser. FastFileLink is a native application, a design based on our core technical principles:

FastFileLink's principle is to turn your own machine into a secure, temporary file server.

Here's how it works: 1. Local-as-Server: When you share a file, your computer opens a random port to serve that file. 2. Tunneling for NAT Traversal: To ensure anyone on the internet can connect to you (bypassing most NATs and firewalls), we use secure tunneling technology. This can be handled by our dedicated tunnel server, or you can opt to use an external tunnel service (like Cloudflare Tunnel) to expose your connection. 3. Automatic HTTPS: This tunneled connection is automatically secured with HTTPS, encrypting data in transit. 4. WebRTC P2P Transfer: FastFileLink then uses WebRTC for the direct P2P data transfer, but with a key difference: your computer also acts as its own WebRTC Signal Server. This means no central server is needed to manage the connection handshake, maximizing privacy.

Why this is better than a Web App: - Stability with Massive Files: Browsers have memory and processing limitations. Trying to share a very large file (e.g., 100GB+) or a folder with thousands of files via a web app can easily crash the browser tab or make it unresponsive. A native application like FastFileLink can handle these large-scale transfers much more efficiently and reliably. - Stronger Security & Privacy: By acting as a local server and managing its own signaling, FastFileLink removes the reliance on third-party signaling servers, giving you full control over the connection. - Guaranteed Connectivity: Our tunneling technology provides a more robust method for NAT traversal than standard WebRTC (which can fail in some restrictive networks), ensuring a higher connection success rate.