[HN Gopher] Peer-to-peer file transfers in the browser
___________________________________________________________________
Peer-to-peer file transfers in the browser
Author : keepamovin
Score : 566 points
Date : 2025-03-12 12:08 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| janandonly wrote:
| I love this WebRTC based attempt to send files browser to
| browser.
|
| Too bad I've not yet seen it working without hiccups.
|
| I'm currently testing keet, which is in beta but promising as
| well. https://keet.io/
| keepamovin wrote:
| Thank you for the information.
| corysama wrote:
| Keet is based on https://holepunch.to/ which I came here to say
| "Why don't I ever hear about this around here?"
|
| Holepunch is about open source tech for P2P apps without
| servers.
| calebh wrote:
| I've also never been able to get these P2P web file transfer
| tools (FilePizza, ShareDrop) to work without issues. Transfers
| inevitably fail partway through, especially for large files.
| This seems to happen even in ideal network conditions such as
| over a LAN.
| modeless wrote:
| I wish there was a way to do local peer discovery with WebRTC.
| Right now both endpoints need an active Internet connection and a
| shared identifier (in this case a special URL) in order to find
| each other. Can't do offline local sharing.
| pzo wrote:
| Sharing identifier maybe we could do with qrcode, chirp audio
| protocol, nfc tap. Ios has peerconnectivity that works really
| as p2p network but sadly no web api and doesn't work android
| (not sure someone reverse engineered protocol)
| lxgr wrote:
| Somebody indeed has, but since it uses a custom low-level
| 802.11 variant, I don't think it's feasible on (at least non-
| rooted) Android devices: https://github.com/seemoo-
| lab/opendrop
| sbt567 wrote:
| https://github.com/n0-computer/sendme
| arilotter wrote:
| iroh's stuff is great but their local peer discovery can't
| work in a browser, since it uses an mdns-like protocol to do
| it
| Sean-Der wrote:
| You can! https://github.com/pion/offline-browser-communication
|
| It uses mDNS for discovery. You can only do one browser though.
|
| I don't see a path forward on browser/browser that is obvious.
| It would make it so easy to fingerprint if you could set your
| mDNS hostname in JS
| modeless wrote:
| If one end of the connection is a native app like this you
| have plenty of other options. Browser to browser is the use
| case I'm talking about.
|
| It could be done with a browser-owned dialog to select peers
| instead of exposing all local peers to the web by default.
| Similar to the web MIDI API or others that expose local
| devices only with explicit user permission for the specific
| device.
| lxgr wrote:
| A QR code should work if at least one of the browsers has
| camera access, I suppose?
| k__ wrote:
| Couldn't you use sound/bluetooth/qrcodes/etc. to do signalling?
|
| I once did it by copying messages from textarea's back and
| forth.
| ivanjermakov wrote:
| I solved this issue by implementing a webtorrent tracker[1]
| client. Signalling server is still needed, but with this
| approach any webtorrent tracker can act as one.
|
| [1]: https://github.com/webtorrent/bittorrent-tracker
| mary-ext wrote:
| rather worried that it's going to go the same fate as ShareDrop
| (https://github.com/ShareDropio/sharedrop) and Snapdrop
| (https://github.com/SnapDrop/snapdrop) where they recently got
| taken over by LimeWire the crypto/AI company.
| chad1n wrote:
| I wonder how much LimeWire pays to buy all of these foss
| projects, must be a decent amount if everyone is selling his
| solution
| grimgrin wrote:
| limewire aint touchin soulseek
|
| and it has people building alt.clients
| https://nicotine-plus.org
| https://github.com/slskd/slskd
|
| (though these are not webapps, which was your main shtick i'm
| sure)
| Etheryte wrote:
| Wouldn't be surprised if the prices are fairly low actually,
| I would wager most of these projects make no income.
| mainframed wrote:
| Yup. I recommended snapdrop to everyone in my family and
| friends for local data sharing without a cable.
|
| When I discovered that it now uploads stuff to Limewire I was
| so annoyed that I had to admit I suggested a harmful tool for
| sharing private data. So much, that I will never recommend a
| similar website. Either I'll host it my self or suggest an
| installed tool through F-droid, if it exists.
|
| I mean, it is entirely my fault. I knew the security risk, but
| set it aside, because I didn't think some known guy developing
| an open source tool would in his name try to grab your data.
| IncreasePosts wrote:
| Wow, as someone who worked at the original limewire back until
| we got sued out of existence, this makes me sad to hear some
| scammers bought the IP and resuscitated the corpse of the
| company.
| Rygian wrote:
| There is also Magic Wormhole [1] which is not in-browser.
|
| [1] https://github.com/magic-wormhole/magic-wormhole
| mhitza wrote:
| And https://github.com/psanford/wormhole-william which is a Go
| reimplementation of the client. I only want to point this out
| specifically because an apt-install of magic-wormhole on Ubuntu
| 24.04 actually results in a program that does not work (the
| beauty of python dependencies at play?)
| artursapek wrote:
| It's really amazing to me how successful Python has been
| given its dependency management and package installation
| tooling
| Timber-6539 wrote:
| Pretty sure the snap version of wormhole works. I use it from
| time to time as well as the go binary.
| 0xdeadbeefbabe wrote:
| If someone has ported the server I'll run my own instead of
| taking the bandwidth.
| nuptials wrote:
| There is: https://wormhole.app/ for the browser if one needs
| it.
| sevg wrote:
| Other readers, please do note that (the unfortunately named)
| wormhole.app is unrelated to the frequently recommended,
| heavily peer-reviewed and much longer-standing magic-
| wormhole.
| Imustaskforhelp wrote:
| exactly!
|
| Was just looking for such comment because I knew about
| wormhole.app is not on top of wormhole protocol itself.
|
| Thanks for your comment , may it help other people.
| nuptials wrote:
| Didn't knew that. Thanks a lot!
| Retr0id wrote:
| Not to be confused with https://webwormhole.io/, which is
| open-source
| amelius wrote:
| It's so strange that this should have been a solved problem
| decades ago, but somehow a robust and secure non-commercial
| solution never gets off the ground.
|
| Speaking of which, how is the IPFS project doing these days?
| piyuv wrote:
| It was solved a decade ago, BitTorrent protocol
| brulard wrote:
| BitTorrent started in 2001, so more than 2 decades.
| pzmarzly wrote:
| Arguably, only in BitTorrent V2, which released in 2017,
| wasn't supported by major clients until 2020, and is still
| not widely adopted.
| piyuv wrote:
| The same reason universal healthcare and free education is
| not widely adopted in the US. BitTorrent is quite "widely
| adopted" in other parts of the world.
| pessimizer wrote:
| > Bittorrent V2
| SirMaster wrote:
| I think people mean something seamless like AirDrop is on
| Apple devides, but some public standard that gets implemented
| on all platforms like iOS, Android, Windows, macOS and Linux,
| so all these platforms can just easily send files to each
| other simply and securely over WiFi.
| piyuv wrote:
| There's no incentive for big players to play nicely with
| other platforms so they just won't. Hardware standards like
| Qi2 are different since it affects costs directly. Software
| is usually built for lock-in since quite some time.
|
| "Buy your mom an iPhone" and how Apple buried beeper mini
| into nonexistence was a nice example.
| pjc50 wrote:
| "Securely" is doing a lot of work here; you need some out
| of band mechanism to transfer the link in the first place,
| to determine who you're getting the file from, and then you
| might as well use that to transfer the file instead. Also
| people want to be able to do it asynchronously, so they use
| things like WeTransfer.
|
| During the brief period that open Airdrop / bluetooth file
| transfer was a thing, there was a short fad of spamming
| porn to nearby people on public transport. So that was the
| end of that.
| JadeNB wrote:
| > During the brief period that open Airdrop / bluetooth
| file transfer was a thing, there was a short fad of
| spamming porn to nearby people on public transport. So
| that was the end of that.
|
| My recollection is that the end of that was Apple's worry
| about the protests in China, not any concern about spam
| on public transit. (The first Google hit:
| https://restofworld.org/2022/apple-airdrop-china-memes/.)
| SirMaster wrote:
| Seems like such a simple fix though... Blur the shared
| photos unless you tap preview. Or unless it's coming from
| someone you have in your contacts. Or just not have it
| show the preview at all and obviously you would decline
| files from someone you aren't expecting to receive files
| from.
|
| Or the simple fix of just not having this P2P transfer
| option always enabled. It should be off until you toggle
| it on because you and someone you are with want to
| transfer a file.
| K7PJP wrote:
| I believe that's what Apple did for AirDrop, "Everyone
| for 10 Minutes" is available in AirDrop settings. You can
| also use NFC (Near-field communication) to initiate a
| transfer with a non-Contact, while optionally
| establishing a Contact relationship. If only this were
| also available on Android.
|
| I think it'd be great if Apple supported this, even if it
| meant an Apple AirDrop app for Android. Especially if it
| meant an Apple AirDrop app for Android.
| slt2021 wrote:
| I had a lot of fun airdropping rickroll videos to nearby
| phones while waiting for rides in disneyland
| jjk7 wrote:
| The DHT exists, all you need is an infohash and you get
| grab the metadata from peers/uploader.
|
| libtorrent supports something called 'SSL' torrents that
| require both peers to be signed by the same root.
|
| All the pieces are there to build on top of.
| JadeNB wrote:
| > I think people mean something seamless like AirDrop is on
| Apple devides
|
| Ha! I do wonder if I'm the only person who has errors where
| sometimes an AirDrop attempted transmission, from two
| devices sitting right next to each other, just hangs
| indefinitely, even if a transmission between the same two
| devices a minute ago succeeds. Like all Apple solutions
| that Just Work, it's great when it Just Works, but, when it
| doesn't, great effort seems to have been taken to make sure
| that there's no way to find out why not.
| culi wrote:
| AirDrop was a huge asset to protestors in Taiwan. It was
| heavily used for mass demonstrations. Something that works
| cross-platform could be really great for political
| movements
| Aachen wrote:
| Torrents can be seamless. I take it you haven't used a
| download manager that would just grab any file, treating
| torrents just like any other download, as seamless as HTTP
| downloads are?
|
| It doesn't have to be a dedicated system where you manage
| how long you seed, port forward, and other technical
| requirements: torrents already work well when you just seed
| _while_ downloading because the server can never get
| overloaded, pretty much no matter how viral something goes.
| So long as it keeps serving the tiny torrent file, a few
| blocks on occasion, and the few packets needed to set up a
| NAT punch between people (STUN /TURN server? I always
| forget what's what), people can get the file from each
| other and you don't have huge bandwidth costs or have the
| site go down once the included bandwidth is exhausted.
| There's a reason Facebook and Twitter use(d?) this for
| distributing server updates1, and I don't think someone
| remotes onto every server to visit the pirate bay, which
| torrent technology has sadly become synonymous to and
| people don't realise it is a transfer protocol just like
| FTP, HTTP, and other TPs that I'm forgetting
|
| > some public standard that gets implemented on all
| platforms
|
| What this is based on doesn't matter. It can be http, it
| can also be torrents. It's not very useful if you're
| sending files from and to one person almost every time
| (perhaps at the end of a holiday with friends, more than
| one person would want everyone's photos, but still), I'm
| just objecting to torrents being misunderstood as the only
| thing most people used it for: downloading copyrighted
| material in dedicated (and often unwieldy) software :)
|
| 1 https://torrentfreak.com/facebook-uses-bittorrent-and-
| they-l... Article also mentions that a university cut 20 of
| the 22 update-distributing servers, I didn't know of that
| example
| lxgr wrote:
| Very different use case. It seems both too heavy weight and
| not capable enough for e.g. sharing a screenshot or PDF from
| an Android phone to a Linux laptop without Internet
| connectivity.
| megadata wrote:
| Yeah, your can do your dishes with the fire hose too.
| supertrope wrote:
| People drive one ton pickup trucks to commute to their desk
| job. Or to get two bags of groceries.
| culi wrote:
| This is true but this sucks.
|
| Modern American SUVs are an abomination too. The American
| auto industry started pushing them because they're
| legally classified as "light trucks" which lets them take
| advantage of certain safety and environmental standard
| loopholes
| pessimizer wrote:
| Yes, but it's no harder to get your groceries with an SUV
| than with a compact car. The firehose metaphor doesn't
| make sense; you're not going to accidentally wash all of
| the data off of the recipient's computer if you're not
| especially skilled in handling bittorrent.
|
| The problem with bittorrent is ports, just like ipfs. I
| have to tell somebody to open a port to the outside who
| may never use bittorrent again.
|
| Opening ports can be obnoxiously hard for someone who
| doesn't know anything, even if it sometimes just means
| finding the UPnP checkbox; 90% of the time it involves
| trying to figure out how to access the UI for their
| router, and after that trying to figure out what their
| password could possibly be or how to reset it.
|
| Now, they've got a port sitting open for a piece of
| software they might never use again, and that's not
| something I want to be responsible for.
|
| People who often share files should be setting up
| standing private networks. Group chats/texts can last for
| years, they should be packaged with an entire range of
| services that the members can easily provide for
| themselves (like file sharing and voice/video messaging.)
| So many companies make their money from centralizing and
| siloing this.
| mystified5016 wrote:
| Yes, and they kill more people on average by doing it.
| hot_gril wrote:
| This isn't always encrypted, right?
| sidewndr46 wrote:
| Peer to peer sharing doesn't really have much opportunity for
| commercialization. The closest thing I can think of is
| bluetooth file sharing, which can still be a painful experience
| in some circumstances
| megadata wrote:
| Not only sharing, bluetooth in general can be a painful
| experience in some circumstances.
| supertrope wrote:
| Yes businesses tend to only work on interoperability when the
| interoperable product is just a complement to their main
| revenue generator. Like how Netflix releases clients for many
| platforms. No one is going to be motivated to make a (1) free
| (2) easy to use (3) cross platform file sharing solution.
| It'll also draw the ire of the copyright cartel. File locker
| websites have been harassed and "legitimate" cloud storage
| services are forced to police their user's files.
| Yizahi wrote:
| XKCD from a decade ago, and we still can't figure it out ;(
|
| https://xkcd.com/949/
|
| Recently I had to send file from Whatsapp to Telegram, because
| apparently it is forbidden to download file from the Whatsapp
| and it's a "feature". Facepalm....
|
| PS: afaik IPFS doesn't guarantee file storage, a separate paid
| middleman is required for that.
| j_maffe wrote:
| IPFS allows you to store your file and share the content ID
| to someone else so that they can get it through P2P
| j_maffe wrote:
| IPFS is in this weird state where it's getting barely enough
| updates and enough usage to not be considered vaporware.
| makeworld wrote:
| It is partially being succeeded by Iroh.
|
| https://www.iroh.computer/
| IsTom wrote:
| I think it's because of all the NAT, which makes any attempt
| cumbersome for a lot of people.
| pmarreck wrote:
| If only IPv6 had taken off...
| hot_gril wrote:
| If only they just made a new IPv4 with a longer address
| field, instead of something way more complicated that also
| changes pre-existing addresses.
| enriquto wrote:
| kids these days...
|
| in my time, we used to know each other's IP addresses and just
| used netcat
| InsideOutSanta wrote:
| In my time, we used to bring floppies to the schoolyard and
| just swap them.
| JadeNB wrote:
| > In my time, we used to bring floppies to the schoolyard and
| just swap them.
|
| Sneakernet!
| Dylan16807 wrote:
| If that counts then you can use a flash drive and the problem
| is solved.
| deskr wrote:
| We swapped cassettes and then copied them in hillbilly double
| cassette deck.
| mrbluecoat wrote:
| Making sure to cover the write-protect holes on the top
| with Scotch tape, of course.
| doodlebugging wrote:
| In my time we just wrote very small on scraps of paper or
| tore pictures from magazines. We folded them tight into a
| compact rectangle, then we folded that rectangle across a
| rubber band between our thumb and index finger and with the
| other hand we stretched that rubber band enough so that when
| released, it would propel the folded rectangle of paper
| across the intervening distance rapidly enough that the
| adversarial player in the room could not detect the source or
| recipient of the rectangle without querying the entire
| congregation.
|
| This method eliminated potentially adversarial middlemen in
| transit who might, if you chose to pass it through multiple
| players (servers if you will) - read it in transit though the
| message was not intended for them, and then use the contents
| against you later.
|
| It had the disadvantage that one needed to insure that the
| sender and recipient were in sync in case the aim was off and
| the message bounced to an unintended recipient.
|
| I once had the misfortune of sending a tightly folded, secure
| message that was part of a war game being played during
| English class, and having that poorly aimed message hit the
| largest mass of muscle in the class right squarely in the ear
| because the recipient was busy gloating over the success of
| their previous move and wasn't able to secure the reply in
| transit.
|
| We all heard the light snapping sound of the rubber band
| followed by an uncharacteristically loud profanity from the
| unintended recipient, my own barely stifled gasp of horror,
| lots of giggles and laughter from the audience, and as they
| turned - the beginning of the next round of the Inquisition
| by the adversarial instructor who mistakenly thought we were
| all watching the English lesson on the board in real time
| instead of conducting paper war games in the background.
|
| Fun times.
| arthursw wrote:
| I really like PairDrop https://github.com/schlagmichdoch/PairDrop
| rpastuszak wrote:
| Heh, seeing PairDrop motivated me to make sth similar, but more
| as a toy/exercise in messing with idiosyncratic/home cooked
| software: https://sonnet.io/posts/reactive-hole/
| PhilippGille wrote:
| Thanks for sharing!
|
| Most other solutions don't allow pairing of devices _across
| networks_.
|
| TFA's "file.pizza" only allows to initiate a session on the
| device that uploads a file, which makes it tricky to share a
| file from a mobile device to a laptop (due to tricky QR code
| scanning with the laptop camera).
|
| PairDrop allows cross network pairing (mobile device can scan
| QR code from laptop screen), and file uploading from both sides
| afterwards.
| eduction wrote:
| It still needs middle out compression imo
| keepamovin wrote:
| WebRTC is compressed, unless I misunderstand your possible term
| of art "middle out"?
| onychomys wrote:
| Middle out compression is what the guys in the TV show
| Silicon Valley invent.
| keepamovin wrote:
| lol ok.
| Sargos wrote:
| Silicon Valley TV show
| mystifyingpoi wrote:
| That's the beginning of The New Internet.
| unstruktured wrote:
| "Uh...the answer's not in the box, it's in the band".
| westurner wrote:
| > _He said, uh, "The answer's not in the box, it's in the
| band."_
| ranger_danger wrote:
| Love that movie.
| porridgeraisin wrote:
| I like https://github.com/schollz/croc
| Springtime wrote:
| Opera browser used to have P2P file transfers as a short lived
| feature in ~2010, called Unite. I remember it also had
| skeuomorphic GUI of a 'fridge' where users could put post-it
| style notes that could be seen by others.
|
| One of many everything-and-the-kitchen-sink features Opera Presto
| had during its heyday. Others included a _separate_ Bittorrent
| client, desktop widgets that could be moved outside of the
| browser window, full IRC client, email client and peerless hotkey
| actions customization.
|
| By some miracle the browser still managed to be a rather lean
| binary.
| culopatin wrote:
| Can we have that do-it-all Opera back? RSS, email, torrents.
|
| Feels like we had it all internet wise in 2007-2010 and then
| decided to throw it all away.
| mrweasel wrote:
| I think Vivaldi have both RSS and email, it's sort of the
| spiritual successor to the original Opera.... I miss the old
| Opera.
| rplnt wrote:
| Vivaldi is roughly 1000 times slower. You need a pretty
| good computer to run that UI. It also lacks extremely basic
| features Opera had; like working LRU tab switching. I liked
| the idea, but it's impossible to recommend.
| AlienRobot wrote:
| Is that true? I remember having to change a setting to
| switch the behavior of tab switching because it was LRU
| by default and I prefer it in visible order.
| rplnt wrote:
| It used to work and broke maybe 2 years ago. This tells
| me that no one is actually using the browser and that no
| one is really working on it either. It receives chromium
| updates and then some money-making features here and
| there.
| dicknuckle wrote:
| have you tried Otter Browser?
| rplnt wrote:
| It's been a while, 8-10 years ago maybe? But quick look
| now tells me it's still one person effort. That's both
| awesome and unfortunate. I wish it got more traction back
| then to attract more active user/dev base.
| rplnt wrote:
| What a blast from the past. 0 comments, 0 points. Opera
| wasn't very popular in US.
| https://news.ycombinator.com/item?id=7937436
| rplnt wrote:
| We did not decide it. Google decided to kill it. In countries
| where Opera had major share Google ran aggressive and
| deceptive (something something faster) campaign with
| billboards, radio and tv ads. Chrome ads were also everywhere
| on their homepages (google.com, youtube.com). But more
| nefariously, Google kept blocking features and apps based on
| the UA agent alone. Add lots of tech demos with their custom
| extensions.
| masklinn wrote:
| They did that in pretty much every (developed) country not
| just those where opera has major share.
| rplnt wrote:
| Good point, I missed a word or two there to make it clear
| I didn't mean it was only there.
| miki123211 wrote:
| Don't forget bundling Chrome with random apps (I remember
| cCleaner), making it install silently and automatically set
| itself as default.
|
| I got caught by this as a kid a few times, I was technical
| enough to know what was going on, and reliant on a screen
| reader (which Chrome didn't support back then), so it was
| definitely a memorable annoyance for me, but I guess quite
| a few people didn't care.
| pbhjpbhj wrote:
| Do you mean Opera Unite, that had p2p file sharing and a
| 'wall' (I think it was termed the fridge door, all your
| verified users could leave you notes/images on it IIRC).
|
| I blogged about it back in the day (15 years ago),
| https://alicious.com/opera-about-to-change-the-world/.
| 0x0f_4 wrote:
| > One of many everything-and-the-kitchen-sink features Opera
| Presto had during its heyday.
|
| oh the Presto engine.. shame its not the same opera we used
| anymore. still has the best ux on phone, unfortunately no other
| browser come close.
| freehorse wrote:
| I remember this fondly. How much more beautiful the web could
| have been if google had not killed everything else.
| kristopolous wrote:
| Opera has an operator mode now btw. I think it slipped through
| the hn radar. Maybe 2 weeks ago was the announcement? Hit
| producthunt's main page
| nashashmi wrote:
| I really wished opera had a greater market share than it did.
| It did relatively well for a few years with share between 1-4%.
| But was lagging behind defunct browsers like IE6. And back then
| the browser space was only chrome, Firefox, and IE. Notable
| mention to safari and KDE fwiw.
|
| The everything browser made it a difficult experience to
| understand. Kind of a feature overload in the face of
| minimalism being practiced by chrome and ie7.
| theendisney wrote:
| Someone made a torrent website software for it which spawned
| something like 50 good torrent websites. Combined with the
| build in torrent client and irc client it made a wonderfull
| experience.
| Lanolderen wrote:
| I still need mouse gestures in all browsers and extensions are
| still in comparison hot garbage at it.
| apitman wrote:
| Ah yes, back when browsers were actually user agents.
| martylamb wrote:
| Very nice. It reminds me of a similar all-in-browser file
| transfer tool I built ages ago called nearshare. This was WAY
| before webrtc was a thing so my approach was to actually run a
| web server in the browser via a java applet. :)
|
| https://martiansoftware.com/nearshare/
| catlikesshrimp wrote:
| >>The approach was simple, but relied on technologies that are
| now obsolete.
|
| Does obsolete mean deprecated or removed?
| martylamb wrote:
| First the one, then the other. :)
|
| It used LiveConnect[0] to talk to the UI-less java applet[1]
| hosting the web server. It was a weird (and therefore kind of
| fun!) combination.
|
| 0: https://en.wikipedia.org/wiki/NPAPI#LiveConnect
|
| 1: https://en.wikipedia.org/wiki/Java_applet
| smusamashah wrote:
| I keep a long list of browser based and CLI p2p file transfer
| tools[1].
|
| LimeWire (which now has its crypto currency probably) has been on
| a rampage recently aquiring some of really good tools including
| ShareDrop and SnapDrop. https://pairdrop.net/ is the last one
| standing so far.
|
| [1]:
| https://gist.github.com/SMUsamaShah/fd6e275e44009b72f64d0570...
| asynchronousx wrote:
| Was very annoyed when they acquired ShareDrop.
| BiteCode_dev wrote:
| https://wormhole.app/ has been spared and is pretty good.
| Encrypted, dl can start before up is finished, decent size
| limit.
|
| Unrelated to the wormhole python cli tool and associated file
| sharing protocol.
| smusamashah wrote:
| It's not a p2p tool btw.
| smallerize wrote:
| It can be, if you send files larger than 5GB.
| https://wormhole.app/faq
| toomim wrote:
| Yeah, it uses webtorrent behind the scenes:
| https://webtorrent.io
|
| ...which is freaking awesome torrent software, by the
| way.
| jeffhuys wrote:
| It's okay - 99% of the video files I download have to be
| opened in VLC, though :/
|
| But still, being able to almost immediately stream, even
| if through VLC, is pretty nice.
| lxgr wrote:
| Both not to be confused with Web Wormhole, which is also
| pretty good: https://webwormhole.io/
|
| Slightly different approach - "P2P first", i.e. both sender
| and receiver need to be online simultaneously throughout the
| transfer, but there's a TURN relay, so it should work in
| almost all network constellations.
| macielfclaudio wrote:
| I use https://onionshare.org/. It's not p2p afaik, but dang!
| that one is easy to work with.
| makeworld wrote:
| You should add sendme, it's one of the best I've tried for the
| CLI. https://www.iroh.computer/sendme
| westurner wrote:
| /? inurl:awesome p2p site:github.com:
| https://google.com/search?q=inurl:awesome+p2p+site:github.co...
|
| Peer-to-peer: https://en.wikipedia.org/wiki/Peer-to-peer
| kenrick95 wrote:
| Not sure if it's p2p, but I also find that this exist:
| http://xkcd949.com
| cship2 wrote:
| Over http?
| sir_eliah wrote:
| Probably you can also add Dragit[1], which is a desktop p2p
| file sharing tool for local network with automatic host
| discovery. Currently supporting Linux and Windows. (author &
| maintainer here) I'm not sure if I should keep on working on
| the tool, considering the length of the list so far. :D
|
| [1]: https://github.com/sireliah/dragit
| d3rockk wrote:
| Bless you.
| telesilla wrote:
| I use https://justbeamit.com
| jech wrote:
| The Galene videoconferencing system <https://galene.org>
| includes peer-to-peer file transfer. The web client is built
| in, but there's also a command-line client at
| <https://github.com/jech/galene-file-transfer>.
| ajb wrote:
| My previous company used WeTransfer a lot, because we needed to
| send large filesystem images and Android releases to and from
| China, and the great firewall hobbles obvious things like using
| gdrive.
| madacol wrote:
| In the CLI section, magic-wormhole is missing, instead you have
| wormhole-williams which is just an outdated implementation in
| GO of the original
| mmmlinux wrote:
| I noticed this when i was actually looking for something
| exactly like this tool earlier in the week. I didn't realize it
| was a recent thing.
| api wrote:
| These are neat but... it's 2025, and there is still no first
| class standardized ways to move files over the Internet between
| PC/mobile/edge devices.
| lxgr wrote:
| That's on purpose.
|
| Imagine being able to just send a file from an Android phone to
| an iPhone without a centralized service and an Internet
| connection (i.e. like we could in the time of feature phones
| and early smartphones via Bluetooth)...
|
| Please think of the shareholders and the lawful interceptors
| before you suggest something as subversive!
| 0xbadcafebee wrote:
| There's a dozen apps that will open an FTP server on your
| phone, then the other phone connects over the network with
| any FTP client.
| lxgr wrote:
| Where do you get the FTP client and server from without an
| Internet connection, and how do you create a network
| between the two?
|
| And would you say that this is comparable in terms of
| complexity with e.g. Airdrop or selecting "send via
| Bluetooth" and picking the recipient's device name?
| jeroenhd wrote:
| > Where do you get the FTP client and server from without
| an Internet connection
|
| Until last year, your web browser will usually download
| files. These days, you have to start an HTTP server.
| Which is actually easier, because FTP is a messy
| protocol.
|
| > how do you create a network between the two
|
| WiFi Direct has been built into phones for at least a
| decade.
|
| > And would you say that this is comparable in terms of
| complexity with e.g. Airdrop or selecting "send via
| Bluetooth" and picking the recipient's device name?
|
| On the sender side, the "send via" option can appear in
| the standard sharing app list. On the recipient's side,
| you may need to scan a QR code to finish the WiFi Direct
| connection. Starting the download should be as easy as
| having the sending app pretend to be a WiFi login portal
| so the phone automatically pops up the web page.
|
| But if you're just sending files offline, there's always
| Nearby Share or plain old Bluetooth if the files are
| small enough.
| lxgr wrote:
| > On the sender side, the "send via" option can appear in
| the standard sharing app list.
|
| Can, but does it? Defaults matter. And how would the
| receiver be notified that they should download some file
| via FTP?
|
| As long as such a feature does not come preinstalled on
| smartphones, I'll continue considering this lack of
| previously commonplace functionality an intentional
| vendor lock-in.
| jeroenhd wrote:
| >how would the receiver be notified that they should
| download some file via FTP You tell them "hey I want to
| share a file with you, scan this QR code". The QR code
| sets up the WiFi Direct connection, the fake portal login
| should auto-open a "click here to download" button (or
| redirect to a file, but I don't think that's allowed),
| and once the file is downloaded you terminate the Wi-Fi
| Direct connection.
|
| But that presumes phones don't have a method to share
| files. They have that feature built in. It's called
| Nearby Share on Android and AirDrop on iOS. Both use some
| weird pairing mechanism and some form of Wi-Fi Direct to
| transfer files, but the interface is just a bit more
| integrated.
|
| When Apple opens up Airdrop or when Google convinces
| Apple to pre-install Nearby Share, we'll get the
| universal file transfer we desperately need.
| pessimizer wrote:
| What about people who have never heard the term "FTP" and
| don't know what a client or a server is?
|
| Nobody cares what we do, we know how to use our computers
| well, and will force them to do what we want them to do in
| ingenious ways, and we will share those ways with each
| other. The problem comes when one of us puts that solution
| into a user-friendly mobile package that can be installed
| and run with your elbow, and then somebody makes a tiktok
| about it.
|
| That app is getting nuked. Maybe even the internal API that
| enabled that app is getting nuked. If it's a standard
| protocol, it's getting extended and extinguished. The
| people who made it and the people who host it are getting
| legal letters.
| hot_gril wrote:
| Honestly yeah, AirDrop is part of Apple's lock-in.
| lxgr wrote:
| Absolutely.
|
| The fact that Google and Apple could quickly agree on a
| standard for both cross-platform Covid contact tracing and
| "stalker warnings" for "Find My" trackers, but not for
| cross-platform encrypted text messaging or an interoperable
| AirDrop extension, shows that it's purely a problem of
| incentives.
| hot_gril wrote:
| Maybe there's a way to send messages/files over the
| covid19 protocol.
| 0xbadcafebee wrote:
| > no first class standardized ways to move files over the
| Internet between PC/mobile/edge devices
|
| FTP? You can open an app on your phone, start an FTP server,
| use UPnP to poke a hole in the router, show their public IP
| address, send a text message to your friend with the IP, port,
| username & password in a single URL, connect, send/receive
| files.
| api wrote:
| I meant modern -- you can use FTP over stuff like ZeroTier or
| Tailscale but otherwise you can't do P2P with it (firewalls,
| V4 NAT) and it's not secure. TS has some facility for
| transfer but again-- TS-specific, not available everywhere,
| not standard, and not suitable for all cases.
|
| I also meant things regular people can easily use and that
| can be used as conveniently as e.g. Apple's AirDrop (which is
| nice but only works between Apple stuff).
|
| It's part a UI/UX problem and part a missing standards
| problem. The latter precedes the former.
| jeroenhd wrote:
| > firewalls, V4 NAT That's why they added 'use UPnP to poke
| a hole in the router'. Which will work on most networks,
| though CGNAT will still break it if IPv6 isn't available.
|
| There are plenty of other tools out there that can send
| files between devices. Google+Samsung's Nearby Share work
| pretty much everywhere. KDE Connect works on any device I
| can think of. I wish Google+Samsung would make it an open
| standard but I'm guessing they won't do it so they can
| rewrite the app whenever they please.
|
| The biggest, and IMO only, problem for AirDrop competitors
| is that they're not pre-installed on iPhones and iPads
| while AirDrop is. AirDrop is nothing special in itself,
| though Apple did implement it in a rather weird way. All
| you need to mimic it is Bluetooth (BLE if you're fancy) for
| handshakes and WiFi Direct for transfers.
| frontfor wrote:
| This is the same predictable reply as the naysayers at the
| launch of DropBox. Both of us know that expecting people to
| set up FTP is a complete nonstarter.
|
| https://news.ycombinator.com/item?id=8863
| wackget wrote:
| This is my constant frustration with phones.
|
| I sit behind a keyboard, mouse, monitor, and an incredibly
| powerful desktop operating system for 99% of the working day.
| These devices are pretty much the pinnacle of human-computer
| interaction; arguably the best tools we have for interacting
| with digital content with speed and efficiency.
|
| But as soon as I want to do something involving my phone, I
| have to physically reach for it and immediately hamper myself
| with its limited UI, screen size, and ludicrously locked-down
| ecosystem limitations.
|
| Smartphones have been around for decades and yet we're _still_
| nowhere close to seamless integration with the rest of our
| devices. The best we 've got are clunky half-featured
| workarounds (Airdroid) or overly-complex techy solutions
| inaccessible to laypeople (VNC).
|
| As another commenter said, it's all very much intentional. It's
| a deliberate choice on behalf of greedy phone manufacturers and
| greedy app developers. And it's really, _really_ frustrating.
| j_maffe wrote:
| If you're on Windows I highly recommend Link to Phone
| pnutjam wrote:
| KDE connect solves most of these problems.
| tredre3 wrote:
| Link to Phone sends all your data (Messages, calls,
| notifications) to Microsoft. It also requires a Microsoft
| account. Admittedly for file transfers it's a bit
| different, if you're on the same network it will attempt a
| direct connection so MS won't get your files. It still
| sends the meta data (file names, file sizes) to Microsoft,
| though.
|
| Similar issues with Smart Connect from Motorola.
|
| An entirely local solution like KDE Connect is better, if
| your situation permits it. Unfortunately it has been quite
| unreliable for me (and I have tried many devices) but it
| seems to work just fine for others!
| ebfe1 wrote:
| Oh i love the use of webrtc for this, thank you for sharing!
|
| This was my half day covid project to share file... inspired by
| firefoxsend a while back...
|
| https://www.relaysecret.com/
|
| the infra is super lightweight and you can deploy yourself with
| aws account, it costed me nothing to run and quite useful when
| needed :)
| lxgr wrote:
| Nice! This uses server-side storage though, right?
| gqgs wrote:
| I don't see which use case this is solving that hasn't already
| been solved by multiple other P2P file sharing browser based
| software available.
| latexr wrote:
| This particular project has existed for a decade. Any file
| transfer service which survives that long is worthy of praise,
| especially now when open-source solutions are being gobbled by
| LimeWire.
| culi wrote:
| Local First Software benefits heavily from p2p solutions like
| these that can be integrated into a larger application
| lxgr wrote:
| I appreciate every single attempt at solving xkcd #949, but so
| far, all I'm seeing is an ever-growing pile of evidence for #927.
| casey2 wrote:
| >filepizza
|
| Horrible name dude
| adzm wrote:
| i like the name. pizza invokes thoughts of sharing anyway
| chmod775 wrote:
| As someone who had the misfortune of moderating a platform
| with filesharing features, I agree that the name is... really
| bad.
|
| (Cheese) Pizza is slang for CSAM.
|
| https://www.urbandictionary.com/define.php?term=Cheese%20piz.
| ..
| culi wrote:
| Wow I had no idea. Yeah then this is absolutely the worst
| possible name they could've picked.
|
| Hopefully this isn't a "they knew what they were doing"
| situation
| jollyllama wrote:
| It's rather sus
| TheAmazingRace wrote:
| Also, un-fun fact and coincidence... Peter Bright, formerly
| of Ars Technica and arrested for Child Enticement, had the
| nickname of "Dr. Pizza" on the Ars forums.
|
| I wish I was joking.
| 0xbadcafebee wrote:
| Ignorant question: isn't WebRTC just... built into the browser?
| Do you really need a stack of 20 things to tell the browser to
| connect to another browser with WebRTC? Isn't one HTML page with
| a few lines of javascript enough?
| hombre_fatal wrote:
| This is actually a good question for you. You have a
| multiplayer browser game and you want to swap out the websocket
| you're using for webrtc. What all would that change involve?
| alexpadula wrote:
| It's a start to something great. Keep it up!
| bilekas wrote:
| Nice project and I always like playing with WebRTC but there is
| something that has me a little concerned .
|
| > Transfers are now directly from the uploader to the
| downloader's browser (WebRTC without WebTorrent) with faster
| handshakes.
|
| Maybe I'm wrong, but there is a signaling server in the middle
| somewhere along the chain here no ? unless it's just the same as
| PeerJS in which you first need the clients ID, but connection can
| be flaky.
|
| From the source I can see it's using PeerJS but react is throwing
| me off a little bit. It's not clear to me what
| `useContext(WebRTCContext)` is..
| stewartbracken wrote:
| Yes, this repo is also an api server which stores peer ids here
| `https://github.com/kern/filepizza/blob/main/src/app/api/crea..
| . ` and here
| `https://github.com/kern/filepizza/blob/main/src/channel.ts`.
| Webrtc implementations typically use a server to connect peers.
| Without, peers need to exchange id's to connect.
| crazygringo wrote:
| > _Because data is never stored in an intermediary server, the
| transfer is fast, private, and secure._
|
| But WebRTC needs a TURN server for when hole punching/STUN
| doesn't work when both clients are behind NAT.
|
| Data is never _stored_ in an intermediate server, but it can
| _pass through_.
|
| How is the privacy and security ensured that the TURN server
| won't/can't read your data? Do you just have to trust them? Or is
| a form of E2EE employed?
|
| I'm surprised this isn't even metioned on the page. Or does this
| not include TURN servers, and so file transfers just fail between
| certain peers? (Which it doesn't mention either.)
| robertlagrant wrote:
| Good point. I didn't think of that.
| phailhaus wrote:
| OP can just not use a TURN server, and it won't work for
| double-NAT traversal. I did this in a side project to avoid the
| security risk.
| eptcyka wrote:
| But you can punch holes even when both clients are behind NAT.
| ranger_danger wrote:
| How so? With both users behind _symmetrical_ NAT? TURN does
| not count as punching holes IMO.
| eptcyka wrote:
| Both clients send a packet to a server, server sends the
| remote IP to both parties, both parties try to send traffic
| to either's remote IP. Unless their nat firewall is evil,
| this should work.
| ranger_danger wrote:
| That's no longer p2p, that's using a relay server like
| TURN
| eptcyka wrote:
| It is p2p, the middle server isn't relaying traffic.
| frontfor wrote:
| If TURN is used, then it absolutely is. Please read the
| comments above.
| saurik wrote:
| That doesn't work with "symmetric" NAT, which was
| specified by the person you are responding to: in that
| case, you can't rely on even a third party to figure out
| the port. To the extent to which this NAT paradigm is
| chosen for its efficient usage of ports, this is fixable
| using UPnP/NAT-PMP/PCP, but 1) I've (sadly) never seen a
| WebRTC implementation which takes advantage of these
| protocols, and 2) usually this isn't chosen for it's port
| efficiency: it is chosen because the NAT provider is
| incompetent (or even actively "evil", lol), and so they
| are almost certainly also not going to support a port
| mapping mechanism.
|
| Regardless, I'll claim that the real disagreement is more
| over how common symmetric NAT is: I claim it is very
| rare, and that the vast majority of NAT isn't
| symmetric... however, in another thread, the user you are
| responding to claims that "in [their] country" they've
| never seen WebRTC work at all. I'd wager that's a pretty
| local issue, with what probably amounts to a local
| oligopoly built with similar limitations, but if you live
| in that world it must be brutal. However, that's not
| WebRTC's problem: we should implement port mapping in
| clients and ISPs should, to put it as kindly as feels
| fair, "fix their shit".
| nikisweeting wrote:
| CGNAT is increasingly common for large ISPs as IPv4 gets
| expensive.
|
| There are entire regions of brazil where all residential
| internet is CGNAT'ed, making any video calls between
| those users symmetric NAT.
| eptcyka wrote:
| What part of CGNAT requires the network address
| translation to be symmetrical?
| nikisweeting wrote:
| > A symmetric NAT is one where all requests from the same
| internal IP address and port, to a specific destination
| IP address and port, are mapped to the same external IP
| address and port.
|
| My understanding is that it's not "required", but most of
| the CGNAT routers I've encountered do symmetric NAT, and
| they force-randomize the source port for each new
| connection, then keep it fixed for one external ip:port
| for some "session" duration, defeating traditional hole-
| punching.
|
| When I've tried to build WebRTC P2P stuff I've
| experienced this making direct P2P WebRTC connections
| between CGNAT users nearly impossible, always requiring
| at least one node with a re-usable hole-punched public
| udp port or a relay server.
| saurik wrote:
| WebRTC, in fact, merely passes e2e encrypted packets through
| the TURN server (which, by the way, is only required if both
| sides are behind _symmetric_ NAT: the vast majority of NAT
| doesn 't cause this problem, though you might need to do STUN).
| ranger_danger wrote:
| > the vast majority of NAT doesn't cause this problem
|
| Hard disagree, I've yet to meet anyone in my country that has
| gotten any WebRTC service to work _at all_.
| saurik wrote:
| FWIW, this doesn't actually imply we disagree, as maybe the
| vast majority of NATs aren't in your country ;P... we could
| both be right!
| polishdude20 wrote:
| A lot of cell networks won't work with STUN. I've tried in
| personal projects to have a home computer with wifi
| communicate through a stun server to a mobile device using
| mobile data. It don't work.
| happosai wrote:
| > the vast majority of NAT doesn't cause this problem
|
| A WebRTC clients behind an iptables based MASQUERADE NAT will
| not work without TURN. Which both incredibly common and weird
| that people designing WebRTC and STUN/TURN/ICE never stopped
| by netfilter developers to make iptables work out of box with
| WebRTC.
| ivanjermakov wrote:
| In WebRTC, TURN server is only used to establish a data
| channel. After that, data transfer us peer-to-peer.
|
| https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/...
| crazygringo wrote:
| That's incorrect. What you're describing is STUN, when it
| works. TURN is what is used when peer-to-peer remains
| impossible. All data transfer is via the TURN server.
| gloosx wrote:
| TURN or STUN server can use the DTLS transport in order to
| encrypt the traffic.
|
| So you know it's secure if you are using _turns: //_ protocol
| and verified the certificate just like it works with _https://_
|
| https://datatracker.ietf.org/doc/html/rfc7350
| filleokus wrote:
| Hmm. I'm not a WebRTC pro but looked into it recently for a
| hobby project and felt that the typical WebRTC TURN
| implementation still leaves the TURN server in a quite
| trusted position. My rough understanding:
|
| - (1) Each client generates a key pair
|
| - (2) The fingerprint of the public key is part of the SDP
| message each client generates
|
| - (3) The SDP message is somehow exchanged between the
| clients, out of band, and the session is started. The
| client's verify the remote peer using the public key from the
| SDP message.
|
| The problem is that it's not really feasible in most
| circumstances to exchange the full SDP message out of band,
| so instead the service provide some mechanism to map a
| shorter ID (typically in a URL) to a centrally stored copy of
| the SDP. I think this might be where it happens for filepizza
| [0].
|
| This means that a malicious file sharing operator, being in
| control of both the TURN service and the out-of-band
| signalling mechanism, could just MITM the DTLS connection and
| snoop on all the data going by. The peer's think they have
| each others public keys but they just have two keys owned by
| the server.
|
| [0]:
| https://github.com/kern/filepizza/blob/main/src/channel.ts
| numpad0 wrote:
| Only the initial SDP needs to be fudged. The attacker could
| just set up two clients that pretends to be the
| sender/recipient. Then the data can just go through regular
| Google TURN servers.
| logicallee wrote:
| For a simple no-frills alternative, I have this version on my
| site:
|
| https://taonexus.com/p2pfilesharing/
| kenrick95 wrote:
| Relevant xkcd: https://xkcd.com/949/
| me2too wrote:
| That's great
| vzaliva wrote:
| We tried something similar 17 years ago. We couldn't achieve true
| P2P, but we managed to relay a data stream via a server without
| store-and-forward. The startup was called Pipebytes, and we even
| got a bit of news coverage:
| https://www.youtube.com/watch?v=ATqKvra1X3o
|
| It was later sold to another company, which scrapped the P2P part
| and repurposed it for regular cloud sharing. :(
| 867-5309 wrote:
| >FilePizza eliminates the initial upload step required by other
| web-based file sharing services
|
| homepage is an upload interface..
| gloosx wrote:
| hmm, it says "Drop a file", not "Upload", on this step it
| uploads the file to your local browser for sharing, but the
| file is not actually uploaded anywhere on the outside
| cassepipe wrote:
| If having someone intall transmission (or your favorite torrent
| client) is not a hurdle, I like the privtracker approach a lot :
| https://privtracker.com/
|
| The reason I like it more is that most torrent clients can run in
| the background by default so it's not dependant on keeping a
| browser tab opened
|
| It made it to the frontpage not so long ago but it'd be a pity if
| you had missed it
| jen729w wrote:
| FWIW I tried this the other week and it did not 'just work'.
|
| It just did nothing.
|
| Then I remembered I have Syncthing running on the machines I
| was trying to transfer between, so I used that.
| dboreham wrote:
| Uses WebRTC, so not actually p2p.
| latexr wrote:
| The thing that usually annoys me about these services is they
| tend to give you an intractably complex URL to share with the
| recipient. This poses a problem because every time I need such a
| P2P transfer, I'm communicating with someone over the phone and
| they need the file on a computer (which may not even be their
| own, so email is also cumbersome).
|
| https://file.pizza does this better than most, as the URL
| consists of real words. But all the words are ingredients in
| English which comes back to being an issue again.
|
| https://pairdrop.net is my go-to, since it allows creating
| temporary "rooms" with just five letters, which are easy to share
| over the phone.
|
| Still, I continue to wait for the holy grail of a P2P service
| which would allow me to initiate a connection via CLI and get a
| _simple_ URL to share with someone who could download the file
| from a web browser, saving me from having to babysit the browser
| tab. There are services which allow you to upload via CLI and
| download via web browser, but they host your file so you have to
| wait for the full upload to finish before sharing the link.
| ryandrake wrote:
| The file.pizza one doesn't look like it's peer-to-peer. You
| upload a file to their server, and then they provide a download
| URL you can share. Kind of the opposite of peer-to-peer. I
| would expect a "P2P" file transfer product to not require any
| intermediate storage besides the sharing user's and the
| recipients'.
| latexr wrote:
| It is peer-to-peer, via WebRTC. It says right there on the
| homepage, when you start a connection, and on the FAQ.
| ryandrake wrote:
| Oh, nice! Totally missed that.
| lotharrr wrote:
| One tricky constraint is that a "simple URL" isn't big enough
| to hold a full-entropy encryption key. So your security must
| either come from PAKE (like magic-wormhole and friends), or
| from the good behavior of some intermediary. And PAKE requires
| a peer who knows the plaintext and will only execute the
| protocol once, which means it really needs to be the person
| you're connecting with and not an intermediate webserver.
|
| I think it's a 2-out-of-3 trilemma: end-to-end encryption,
| short codes/URLs, offline/non-interactive workflow: choose two.
| Or framed differently, if you require proper encryption, then
| either the code/URL must be long enough to hold the full key,
| or you must use an interactive (PAKE) protocol which means both
| agents must be running at the same time (babysitting).
|
| Your last point is an interesting one: we could build a form of
| magic-wormhole where the sender's CLI waits, the recipient gets
| a URL, the URL points to a web page which performs the client
| side of the protocol. The server wouldn't host the file, just
| the decryption agent. Basically _wormhole receive_ in a
| browser. That would match many of your goals.
|
| However I'd be hesitant to do this with magic-wormhole because
| it opens up a vulnerability we don't currently have: the web
| server hosting that page could silently swap out the JS with a
| version that retained a copy of the plaintext, perhaps only
| when the browser is coming from a specific IP. You can't audit
| a webserver for consistent+correct behavior the way you could
| with e.g. the contents of a Debian distribution.
|
| That said, the usability gains of the recipient not needing a
| CLI tool installed might be worth the tradeoff for some folks.
|
| (I'm the author of magic-wormhole)
| latexr wrote:
| > a "simple URL" isn't big enough to hold a full-entropy
| encryption key.
|
| I don't care about that most of the time. When I do I'm
| unlikely to trust some random web service anyway (how do I
| know the author didn't turn rogue the day before and decided
| to send a copy of every file to their own server?).
|
| The service could offer a choice, where picking the short
| link comes with a big red warning. That could even be hidden
| under some setting on the page, since it's the sender who
| needs to understand the implications.
|
| > the usability gains of the recipient not needing a CLI tool
| installed might be worth the tradeoff for some folks.
|
| That's exactly what I'm looking for. Whenever I need one of
| these services, there is 0% chance the person on the other
| side would know how (or have the patience) to install a
| command-line tool.
|
| > I'm the author of magic-wormhole
|
| Thank you for taking the time to expand so thoroughly from
| experience.
| rahimnathwani wrote:
| Just use a link shortener?
| latexr wrote:
| The goal is to reduce complexity, not tack on more crap
| on top. The solution I have now with PairDrop is already
| more convenient than that.
| jech wrote:
| > One tricky constraint is that a "simple URL" isn't big
| enough to hold a full-entropy encryption key.
|
| If you trust the server not to MITM you, then you don't need
| the encryption key in the URL. The URL only needs to be long
| enough so it cannot be guessed by an attacker, 64 bits should
| be plenty. Once the peers connect to the common URL, they can
| generate an arbitrarily large key by performing ECDH through
| the server. (This is where you assume that the server is not
| doing MITM.)
| noAnswer wrote:
| https://rdrop.link gives you six characters. It's IMHO
| "telephoneable".
| latexr wrote:
| That's a lot of red! I didn't know about this one, thank you
| for the share. I suspect I still won't use it over PairDrop
| because the web page is too busy, the "Check out my other
| projects" completely draws the eyes, and I want something
| that's clean and not distracting for the receiving end.
| apitman wrote:
| You seem pretty determined to not have your problem solved.
| tripflag wrote:
| > There are services which allow you to upload via CLI and
| download via web browser, but they host your file so you have
| to wait for the full upload to finish before sharing the link.
|
| There are exceptions to this; I've been making copyparty[1], an
| httpd which lets you start downloading a file that is still
| being uploaded[2]. If you catch up with the uploader, it'll
| throttle the speed so the browser doesn't drop the connection.
| Uploads and downloads can be done through browser and/or cli.
|
| I recall there was at least one other alternative with similar
| functionality somewhere on the awesome-selfhosted list, but I'm
| failing to find them right now... It was prominently mentioned
| in the project's readme, but maybe that's no longer the case.
|
| [1] https://github.com/9001/copyparty
|
| [2] https://a.ocv.me/pub/g/nerd-stuff/cpp/2024-0418-race-the-
| bea...
| latexr wrote:
| > copyparty
|
| Great name!
|
| Unfortunately this seems like it's something I'd need to host
| myself, and that's something I specifically don't want to do.
| I only need to share on occasion, and always want to do it
| with the least hassle possible.
| tripflag wrote:
| Yep, and the server bandwidth can become a bottleneck if
| the peers are fast enough, so true peer-to-peer is still
| the better choice, or something webtorrent-based if
| multiple people are grabbing the same file.
|
| But there's been enough last-minute submissions of DJ
| material by now that I'm still happy it was added as an
| option :-)
| apitman wrote:
| Why throttle the browser rather than just having it block
| until more data arrives?
| makeworld wrote:
| > initiate a connection via CLI and get a simple URL to share
|
| https://webwormhole.io does this, see the CLI link at the
| bottom. Just tested it myself with a small file.
| latexr wrote:
| This does look quite close to what I wanted. Thank you.
| Unfortunately, it also looks to no longer be under
| development.
| johnisgood wrote:
| It says that the last commit is from 2 years ago. Is it
| because it is completed, or because it really is no longer
| under development?
| latexr wrote:
| If it were completed, the author should have
| closed/rejected every issue and pull request and removed
| this large warning at the top of the README:
|
| > THIS PROJECT IS STILL IN EARLY DEVELOPMENT IT USES
| EXPERIMENTAL CRYPTOGRAPHIC LIBRARIES AND IT HAS NOT HAD
| ANY KIND OF SECURITY OR CRYPTOGRAPHY REVIEW THIS SOFTWARE
| MIGHT BE BROKEN AND UNSAFE
|
| Plus, install instructions are outdated. As soon as I
| tried them, `go` complained of using a deprecated method.
|
| So everything points to it no longer being under
| development.
| GoblinSlayer wrote:
| Not much development can be done about experimental
| cryptography, you just use it and that's all.
| Cryptographic review can't be written either. Also you
| said you don't want much cryptography.
| latexr wrote:
| > Not much development can be done about experimental
| cryptography
|
| That's not the bit that matters, it's the "this project
| is still in early development" and "this software might
| be broken". Those are the things which hint at the
| project not being done.
| johnisgood wrote:
| Send a pull request and I will review it personally. :P
| saljam wrote:
| i'm the author. i keep a close eye on it for any security
| issues but i'm not adding any new features, hence the
| lack of commits.
|
| i also obviously maintain the instance on
| https://webwormhole.io/.
| makeworld wrote:
| Thanks for maintaining it! You might want to update the
| CLI instructions to use "go install" as the current
| command doesn't work.
| johnisgood wrote:
| That is what I thought. Thank you for clarifying.
| latexr wrote:
| It wasn't the lack of commits which made me think this
| was abandoned, but everything else (outdated
| instructions, issues and pull requests open with no
| reply, giant warning at the top of the README...).
|
| https://news.ycombinator.com/item?id=43351944
| johnisgood wrote:
| Yeah, the installation instructions should probably be
| updated at the very least, and perhaps that warning
| should be adjusted as well.
| anacrolix wrote:
| What about creating and seeding a torrent with a CLI then
| creating a shortlink to magnet link?
| latexr wrote:
| That is the opposite of what I want, everything about it is
| harder to share over the phone. Magnet links are not exactly
| short and now I'm asking people to install a BitTorrent app
| too, on a computer which might not even be theirs.
| quantadev wrote:
| Has anyone used this kind of technology to create a kind of one-
| on-one messaging system that maintains a persistent thread (in
| browser storage) which can sort of simulate "texting" but without
| the phone?
| u7i7i8o8o8 wrote:
| Cool concept, has been done a few times before. Would prefer to
| see a cleaner implementation. Do projects like this really need
| Tailwind, TS, React? I don't think so.
| BiteCode_dev wrote:
| I miss dukto r5.
| ethnographers wrote:
| I use https://blip.net which is like a cross-platform AirDrop,
| but also works over the internet in addition to LAN. Probably the
| fastest one I found.
| tomazsh wrote:
| Hey, our team made Blip! Glad you like the speed :)
| doodlebugging wrote:
| I am intrigued by this. I read everything on your site. It
| looks great since it apparently allows transfer between
| devices using different OSes and that is always the sticking
| point around my place. I have several incarnations of Windows
| (7-11), a couple of linux distros (PopOS, CentOS7), and iOS
| on our phones. I see that linux is currently not supported
| though you would add that if people request it.
|
| That's great.
|
| My question for you is about the security of the data being
| transferred. You're using TLS according to your docs and this
| app transfers directly peer to peer. Is this secure FTP using
| TLS?
|
| You have two tiers for users - Community and Business.
| Community is free and donations encouraged. Speeds may be
| slower to prioritize paying customers and support is more
| crowd-sourced. Business gets fastest speeds and direct
| support.
|
| I am not a subscription buyer by choice. I would like to help
| make this profitable for you. Would you consider offering a
| paid version for personal use that would give faster speeds,
| security updates, and bug fixes at a price point between Free
| and Business? $300/year is way too much for something that
| would be used as a personal tool to quickly and securely send
| documents and photos to family members.
|
| I realize that the donation model could function like a one-
| time payment model since you are likely using it
| intermittently and sending a small donation for each use so
| that your annual costs are minimized. In that case you always
| use the most current version. You "own" that version during
| the period that you use it and you pay a reasonable donation
| for use of it.
|
| I also don't see the need to establish an account if this is
| a p2p service since the data transfers should walk from my
| device to the destination device. Fill me in on why I need an
| account.
|
| I would pay for a license to use this with the expectation
| that the license would provide the current version of the app
| plus all bug fixes and security fixes for that paid version
| and that upgrades taking the app to the next full version
| would be discounted to existing users. I could be a long-term
| customer.
|
| As an example, I use an antique, unsupported version of
| SnagIt on my machines. I purchased the license years ago,
| upgraded through a couple of versions until they got to a
| point where they dicked up the interface and changed the tool
| availability and so I ditched the newer version and have
| continued using the old version which work great. I still get
| the nag screens to update to the new version but the click to
| close that dialog is now muscle memory for me.
|
| I appreciate the functionality that this app, blip, provides
| and would like to be a paying customer and use the app but
| I'm not interested in a subscription model.
|
| EDIT: I forgot to note a slight error in one of your replies
| to a FAQ.
|
| Under the "Blip vs Aspera" comparison in the FAQ "Why is Blip
| easy to use?" there is a fat-finger spelling error.
|
| The sentence reads:
|
| > We want you to set up any use it by yourself!
|
| I believe that it should read:
|
| We want you to set up and use it by yourself!
| sellmesoap wrote:
| I came across this recently while looking at cosmopolitan lib
| stuff https://bob.osau.re/
| gsliepen wrote:
| "It's peer-to-peer, trust me bro!" The problem is that you are
| still using a website provided by a third-party to serve you the
| JavaScript program that initiates the transfer. It's easy to
| replace that JavaScript by something that just transfers a copy
| to the third-party itself. To be sure that the transfer is
| actually peer-to-peer, either the sender or receiver should run
| their own fillepizza server (and have verified that the source
| code does not contain any backdoors or phone-home code). But if
| you do that, you actually don't need a peer-to-peer solution
| anymore, it's turned into a client-server problem.
| nikisweeting wrote:
| Ideally it's all a single html file that both sides can just
| open locally, no HTTP servers required.
| desdenova wrote:
| Didn't work here.
|
| The downloader connects, status becomes Ready, then nothing
| happens.
|
| Tried on both Firefox and Chromium.
| EGreg wrote:
| Isn't this easy to do with just WebRTC? Like, a few lines of code
| and using some signaling server and relay (STUN + TURN)?
| gruez wrote:
| There must be dozens of services like this (ie. peer to peer file
| sharing over webrtc), but I can never get them to work.
| Presumably it's because often times one or both of my devices are
| behind strict NAT, and the service doesn't provide a TURN server
| (understandable, given that it might be bandwidth intensive).
| Does anyone know any public/self-hosted service that provides a
| TURN server?
| deknos wrote:
| Which browserbased p2p file transfer tool works with STUN and
| TURN servers? and if possible, also with an cli option?
| seanwessmith wrote:
| is there any tool for p2p audio? something to communicate with
| friends while gaming would be cool
| genpfault wrote:
| Jami[1]?
|
| [1]: https://en.wikipedia.org/wiki/Jami_(software)
| DeathArrow wrote:
| Why can't we have a mixed system? A Dropbox like service with
| built-in file sharing. If there are no other peers or the speed
| of transferring from peers is slow, you use some servers for
| seeding.
| dusted wrote:
| I did the same thing a long time ago, though I cant brag about
| using as long a list of frameworks, source is
| https://github.com/DusteDdk/fileswithafriend so you can host it
| youself, announcement post and link to site where it can be used
| is here https://news.ycombinator.com/item?id=39622511
|
| In my version, the entrypoint is not uploading your file (where
| would it go??) but establishing the connection between two
| devices, then bidirectional transfers between them.
| thenthenthen wrote:
| Is it strange that non of these ever worked for me over the years
| in different places/setups? (between windows/linux/osx).
| Literally never. Always been thinking of writing my own... I
| guess thats why there are so many :p
| Alifatisk wrote:
| Idk if this will replace the good ol' snapdrop / pairdrop
___________________________________________________________________
(page generated 2025-03-13 23:02 UTC)