Open jvehent opened 6 years ago
We're working on a version 2 of send which will support larger file sizes; up to 4 gb. You can follow our progress on the "vnext" branch.
However, for files bigger than 4gb, I think it is perfectly reasonable to switch to another mode where the sending page tells the user to keep it open, and the receiving page connects peer to peer to download the item. We'll discuss it in our next meeting.
Actually when p2p sending you do not impose any limit. AFAIK the chunks can be always be send in WebRTC, so the only limit is time/upload/download speed here, that's a thing the user may be made aware of; of course.
I've been able to push & retrieve an 8G file on a local instance of send (I'm a bit low on disk so can't test much larger) but curious is there's still a plan to allow peer-to-peer connections to facilitate larger transfers.
As a user, I'm still struggling to share very large files with others. Send currently has a 1gb upload limit, which is too small for some legitimate use cases, like sharing a collection of RAW photos from a trip. No good alternative exists on the Internet today, and my attempts at coding this myself have somehow failed again.
@warner's magic wormhole offers a very elegant solution to this problem, but the tool is terminal-based and not suitable to the general population. A web version was discussed a long time ago, but never came to fruition. I think Send could be that web version.
User Story User A wants to send a very large file (50GB) to user B. A uploads the file to send.firefox.com and get a warning: the file is too large to be uploaded, but can be transferred to B directly. A URL is provided, and a message informs A to keep the tab open until B is done transferring.
A sends the URL to B who opens it up in a browser. The Send server then establishes a channel between A and B, uploads the file from A and transfers the chunks directly to B. Nothing is stored or cached on the server side. Encryption principles that normally apply to files uploaded to Send remain in effect and only encrypted chunks are transferred, then decrypted by B.
I think this feature would solve a real problem Internet users encounter regularly. As someone who supports photographers who have to deal with huge files on a daily basis, I can attest to the need for a service that makes transferring these large archives much more easily.