Missing from the article (and the linked summary of other sites that do this) is letscrate.com, which does it so well that I'm not even interested in looking at sendoid. It's dead easy, and my clients understand and remember the name after I say it once.
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.
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 !
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).
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 :)
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.
I like the emphasis on sending rather than hosting. I think the Drop in DropBox makes sense for sharing folders, but I don't think it makes sense for sharing individual files. There are services for hosting different types of large files, like Vimeo, DropBox, GitHub or just a web server. Secure transfer of files is a different problem from the user perspective IMO.
I also like how they've went through the trouble to actually make it more powerful than (most of) the competition, by allowing direct connections. (Sure, AIM supports it but it's brittle, has a confusing UI, and requires more coordination between users.)
We definitely agree and think it's a huge area that's been overlooked. Files keep getting bigger and it takes forever to get them up to hosted services.
We're hyper-sensitive about our data as well, and wanted to create something that gives people built-in security and privacy but make it all super-easy.
Excellent service! I tried it and it's very simple and easy to use. I'm curious... how does one initiate a P2P transfer between two computers using just browser technology?
Haha yeah, its a pretty awesome addition to Flash. I kind of gloss over that word because I hate Flash as much as the next hacker, but it provided a method to solve a problem that was plaguing John and I and was impossible to solve otherwise.
You should mention that it uses Flash. I have a Flash blocker installed, and when I tried Sendoid just now it simply failed to connect. I thought "What a piece of crap," and closed the tab.
Hate to do a me too post, but I'm going to anyway. I made a very similar app for a weekend project back in early march of 2009. http://www.fileinaflash.com I used TFTP as the transfer protocol and it's not encrypted like Sendoid, but it works. Ultimately, although it costs next to nothing to run, I couldn't think of a good way to turn it into a business so it's just been sitting there for the past 2 years or so. Sendoid is way faster and prettier than what I made though. Great implementation. Good luck!
Also, we are aware certain rare network configurations break things. Network technology is a finicky beast. In particular, symmetric NAT seems to wreck the setup for the direct connection. Definitely working on solutions for getting around these problems (I've got a couple ideas I'm hoping will work). If anyone hits connection issues I'd love details on your network/OS/browser so I can document things more completely and try to get solutions out there. You can harass us directly at feedback (atsign) sendoid.com.
So many startups/services need a good way to upload large files efficiently. It takes a lot of effort to create an file upload feature that works and provides a good UX across browsers/platforms. We would use it for Mugasha (artists upload large audi files) and would pay for it.
2) When you click "Set a Password" it should set focus to the input. I couldn't even tell it was an input box, I thought it was just a gray box. Style changes could help too.
Neat technology, but I'm a bit worried about having to leave the browser window open before/during the transfer. I accidentally close tabs all the time, I wouldn't want to do that in the middle of a long transfer.
I'm going to give the service a shot for a few weeks though, maybe that will turn out to be a non-issue in practice.
Thats what the helper app is for! Sits outside the browser and lets you send and receive using the same technology without having to worry about the browser thing. Will do resume and everything. Still just as easy to use too.
From the FAQ: "Files never touch or pass through our servers."
Peer-to-peer transfer has some speed benefits, but completely avoiding a server-based fallback seems more problematic. The sender needs to be online when the recipients are downloading the file. People increasingly use laptops/tablets that spend much of their life sleeping (as opposed to always-on desktops). Am I missing something?
Nope, you're just describing two different use cases (real time transfer vs. delayed transfer). Currently you can use the installable app and files will resume/restart whenever either disconnected machine comes back online to combat the often-sleeping laptops you reference.
The thing about persistence via storage is that now you're talking cloud storage, and that's a pretty overloaded and over-served market with a race to the bottom on price. We're fanatic about speed and privacy so we're p2p only right now and we really love the potential for this tech. Ideally, we'll make the persistence issue irrelevant rather than falling back to what we consider outdated tech...
Can you merge the ideas of sendoid desktop client with a pinch of dropbox, so we can sync folders with other computers, other people's computers (multiple folders, multiple computers) without a central server?
i.e. sendoid, but semipermanent links and folders instead of files.
This is actually an extension to the idea we've considered. We are implementing mesh transferring (similar to bit-torrent) and the idea was to have a server act as a peer in the mesh. We are still trying to decide if its something enough people want.
Assume that I want to send a large file to multiple recipients. Does your P2P technology mean that it works like torrent, each node will contribute some of its bandwidth to uploading or that the file will be sent directly from my computer to each of my recipients ?
Didn't know about BitTorrent DNA. Thanks for the link!
One difference I'd note is that DNA seems much better suited for mass distribution while Sendoid is much better suited for sending individual files (especially if you're on the same network, since you'd need to upload to a server and re-download to get p2p going).
Couple of thoughts; you might want to consider a conditional note somewhere that Flash is required for those without.
Selecting and sending multiple files worked perfectly/instantly on my local network, though I could not select a folder.
I noticed that the list of successfully transferred files on the receiving end is partially hidden/obscured by a fixed height div. Also, files in that list are not autoamtically selected; it seems safe to assume the recipient would want to select and download all (rather than having to manually select or check the box.)
Can you shoot us an email at feedback(at)sendoid.com with some info on your setup? Would love to get some more info from you so we can figure out what the problem might be. Thanks!
I wish it could work for me. I love the idea of sharing directly with PCs in our network. Our setup is that we are travelling with my wife and constantly sharing files , now we use dropbox for that, but that means outside connection that relies on slow wifi. if your tool worked - it would be genius
unfortunately, it doesn't and sharing between Windows 7 chrome browser -> Mac .. just getting Waiting for the peer.
I can't say more specifics about network topology as its a hotel wifi.
What prevents URL wardialing? 5 digits, radix 36 = 60 million URLs (e.g. "hg4ba" ). Do you rate limit? Will you add more digits as you get more active shares?
It is nice that the key is short enough that it's easy to remember and enter manually (esp. for any smartphone apps in the future).
To answer my question: there's an option for setting a password. The UI for that should be improved for sharing multiple files with the same password, but there's no need to prevent URL guessing.
Thanks for mentioning Receivd - we've been in early-access for a month now and are growing pretty quickly. We do support large files, our last test with a 5GB+ dataset went swimmingly, and folks use it to share large photos and videos everyday. You can take a look here at http://receivd.com
If you signup with +hn in your email, we'll make sure you get access right away.
We're still discovering this space, but we've learned that there are a huge number of use-cases in commercial sectors for secured, fast file transfer-- especially out-of-network transfers that don't require the receiver to be part of the sender's existing IT infrastructure. Sendoid's tech is great for this.
Companies are having to pay out the nose for our kind of service right now from enterprise providers. We don't think secured file transfer should be expensive, and Sendoid is the first step to fixing that.
PS: If you have a company that wants to get involved with our beta program, get in touch: corp@sendoid.com
iPad version please! I know there are, um, some certain problems there ... but the need exists, especially with video editing. (I have ~2GB renders needing transfers that Dropbox can't handle.)
With Tonido you can right click any file or folder and it will create an URL for the resource. You can share the URL with anybody for download. There is no limit on file size, no uploading - completely private and secure.
I think his point is that browsing to their website, it's not entirely obvious how to quickly share a file. When you initially go to sendoid.com, their link to share a file is the most prominent element on the page.
Having the native hook into context menus is great in the file system, but if your users can't even install the app, what's the point? Having a dead simple browser experience is easier for users because it's one less step to do what they want to do - share files.
