tashmahalic

Sending medical records is one of our target cases. We will be HIPAA compliant.

I think we can sustain unlimited bandwidth because we're transferring files peer to peer, so the bytes go direct from sender to receiver. They don't have to go through our servers (except when P2P fails). So, we don't pay for (most of) the bandwidth. We're enabling you to use the bandwidth you're already paying your ISP for.

Our crypto design is this -

1. The sender generates an AES-256 key for the transfer. 2. The receiver sends a public key to the sender. 3. The sender encrypts the AES key with the public key, and sends to the receiver. 4. The receiver decrypts the AES key. 5. The sender then sends all the bytes, encrypted with AES.

The point of using the AES key is that it's faster to encrypt/decrypt. The point of using the public/private keys is to get that key to the receiver in a secure way.

The transfer has a session key from our server so each peer can validate the identity of the other peer.

How's that sound?

THAT's a problem. We're trying to figure out why that's happening. Thanks for letting me know.

Thanks for letting me know. We need to find a way to fix that.

What about Channels? If you have your grandpa install WireOver, and you set up a channel with him, all your sends over that channel can't be faked. He gets notified via the installed tool (dialog: "Would you like to accept files from Myrth?"), not via email, so there's no longer a need for him to download an executable.

Does that address your concerns?

That's strange. We have nothing to do with drop.io.

I can see how clear explanations of what's happening are important to build trust. We're going to improve on that.

That's also a concern of ours.

We're doing the downloaders because it let's us do p2p, which is how we can offer free and unlimited. It also affords end-to-end encryption, and resumable/restartable transfers.

We think we can mitigate those concerns some by code-signing the exe, having the download from https, and building a recognized brand.

Also, we're considering a feature called "Channels". After you set up a channel with your grandpa, it can be trusted. You just drag files onto your "Grandpa Channel" and they go to his HD in that channel's folder (he gets a pop up to accept/decline). This also ends up being a convenience for frequent sends because you don't have to enter your recipient's email - you just drag and drop files onto the channel and they start going.

Does that address your concerns?

creamyhorror, you have perhaps the best HackerNews username ever. Whatever was your inspiration?

WireOver was born out of sheer annoyance, because it's ridiculous that sending files over WANs and LANs is still such a pain.

Our guiding principle: BE NOT ANNOYING.

Ads would be annoying, so they're out. File size limits are annoying. Failed transfers are annoying, slow transfers are annoying, cluttered UIs are annoying, not sleeping well at night because you're worried about security is annoying.

Transfers should find the fastest route automatically - over internet or LAN - and they should go seamlessly between Mac, Windows, and Linux. That's what we want ourselves as users. We'd be pleased as punch to lower the annoyance level for others too.

To give a proper introduction - I'm Trent, one of the co-founders of WireOver. We want our tool to become indispensable to all of you, and I really appreciate your feedback. I'm always impressed by how smart and useful your comments are. Thanks in advance.

Please give WireOver a spin and let me know what you think. I'm trent@wireover.com.

Your recipient gets an email with a download link. The link downloads a downloader. You run it, it downloads your files, then it deletes itself, unless you elect to install WireOver.

Try it out and let us know what you think!

That's exactly right. We think most people will love the free tool for their personal use, and that many businesses will be willing to pay for End-to-End Encryption and CloudCache.

We'll put up some more info about us in the near future. Here's a bit: we're programmers from the computer simulation world, data visualization world, high frequency trading world, and desktop application world. This tool is our first beta - we're looking to prove people will love it, and get your feedback about how it can be better.

So - thanks for your feedback!

We're building the tool to send your bytes peer to peer (UDP hole punching) when it can, which works ~90% of the time. When it fails, we route your bytes through our servers. We don't store your bytes.

Having a linux version is important to us too. We'll have one.

Trent here, from WireOver. The tool isn't a virus or malware, don't worry. It's just a file sending tool. We'll put up terms of service and a privacy policy very soon.

I'm planning to use Paypal Adaptive Payments for a site I'm building. Can anyone save me?

I'm building a Ruby site and will charge my users automatically on a monthly basis, based on their usage, so their charge varies. They agree to a billing agreement when they sign up, and their charges will vary mostly between $0.25 and $5.00.

I need a payment service that:

(1) enables me to automatically charge my users varying amounts (without them approving each time),

(2) has a decent micropayment fee structure ($0.05 + 5% for less than $10),

(3) allows my users to pay with any credit/debit card without requiring a proprietary login (e.g. Amazon), and

(4) can store my users' billing info so I don't have to be PCI compliant - I just do an API call to charge them.

The only service I've found meeting my needs is Paypal's Adaptive Payments API. I've had some bad experiences in the past with Paypal and I'm wary based on others' feedback (e.g. "Paypal is the Anti-Christ"), but I don't see any other option.

Does anyone know of a good alternative?