List of P2P file sharing tools

list_of_p2p_file_sharing.md

Browser Based

1. Web Wormhole https://webwormhole.io/ https://github.com/saljam/webwormhole
2. Localsend https://web.localsend.org/
3. FilePizza https://file.pizza/
4. ShareDrop sharedrop.io https://github.com/szimek/sharedrop (SOLD, not recommended, use one of the forks)
   1. A clone SnapDrop snapdrop.net https://github.com/RobinLinus/snapdrop (SOLD, not recommended, use one of the forks)
      1. A fork PairDrop https://pairdrop.net/ https://github.com/schlagmichdoch/pairdrop
5. ToffeeShare https://toffeeshare.com/
6. Instant.io https://instant.io/
7. FileTC https://file.tc/
8. Send Anywhere https://send-anywhere.com/
9. Just Beaam it https://www.justbeamit.com/
10. Peermesh https://perguth.de/peermesh https://github.com/perguth/peermesh
11. drop.lol https://drop.lol/ https://github.com/mat-sz/filedrop
12. rDrop https://rdrop.link/
13. AirDelivery https://airdelivery.site/
14. Blaze https://blaze.vercel.app/ https://github.com/blenderskool/blaze
15. SendFiles https://sendfiles.dev/ https://github.com/jchorl/sendfiles
16. Katana https://sekky61.github.io/Katana/ https://github.com/Sekky61/Katana
17. FileLove https://file.love/ https://github.com/midzer/filelove
18. Filegogo https://send.22333.fun/ https://github.com/a-wing/filegogo
19. Peertransfer https://github.com/perguth/peertransfer https://perguth.de/peertransfer/
20. Yt2fb.in https://yt2fb.in/file-transfer/
21. P2P File Transfer https://chidokun.github.io/p2p-file-transfer/ https://github.com/chidokun/p2p-file-transfer
22. P2P File Transfer https://webbrowsertools.com/p2p-file-transfer/ https://github.com/leocompson/p2p-file-transfer
23. NeighborHoodShare https://neighbor-share.vercel.app/ https://github.com/dikshantrajput/neighborHoodShare
24. Vegh https://vegh.netlify.app/ https://github.com/veghfile
25. P2P File Sharing https://taonexus.com/p2pfilesharing/

TODO

• Test which of these tools can send very large (10GB+) files without freezing/crashing the browser.

CLI

1. croc https://github.com/schollz/croc
2. p2pcopy https://github.com/psantosl/p2pcopy
3. pcp https://github.com/dennis-tra/pcp
4. wormhole-william https://github.com/psanford/wormhole-william
5. Wush https://github.com/coder/wush
6. sendme https://www.iroh.computer/sendme https://github.com/n0-computer/sendme
7. B·o·B https://bob.osau.re/ https://github.com/dinosaure/bob

(Updated the list based on comments. Only keeping p2p tools)

Is there any one of these services that could possibly accept a drag'n'drop of a complete folder and share the entire content (with folders/files inside) without messing up everything?
All of the ones I've tested only accept one or some files individualy, or if multiple in a folder and subfolders like File.pizza, the structure is mess as it download files individually...

Thank you!

@ekinoxben checkout www.shipfilez.app

mokshith-moksh
It can accept a folder, cool, but it download files individualy and don't keep the folder structure... If it could at least zip the folder to prevent that...

@ekinoxben checkout www.shipfilez.app

Using OPFS probably means that a copy of all file data is stored in the browser storage. If the file is large, the user may not have enough storage space for an extra copy. Therefore, it would be preferable if the data could be directly streamed to the final destination, without storing it in OPFS first.

OPFS is for the receiver not the sender. There's no "extra copy."

Using OPFS probably means that a copy of all file data is stored in the browser storage. If the file is large, the user may not have enough storage space for an extra copy. Therefore, it would be preferable if the data could be directly streamed to the final destination, without storing it in OPFS first.

OPFS is for the receiver not the sender. There's no "extra copy."

To actually use the file, the receiving user has to save it to the regular filesystem, not OPFS. If the tool that they are using to transfer the file uses OPFS, then at this point there are two copies of the file: one in OPFS, and one in the regular filesystem where the user has saved it. If the file is large and the receiving user has little storage space, they may be able to afford the space for one copy but not for two.

Using OPFS probably means that a copy of all file data is stored in the browser storage. If the file is large, the user may not have enough storage space for an extra copy. Therefore, it would be preferable if the data could be directly streamed to the final destination, without storing it in OPFS first.

OPFS is for the receiver not the sender. There's no "extra copy."

To actually use the file, the receiving user has to save it to the regular filesystem, not OPFS. If the tool that they are using to transfer the file uses OPFS, then at this point there are two copies of the file: one in OPFS, and one in the regular filesystem where the user has saved it. If the file is large and the receiving user has little storage space, they may be able to afford the space for one copy but not for two.

ohh that's what you meant. in that case, you'd probably just want showsaveFilePicker API and that's not ideal for UX. If you have multiple files, you need multiple prompts. Probably fine if you're sending large files since most people send a few at a time anyways.
The real problem there is Firefox cause their showSaveFilePicker implementation just falls back to memory.

showSaveFilePicker isn't supported in Firefox and Safari. A better option is to stream a file using a service worker.

showSaveFilePicker isn't supported in Firefox and Safari. A better option is to stream a file using a service worker.

actually a pretty good idea. StreamSaver.js?

unfortunately, still some issues remain in UX like in-app progress bars and multiple save prompts if there is more than one file.

Progress bars should be possible to implement with either solution. After all, the implementation does know how much data it processed, and even if this processing happens in a service worker, the progress can be communicated back to the page. Multiple save prompts unfortunately cannot be avoided without an API like showDirectoryPicker (or generating a ZIP archive or similar, but then the user will need extra space to extract it).

Do any of these that are web support sharing just text?

Progress bars should be possible to implement with either solution. After all, the implementation does know how much data it processed, and even if this processing happens in a service worker, the progress can be communicated back to the page. Multiple save prompts unfortunately cannot be avoided without an API like showDirectoryPicker (or generating a ZIP archive or similar, but then the user will need extra space to extract it).

Agreed on the progress bars. Honestly, I might consider implementing this. Thanks for the idea :) There's a mess of async chains with cancelling transfers in the UX with this but it's probably doable.

The save prompts though which you pointed out very aptly, are a mess unless you use showDirectoryPicker which is also only supported on Chrome and Edge I think. You could zip but yes that'd be right back to square one with space efficiency.

Do any of these that are web support sharing just text?

p2party.com and dropsilk.xyz both support texts