Show HN: SendRail - Easy P2P File Transfer From The Desktop(sendrail.com)
sendrail.com
Show HN: SendRail - Easy P2P File Transfer From The Desktop
http://www.sendrail.com/
23 comments
I'd agree that generally it's not the best idea to limit a service to just FB users (unless it is fundamentally tied to FB). That said, it's not horrible to start with FB and iterate outward... As long as that iteration happens in the near future.
We use Facebook to validate your identity and send the download link directly to the recipient's Facebook message inbox.
Technical question: how are they able to do this? I needed to programmatically send Facebook PMs a while back, and from what I could tell it was not possible. What gives?
Technical question: how are they able to do this? I needed to programmatically send Facebook PMs a while back, and from what I could tell it was not possible. What gives?
It would certainly differentiate your service, but might also limit your user base unnecessarily
Limiting user base? I don't think it would hurt much. Half of internet users use Facebook. I think they have a good chance at giving better user experience by tying with Facebook.
Limiting user base? I don't think it would hurt much. Half of internet users use Facebook. I think they have a good chance at giving better user experience by tying with Facebook.
Limiting user base? I don't think it would hurt much. Half of internet users use Facebook.
Even assuming that figure is true, why cut your potential user base in half right off the bat? And for those who are FB users, what do they do when they want to exchange files with non-FB users? The service will be unusable in such cases even for FB users, and sendrail ends up losing more transactions.
Even assuming that figure is true, why cut your potential user base in half right off the bat? And for those who are FB users, what do they do when they want to exchange files with non-FB users? The service will be unusable in such cases even for FB users, and sendrail ends up losing more transactions.
We also support hooking into your address book on your Mac, and are working on integrating your online email address book and ActiveDirectory into it. We're trying to cover every single contact mechanism out there so you don't have to worry about "finding the right tool" to send a file to someone -- we hope to make SendRail work for every single use case you encounter.
So how do you plan to make money? I can't see any pricing information, so I guess this is yet another case of users being the product.
Even if they have cut their initial user base in half, it doesn't mean they will not add alternatives in the future. FB integration solves a whole lot of issues around auth and sign up and generally makes your life easier when prototyping things imho.
Half the internet may use Facebook, but how many people, in the target audience for this service, prefer to tie as little as possible to their Facebook account?
I know that if a third party service wants to tie to Facebook, I immediately say "No thanks".
I know that if a third party service wants to tie to Facebook, I immediately say "No thanks".
I know that if a third party service wants to tie to Facebook, I immediately say "No thanks".
Same here. I tend to assume that any company so coupled to Facebook probably has the same concern about user privacy as Facebook, i.e. none.
Same here. I tend to assume that any company so coupled to Facebook probably has the same concern about user privacy as Facebook, i.e. none.
Half of internet users use Facebook.
If half of those internet users friends use facebook, this limits Sendrail to 1/4 of potential matches.
If half of those internet users' potential recipients of files are friends (colleagues, acquaintances, chat room contacts, etc may not be fb friends) that gets us to 1/8 of use cases as potentially solved with Sendrail, and Sendrail is only useful to Fb users 1/4 of the time.
Most people won't want to use a service that's useful only 1/4 of the time for a particular task, so this is far worse than a 50% reduction in potential users. This is how you get no users.
If half of those internet users friends use facebook, this limits Sendrail to 1/4 of potential matches.
If half of those internet users' potential recipients of files are friends (colleagues, acquaintances, chat room contacts, etc may not be fb friends) that gets us to 1/8 of use cases as potentially solved with Sendrail, and Sendrail is only useful to Fb users 1/4 of the time.
Most people won't want to use a service that's useful only 1/4 of the time for a particular task, so this is far worse than a 50% reduction in potential users. This is how you get no users.
Agreed: Many groups block FB; if you want any corporate or business use, you probably don't want to require FB logins.
Peer to peer? I guess I am getting old. I can remember when peer to peer meant that one host would communicate directly to the other host and not store the file transfer on a centralized system. Or that an application would not use a centraliozed third party for authentication.
Amen, brother! These were my assumptions as well when clicking the link. It would be more accurate to call this service peer-to-server-to-another-server-to-peer.
We only store the file on our central server if the receiving end doesn't have our app. If they have the app, we create a direct connection between both parties and transfer the file(s) directly without them ever hitting our servers.
That's a little disappointing, because it means your claim to have no file size limits can't really be true. What is the real limit for sending a file to someone who doesn't have the app installed? Would a 100TB transfer really work?
I don't mean to be snide; I honestly hoped what was going on was that your server was only brokering the transfer, not taking a full upload. In other words, only when the recipient began the file download would sendrail begin uploading the file from my computer. In this scenario, sendrail would merely be reflecting a stream, not storing anything.
So tell me if I understand correctly: If I share a document with someone who DOESN'T have sendrail, they will get the version of the file at the moment I send it. But if I share a document with someone who DOES have sendrail, they will get the version of the file at the moment they download it? In other words - peer to peer downloads get any file changes since the file was sent, but non peer to peer do not?
I don't mean to be snide; I honestly hoped what was going on was that your server was only brokering the transfer, not taking a full upload. In other words, only when the recipient began the file download would sendrail begin uploading the file from my computer. In this scenario, sendrail would merely be reflecting a stream, not storing anything.
So tell me if I understand correctly: If I share a document with someone who DOESN'T have sendrail, they will get the version of the file at the moment I send it. But if I share a document with someone who DOES have sendrail, they will get the version of the file at the moment they download it? In other words - peer to peer downloads get any file changes since the file was sent, but non peer to peer do not?
Curiosity question: what happens if I disconnect my machine halfway through a direct transfer? Do you support continued download/upload (or multipart)?
I guess in the case of a connection to your server, presumably the receiving party would never know that you sent them something (until a retry upload happened).
It's just that in the case of a direct p2p transaction, it's quite likely that the downloading user's downstream bandwidth is low, such that the chance of a failure happening over the entire course of the longer transfer is higher.
I guess in the case of a connection to your server, presumably the receiving party would never know that you sent them something (until a retry upload happened).
It's just that in the case of a direct p2p transaction, it's quite likely that the downloading user's downstream bandwidth is low, such that the chance of a failure happening over the entire course of the longer transfer is higher.
So you actually think this is a P2P architecture?
On a related note how do you handle firewall piercing?
On a related note how do you handle firewall piercing?
probably with port knocking? pretty standard I would think.
Port knocking makes no sense in this situation. I think it's something more like STUN (RFC3489).
http://www.ietf.org/rfc/rfc3489.txt
http://www.ietf.org/rfc/rfc3489.txt
[deleted]
"All our files are encrypted with top of the line 256-bit AES encryption. We use Facebook to validate your identity and send the download link directly to the recipient's Facebook message inbox. No one but the recipient will ever be able to access the file."
No, thank you. Above is a turn off. First of all, the files can't be yours and you can't make people use Facebook to use your service.
No, thank you. Above is a turn off. First of all, the files can't be yours and you can't make people use Facebook to use your service.
I love seeing apps that replace what we misuse email for -- e.g. sending files to a friend -- and looks like you guys have that spot on.
The biggest issue with other solutions is that they grow to a point where it's no longer easier than just emailing the file. Hopefully you guys don't outgrow the ease of use!
I'll never use a service that requires a FB login exclusively.
We also support hooking into your address book on your Mac, and are working on integrating your online email address book and ActiveDirectory into it. We're trying to cover every single contact mechanism out there so you don't have to worry about "finding the right tool" to send a file to someone -- we hope to make SendRail work for every single use case you encounter.
This is the first iteration, you may use it yet.
Cool product and integration with OS X. Your video needs a lot of work - you're talking way too much about technical things like 'threads' 'asynchronous' and 'in the background' - no normal user cares about these things. Show me how I can click a file, press a shortcut, and have it show up on my friends computer. This is a killer feature and you need to HAMMER it.
Every time people think about a solution about this (to my mind) huge e-mail issue I'm really happy to be not the only one who is sick of the existing solutions out there.
I used to use things like Dropbox or other syncing services and then share the link of a file, which is for me an okay solution. But not what makes me really happy.
Your idea looks also interesting, but how do you want to manage things like the file storage time? Do you want to store them permanent? What will become also some interesting challenge is to make the "send file functionality" everywhere in the world fast, regarding up- and downstream.
Really looking forward if other people will find an idea soon. I've been thinking for a while now about it and still never found the kick-ass idea.
I wish you all the best for your product.
Ps: on the bottom of your website is a "-->".
Best, Felix
I used to use things like Dropbox or other syncing services and then share the link of a file, which is for me an okay solution. But not what makes me really happy.
Your idea looks also interesting, but how do you want to manage things like the file storage time? Do you want to store them permanent? What will become also some interesting challenge is to make the "send file functionality" everywhere in the world fast, regarding up- and downstream.
Really looking forward if other people will find an idea soon. I've been thinking for a while now about it and still never found the kick-ass idea.
I wish you all the best for your product.
Ps: on the bottom of your website is a "-->".
Best, Felix
Great that other smart people are trying to make sending files easier!
We at Dropdock ( http:/getdropdock.com/getstarted , check at the end for invite code ) are also working on this problem. We have developed a Cross platform application that send files to anyone, wether they are a dropdock user or online.
Dropdock also work flawlessly over LAN. Our client auto detect other dropdock users on the LAN so you can send them larges files with ease.
We have working on an Android & iOS app too so you can send all those photos and HD video to anyone in one big batch instead of uploading them to different services or sending multiples emails.
We don't want to replace file attachement. If you want to send a simple spreadsheet to someone, you should sent it through email with explanation and not upload it somewhere and C/C the links.
Finally, we though going the facebook route too, but it wasn't too user friendly since you can't auto detect other users base on their facebook account and it just didn't make sens for us to use Facebook messages for notifications.
We are currently in private Beta ( Alpha-ish ) but are about to release a big update with a lot of fixes and new features. If you want to try it out, signup at http://getdropdock.com/signup with the invite code DROPDOCKBETAP1.
We at Dropdock ( http:/getdropdock.com/getstarted , check at the end for invite code ) are also working on this problem. We have developed a Cross platform application that send files to anyone, wether they are a dropdock user or online.
Dropdock also work flawlessly over LAN. Our client auto detect other dropdock users on the LAN so you can send them larges files with ease.
We have working on an Android & iOS app too so you can send all those photos and HD video to anyone in one big batch instead of uploading them to different services or sending multiples emails.
We don't want to replace file attachement. If you want to send a simple spreadsheet to someone, you should sent it through email with explanation and not upload it somewhere and C/C the links.
Finally, we though going the facebook route too, but it wasn't too user friendly since you can't auto detect other users base on their facebook account and it just didn't make sens for us to use Facebook messages for notifications.
We are currently in private Beta ( Alpha-ish ) but are about to release a big update with a lot of fixes and new features. If you want to try it out, signup at http://getdropdock.com/signup with the invite code DROPDOCKBETAP1.
It may well be a great product, but sadly as soon as I see the word "facebook", my gut reaction is good bye privacy, there for Im automatically excluded. Shame.
I literally just finished something today that attempts to solve a similar problem: http://copyfile.net/
Cool concept. Is there not a way to streamline the process even more? Is it possible to generate a magnetized link that sets the file location for you?
Unfortunately, for security reasons, browsers only give you the base of the filepath, so all you can pick up is the filename. Even if you had the full filepath, though, I don't think the format of a torrent file lets you specify the file location.
Looks so simple, it's hard to believe it's really true. Good job! Can't wait to get my invite.
Secure via HTTP? I think your URL is missing an 's'.
We host our files on a completely different server which is completely secure. Sorry for the confusion there and thanks for raising this point -- we'll add SSL to our main website too.
This seems almost identical to Sendoid which appears to have died completely. For asynch file sharing, we can use Dropbox, for synchronous file sharing, Skype. Is there a file size limit on Skype?
I must say that when I've seen a very very similar product completely die as recently as Sendoid did, I get pretty sceptical about the viability of the idea.
I must say that when I've seen a very very similar product completely die as recently as Sendoid did, I get pretty sceptical about the viability of the idea.
Side note, but I'm curious: what do you use to send messages directly to the Facebook messages inbox? The standard FB dialog or is there some Graph API endpoint that will let you do that? My memory of the FB API is hazy, but a quick scan seems to indicate that you still can't post messages to the inbox without popping up the UI.
Great question - we're using the xmpp_login permission that Facebook Auth provides to get messaging permission from the user and we have an XMPP server running on Node.js that handles all the messaging.
I use a flash based p2p file transfer service for this now:
http://www.filesovermiles.com/
Can't really see how this could be more convenient to me.
http://www.filesovermiles.com/
Can't really see how this could be more convenient to me.
I am surprised that nobody mentioned Nitroshare, which is great for a number of use cases, and completely free
How are you different from SoShare[1]?
[1]: http://www.getshareapp.com/
[1]: http://www.getshareapp.com/
It's not an attempted Facebook clone used for uploading files?
It has a desktop client? (Which is the whole point.)
It has a desktop client? (Which is the whole point.)
You may be confused at what Share is; it's a desktop application that uses the bittorrent protocol[1] to do P2P transfers between users. It integrates with Facebook for very much the same reasons as SendRail does.
See https://torrentfreak.com/bittorrent-releases-new-share-appli...
[1] It's actually developed by BitTorrent Inc, the same guys who write µTorrent.
See https://torrentfreak.com/bittorrent-releases-new-share-appli...
[1] It's actually developed by BitTorrent Inc, the same guys who write µTorrent.
Seriously, how are they going to make money in the future? Is it just free in the alpha?
you lost me at 'we use FB to validate your identity'
What if I have two friends with the same name?
Epic Ketchup Prank.mkv :D
how will you generate revenue?
You might want to consider offering a couple of different options; none of these file transfer services have a FB requirement:
http://wetransfer.com http://yousendit.com http://letscrate.com http://ge.tt
Or perhaps you want to position this as a FB-only service? It would certainly differentiate your service, but might also limit your user base unnecessarily.