ffl
Install

Transfer for humans and agents.

Turn a file, folder, or stream into a link. A person opens it in a browser. An agent fetches it and keeps working. The bytes go from your machine to theirs, not through a cloud bucket.

curl -fsSL https://fastfilelink.com/install.sh | bash

Film: how one ffl link reaches a person and an agent

Most file handoffs take a detour through somebody's cloud.

40 seconds, no sound

Read the film as text
  1. The detour Most file handoffs take a detour through somebody's cloud.
  2. One command ffl turns your folder into a link. The files stay on your machine.
  3. To a person A person opens the link in a browser. Nothing to install.
  4. To an agent An agent fetches the same link and carries on with its job.
  5. Your route Direct when possible, relay when needed. With --e2ee, the relay only carries ciphertext.
  6. Delivered Checksum verified on arrival. One link, any next step.

One command. Any kind of recipient.

A photo album, a build artifact, a model checkpoint. The sender runs the same command; what changes is who picks it up.

You run
ffl ./photos --e2ee
They open
https://<your-share-link>
Good to know
No recipient account or app. Keep the sender running until the download finishes.

A folder that keeps delivering

With --watch, every new child folder is published once it stops changing. The receiver runs --follow on one collection link and picks up each batch as it lands.

New folders only. Append-only delivery, not a mirror or two-way sync.

Read the watch and follow guide
# sender
ffl ./outbox --watch --e2ee
# receiver
ffl download <COLLECTION_URL> --follow \
  --output ./incoming --resume

Your bytes take the shortest route you allow.

Cloud storage shouldn't be a prerequisite for handing over a file. ffl connects sender and receiver directly, and you choose how it reaches the network.

ffl clients connect over native TCP/QUIC; browsers use WebRTC. Public signaling and tunnel services help the two sides find each other, and an HTTPS relay carries the transfer when a direct connection fails.

Add --e2ee to encrypt file contents on both the direct and relay paths. Connection metadata stays visible.

ffl ./artifacts --e2ee
On your LAN HTTPS relay TCP/QUIC or WebRTC Your machine Their machine

Make sure it reaches the right hands.

A link is easy to forward. When that matters, ask the recipient to prove who they are before the download starts.

Pickup code

The recipient enters a 6-digit code before downloading. ffl generates one if you don't set it.

ffl contract.pdf --recipient-auth pickup

Public key

Only the holder of the matching private key can open the download. Create keys with ffl keygen.

ffl report.zip --recipient-auth pubkey --recipient-public-key clientA.fflpub

Checksum on arrival

Every download is verified on the receiving side, in the browser or the CLI, so a corrupted file never passes silently.

Receipts

Get an email when the download finishes, or ask the receiver to confirm. Requires an eligible account.

ffl build.zip --receipt --receipt-confirm

Your agents make things. Give them a way to deliver.

Move a local model, a dataset, or a generated report between machines without a cloud bucket or a shared filesystem. Your orchestrator passes the link; ffl carries the bytes.

# worker A: share and write the link
ffl ./artifacts --e2ee \
  --json handoff.json --hook events.jsonl &

# orchestrator: pass the link on
LINK=$(jq -r .link handoff.json)

# worker B: fetch, then keep going
ffl download "$LINK" --resume
  • From scripts and CI

    Share files or stdin. Read the link from --json, follow progress with --hook, close after one download with --max-downloads 1, stream to another program with --stdout.

    Automation tips
  • As a tool for your agent

    Connect the companion ffl-mcp server to any MCP host. Agents can share outputs and download inputs, then hand the same link to a person.

    Set up ffl-mcp
  • Inside your own app

    Structured events and host-provided file sources let you build transfers into your product. Your app owns the interface; ffl handles delivery.

    Embedded mode guide

Install on the sender. The recipient just opens the link.

curl -fsSL https://fastfilelink.com/install.sh | bash

Native builds for Linux x86_64 and macOS (Intel and Apple Silicon). On Linux ARM64, use the portable build.

Then share something ffl ./photos
All builds, checksums, and signatures

Before you send

Is there a file-size limit or a cloud quota?

Direct sharing has no cloud-storage quota and needs no account. The real limits are your network, your disk, and how long the sender stays online. Relay providers may set their own limits. Optional server upload has separate account and plan limits.

Does the sender need to stay online?

Yes, for direct and relayed sharing. Keep ffl running and the files in place until the receiver finishes. If both sides can't be online together, --upload stores the file on a server for a while; that needs an account and the Upload addon.

Is every transfer end-to-end encrypted?

No, it's opt-in. Add --e2ee to encrypt file contents on direct and relay paths, then receive with ffl or its browser page. Metadata stays visible, and E2EE alone doesn't stop an active man-in-the-middle; use pickup codes or public keys to verify the recipient.

Is ffl an agent framework or a sync drive?

Neither. ffl is the transfer layer. Your agent host or orchestrator decides what to send, passes the link, and manages processes. --watch publishes new child folders once they settle; it doesn't mirror edits or deletions.