kids these days... in my time, we used to know each other's IP addresses and just used netcat
In my time, we used to bring floppies to the schoolyard and just swap them.
If that counts then you can use a flash drive and the problem is solved.
Peer-to-peer file transfers in the browser
91–100 of 272 posts
Re: Peer-to-peer file transfers in the browser
#92Earlier quoted context omitted.
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.
I think Vivaldi have both RSS and email, it's sort of the spiritual successor to the original Opera.... I miss the old Opera.
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.
Re: Peer-to-peer file transfers in the browser
#93Re: Peer-to-peer file transfers in the browser
#94It'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?
I think it's because of all the NAT, which makes any attempt cumbersome for a lot of people.
Re: Peer-to-peer file transfers in the browser
#95Nice 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..
Re: Peer-to-peer file transfers in the browser
#96I 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.
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.
Re: Peer-to-peer file transfers in the browser
#97Re: Peer-to-peer file transfers in the browser
#98Opera 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 windo…
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.
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.
Re: Peer-to-peer file transfers in the browser
#99> 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.)
Re: Peer-to-peer file transfers in the browser
#100> 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 E2…
Good point. I didn't think of that.