This project needs your help again

[schollz]

Over a year ago I asked for your help with donations to keep this project publicly available. Since then about a half million people have downloaded croc making it a ubiquitous resource for thousands of people. Thanks to your help and the grant from DigitalOcean I was able to fully fund the croc server for over a year.

But I need your help again. The cost of croc is mostly bandwidth - over 8 terabytes of data is sent every month through croc! That's amazing to me since I started this project just as a way for me to share files with friends. Four years ago, the public relay server only costed $5/month, but now it is costing me $40-50/month. The higher cost is enabling file transfers for thousands of people all around the world.

But I can't maintain paying that much personally, so I would appreciate if you could sponsor me, at any level. Your sponsorship will go towards these costs.

[kisamoto]

Hey Zack,

Are there any options to sponsor you that aren't a subscription? I'd happily do a $20 or so one-time to say thanks. Just discovered Croc and tested it with your public relay. Will probably host my own but understand the struggles.

Thanks again and keep up the great work!

[schollz]

Hi @kisamoto, yes, here are some other options to donate to croc:

• PayPal https://www.paypal.com/paypalme/ZackScholl
• Bitcoin: 3DkN7b4X2qBHA6je6UsnmkcLPJNsrKYN2Y

[jimcost]

Gladly! I am one of those people in the 8TB pool. Fantastic tool, much appreciated.

[kisamoto]

Hey @schollz - I was thinking more about this.

Could you look at hosting your relay on something like a Hetzner dedicated with unlimited bandwidth? I don't know the specs of the machine you need but you could try the server auction to find something cheapish (~30 eur/month) with unlimited traffic.

Even their cheapest EUR 5/month cloud servers include 20TB of traffic. Maybe it would help lower/limit the spend?

Edit: Maybe it's a conflict with your DO sponsor? Perhaps you could see if Hetzner would sponsor you?

[mirage335]

Please keep hosting the public relay, we developers have desperately needed something like this to get going to workaround NAT for a long time now!!!

Soaring Distributions LLC (of which I am the manager) can gladly increase sponsorship if needed . Please contact me anytime, either personally as the manager, or preferably contact Soaring Distributions LLC through businessmirage335+distsponsor ' a T' gmail 'dot ' com . Or @mention me. Or anything. I am findable.

Would much rather be asked for a few tens of dollars for a while than for this service to disappear!!!

[zoonderkins]

Maybe I can set up a backup public relay. If you need to ~

[Technetium1]

Scaleway has unlimited bandwidth and pretty good prices.

[ferebee]

We’re talking about very little money here. I only use croc occasionally, so I’m sponsoring at the lowest level. But corporate sponsorship should easily cover all expenses and more. It’s just a question of letting people know.

Right now the README says, “This project is supported by GitHub sponsors”.

At the very least, that could say, “Please consider sponsoring this project on GitHub to help cover the rising bandwidth costs of the public relay!” And the link could point to a landing page explaining the need for support rather than the general sponsorship page.

Next step up would be to find a hosting sponsor to host the relay for free, and add a compile flag to include a sponsorship message. The precompiled binaries could include the message somewhere discreet, with the makefile defaulting to compiling without the message. How about, just an example,

croc version v9.5.6-b7e4a73
public relay proudly sponsored by Hurricane Electric he.net

[Photosounder]

I just found out about Croc and I think it's very nice, but I'm a bit shocked that the "relay" doesn't just stick to helping setup NAT traversal and instead actually relays all the data. If anything, the fact that you even considered this way to do things viable says a lot about how cheap bandwidth has become. It seems like working on NAT traversal to avoid paying for huge bandwidth transfers would be an obvious direction to pursue.

[5uy4n9]

@Photosounder maybe you could try croc over tailscale

[pepa65]

@Photosounder @schollz This can't be true, right? The relayserver is only for establishing the connection, the transfer is NOT going through the relayserver, correct?

[schollz]

@Pepa64 There are multiple modes for transfer depending on the scenario.

First the two computers sending/receiving try to detect each other (peer discovery) and don't use the relay server.

If that fails, they ask the relay server for the information which can sometimes provide information so the two computers can connect without the relay.

If all that fails, the data goes through the relay. This is most common when doing transfers across firewalls, traversing NATs.

AFAIK there is no consistent way to connect two computers directly when traversing NATs. Even WebRTC other "p2p" networks uses STUN servers (relays) to traverse NATs.

---

Back to the topic of this issue -> bandwidth that croc uses now has reached 20 TB / month. This is getting exceedingly expensive for me and the project needs donations more than ever. I have 21 sponsors who have been amazing at supporting croc over the last years, but I have to keep the sponsorship growing since croc is growing and need your help to do it! https://github.com/sponsors/schollz

[Migelo]

Syncthing solved this problem by having people host public relays themselves, here is the live-updating list.
From my understanding when I run croc relay that relay is not public? I am more than happy to host a relay or two, just like I do for syncthing where my two relays transfer multiple TBs per month.

[pepa65]

From my understanding when I run croc relay that relay is not public?

It might be a good idea to have an option to make a relay public. Of course that then needs to be managed/balanced and published somehow...

[schollz]

Relay lists are possible, slightly tricky because there needs to be a super relay to make sure the two peers meet at the same relay.

Beyond bandwidth there is a crucial need for more sponsors to keep development up on this project.

[afontenot]

If all that fails, the data goes through the relay. This is most common when doing transfers across firewalls, traversing NATs.

AFAIK there is no consistent way to connect two computers directly when traversing NATs. Even WebRTC other "p2p" networks uses STUN servers (relays) to traverse NATs.

Not 100% consistent, but implementing hole punching for Croc would probably eliminate the majority of relay traffic. It's a relatively easy win and would improve performance for users as well (in cases where their available bandwidth surpasses that of the relay).

Note that other "PAKE transfer" projects already have NAT traversal implemented, so there's some potential inspiration there: magic-wormhole.rs. In my testing this works very reliably with both ends firewalled and NATed.

Some existing relevant issues: #481 #108

It's true that having a relay is not optional if you want transfers to be 100% reliable, but there's not a good reason (IMO) to default to a relay when it's possible to open a direct connection, e.g. with NAT traversal. Using the public relay should be the option of last resort.

[github-actions]

Stale issue message

[Technetium1]

I strongly agree that hole punching is appropriate, and the public relay should be a last resort.

[github-actions]

Stale issue message