I dig Crate, but we don't really do the same thing. letscrate.com is an really awesomely designed and implemented cloud storage provider. Sendoid.com is an in browser file transfer method. I wouldn't consider us competitors (at most very indirectly) and think more than anything we complement products like Crate or DropBox.

Hmm... I see that it's implemented differently, but aren't they accomplishing the same user task? Fundamentally, they're both solutions to the "this file is too large to email" problem. Or am I missing something?

Letscrate makes you wait for the upload to finish before you get the link. Sendoid gives you a link instantly, regardless of file size.

The free version of Letscrate limits files to 50MB and your library caps out at 200MB; the $9/month plan allows larger files and caps out at 10GB. Sendoid is free for all file sizes and imposes no caps on the size of your library.

Letscrate offers no security measures. Sendoid creates an encrypted link between sharer and receiver, and has options for password-protection and one-time usage.

Looks so to me but I think the difference is transfer speed. I tried transferring a 200 MB file and it was very quick (over the local network).

I couldn't try that with Crate (I don't have a pro account) but uploading a 25 MB file had taken 10 minutes before I gave up and decided it wasn't worth it.

Agreed. Want to talk privately sometime (email in profile)?

Thanks for the mention! A lazy link because I'll never miss a chance to shameless plug: http://letscrate.com/

Excited to check out Sendoid though.

So good you guys are blocked at the local library.

I see it as validation and a compliment, well done.

I'd have done the same thing. And yes, I upvoted your shameless plug. ;)

Really like both Sendoid and LetsCrate - good work guys. Just to shamelessly plug another link - a project that i've been working on (for the past 6 months) aimed at super simple file sharing : http://www.filepigeon.com - hope you don't mind the plug - thought it was related and it's something I've been working on for a while !

Looks very good. Found a small bug - At the pricing page I see a logout link, though I am not even logged in.

There's a limit in file size for the "free" plan (50mb?). What makes Crate a better alternative to Sendoid?

This is a total deal breaker for me. This is something that needs to work for all files in order to be useful, and I'm not willing to get tied into a monthly subscription for something so occasional and basic. This is the kind of thing that people used to charge $5-20 one time for as shareware, not $9/mo.

Not very useful as only 50MB is too close to what one can send via Gmail. Anything larger than that I've been using http://www.streamfile.com (150MB, which beats all of you. And it was created by an HN'er before it sold, I think).

I just miss my drop.io.

Crate is really great, and I definitely like their UI a lot more, but Sendoid really knocks it out of the park in terms of speed and security.

Tell me more about how this solves security problems? (I'm asking, I don't already have an opinion). Why can I trust this service with (say) a zip file full of source code?

It forms an encrypted direct connection between the sender and the receiver. The data never touches anyone else's server and is encrypted the entire trip.

Everyone feel free to run a tcpdump dump of the traffic if you want confirmation thats not from the guy who made the service.

Really? You wrote custom crypto for this? Or do you use an SSL connection?

I wouldn't have thought to ask that. My original concern was: how do you assure someone like me that an attacker can't redirect files to other locations?

The protection against redirection is inherent in the underlying peer-to-peer media streaming technology we built on top of (RTMFP), as is the crypto. Going off your profile you seem to be a security researcher type. Would love to discuss things further with you offband. Feel free to email me directly, email is in my profile.

I don't believe that your email is there. I may take a whack at it later this week (we're launching a product and I'm pretty busy, but I do love me some custom crypto protocol.)

Please, please, please share your findings :) Your blog is the sad little feed in my Google Reader list that never gets any love, and, while I appreciate that you're getting shit done instead of entertaining the unwashed masses such as myself, I think this could be a great article. So again, please :)

A really old version of it - http://replay.waybackmachine.org/20060906221358/http://www.a...

Emailed you instead.

Interesting. How do you punch through NATs and firewalls? If you're doing it with p2p proxies, how do you do authentication and avoid mitm attacks?

If Sendoid is completely relying on RTMFP then the core security technology would have to be coming from Adobe. Check out Matthew Kaufmann's two year old talk on the subject: http://tv.adobe.com/watch/max-2008-develop/future-of-communi... Or Tom Krcha's blog which contains a number of Flash P2P entries: http://www.flashrealtime.com/ RTMFP is pretty fascinating technology that originates with a couple of very smart guys that Adobe brought on board (Matthew Kaufman and Michael Thornburgh). I'm curious if the Sendoid team has a non-Flash solution for 'restricted' devices.

If I understand RTFMP (what I know I got from reading Cumulus, an open source C++ implementation), the security side of this is not thrilling me:

* It's Diffie Hellman for key agreement, which is trivially MITM'd (odds are, you can even zero out the DH key and it won't notice).

* It uses AES in CBC mode with all-zeroes IV's (so it's less secure than CBC mode).

* It's using a 16 bit CRC for message integrity checks instead of a cryptographic MAC.

I say all this with the caveat that I could be misreading Cumulus or Cumulus could have it wrong, but if this is where RTMFP is today, then Sendoid is substantially less secure than an HTTPS file transfer site.

Thanks, and I'm hoping that part of flash works better than the video component on 64 bit linux.

sendoid avoids storage/bandwidth overhead ... from now on letscrate is "old school"