love Wormhole, but that animated background chews up an incredible amount of battery power on my M1 Macbook Air (even when the tab is in the background). Please wormhole crew, turn it off.

We recently made a one-line change that massively reduced GPU usage, specifically:

- Intel integrated graphics: 60% reduction

- AMD Radeon: 40% reduction

- Apple M1: 10% reduction

What was the change? We removed "opacity: 85%" from the <canvas> element. We were using opacity to slightly darken the animation but now we just darken the texture image directly.

Would love to read more about this.

We just massively reduced GPU utilization on Wormhole for a second time (as of May 12). Give it a try and let me know if you still have issues.

GPU utilization when window is full screen, 4K resolution:

Chrome:

  - Radeon: 70% -> 15%

  - M1: 65% -> 29%

Firefox:

  - Radeon: 60% -> 8%

  - M1: 55% -> 23%

Safari:

  - 15% Radeon + 75% Intel -> 8% Radeon + 8% Intel

  - M1: 75% -> 35%

A bit more detail: We're running into the limits of WebGL. It seems just rendering a white screen at 60fps at 4K resolution is enough to make people's fans turn on.

So we reduce the frame-rate when the wormhole is not warping (render every 3rd frame). We also lower the resolution and scale it up.

You can "hide" it with uBlock Origin by blocking large media elements in the popup.

Thanks, much better experience

100% agree - I've used Wormhole a few times when I try to quickly get data into interactive VM sessions, because it works great otherwise, but the graphics consistently grind the whole thing to a halt.

I really don't get the reasoning. It looks kind of cool, but it makes it super unusable for a bunch of use cases from very old computers to interactive sessions on raspberry pis to constrained VMs. And those are exactly the kind of places where I want friendly easy tools to copy files across for quick system admin or to get logs back out! Doesn't seem like a good tradeoff.

I use rclone serve for this task:

rclone serve http ./dir/or.file --addr :9000

File/s can be grabbed with curl/get etc or a browser

See: https://news.ycombinator.com/item?id=27060566

Set webgl.disabled to true if you're using Firefox.

And if you have a sucky connection, it's slow has hell to load.

Sorry to hear the site was slow for you. We get pretty good scores on Lighthouse and from real-world data according to https://developers.google.com/speed/pagespeed/insights/?url=...

What OS, browser, and connection type/speed did you use?

Ubuntu, Firefox, sucky country adsl with unkown speed.

I don't mind for the upload to be slow, I just let it run, but getting to the page should not be.

I mean, this galaxy.jpg file is a third of you webpack JS bundle size!

It has no added value for me. I get the cool factor, I know it's pretty, but still.

You could add a "fast" or "lite" or similar subdomain that avoids anything like the complaints that have been shared here. Not perfect (the default should be the best), but at least you could avoid this problems as a user.

Turn on "reduced motion" setting on your Mac.

Wouldn’t it be easier for you to manage what you expend your battery on?

Great idea, do you have any suggestions that will help?

Hmmm, it seems like https://webwormhole.io/ has changed from last time I used it. https://wormhole.app/ seems more similar to what I remembered as frontend.

I remember trying many of those services and I decided to use this one because I could send large files without any problem (was trying to move sqlite dbs that were several Gbs, as it seemed to stream the file instead of trying to store it on ram first, but now I see wormhole.app allows up to 10GB, and I don't remember to have any limit.

WebRTC services seem to have problems to get up to speed, but for streaming files between devices it seems the best solution in terms of friction.

The speed problems interestingly seem to be caused by a bug in an implementation of SCTP used by most (all?) WebRTC browser implementations:

https://github.com/saljam/webwormhole/issues/55

The symptom seems to be that the SCTP data rate drops with increasing latency (which used to be a problem with very old TCP implementations too, but all modern ones handle high-latency networks much better).

I think SCTP has everything we need, just more knobs need to be exposed [0]

I have gotten feedback about the performance about Pion's SCTP implementation as well. It is a hard problem. The amount of people who care about SCTP performance + WebRTC and are able to work on it is very small.

If anyone is interested in more about this [1] is a fun issue to read.

libwebrtc is also planning to stop using libwebrtc soon. That would mean all browsers (Chrome, Safari, FireFox) will be on something new. Could be good no idea yet. The ongoing work is here [2]

[0] https://github.com/w3c/webrtc-extensions/issues/71

[1] https://github.com/pion/sctp/issues/62

[2] https://webrtc.googlesource.com/src/+log/refs/heads/master/n...

Thanks, this is great context! Especially the very different focus in these two projects explains a lot (lightweight control channel for A/V [1] vs. the entire reason for using WebRTC in all of these file transfer projects).

Curious to see how the new implementation will play out for the browsers!

[1] https://github.com/w3c/webrtc-extensions/issues/71#issuecomm...

*libwebrtc is also planning to stop using usrsctp soon

I‘ve also built a file transfer tool (CLI) with emphasis on decentralization. It’s a fully decentralized p2p file transfer tool based on libp2p:

https://github.com/dennis-tra/pcp

I‘m currently trying to make it interoperable with https://share.ipfs.io/#/ which resembles the functionality of the posted tool.

Seems very similar to 'hyp beam': https://github.com/hypercore-protocol/cli

There's also https://snapdrop.net which seems extremely similar to sharedrop.io but has an additional useful feature of letting you send messages which I sometimes use to send links to devices that aren't logged into any service.

Ah neat! I've added all of the links in the comments here to my list - great to see what's out there and to combine our collections.

As I recall, there's a difference between file.pizza and webwormhole. file.pizza allows the sender to specify files and then generates a share url, whereas webwormhole creates a share link first. The latter can be useful if you're not sure exactly what you'll send before you share the link.

There's also https://github.com/schollz/croc which is a very simple P2P CLI transfer tool.

Missing https://dropbox.com/transfer

Is that using WebRTC, or are they hosting the files on their backend?

I’m a fan of Kipp! Not p2p, but has optional encryption

https://kipp.6f.io/

I made these:

https://file.io

https://temporary.pw

> I track these tools

How frequently do you validate that they are still functional?

I tried File Pizza several months ago, and neither I nor the recipient could get it to work.

Links are checked at least once daily - I do have a few that are recently broken that I need to address - but File.pizza is okay again. I have switched the main link to Wormhole, because it's now my preferred option - and because File.pizza has been up and down for me in the past as well.

The website is up - the actual transfer service no longer seems to function in modern browsers. Have you (or anyone) had a successful transfer via File Pizza recently?

Just tried with a tiny file, it tries to work, as I can see the filename/size on the receiver end. But, it never downloads. It does say "Peers: 0, Up: 0, Down: 0".

Ok - I see. I suppose I will need to find a way to verify some of these links a bit deeper. Thank you for doing the footwork on this!

I swear I've tried it several times over several years. I've never gotten it to work.

http://Gofile.io File sharing and storage platform, unlimited and free

https://snapdrop.net/ is another

We build a web app for e2ee file transfer:

https://arcano.app

That website or yours should be its own hn article.

Thanks, useful site!