My sister (Eva) needed to use Hellofax a few days ago after I asked her to sign something digitally. She didn't know how, but when she got your automated "Let me know if you need any help" email, she wrote back with some questions. You (assuming you're Joseph) helped her figure out how to use it, and then she called me and was absolutely GLOWING about how cool it was to email back and forth with you, get help, and have a fun conversation. She also loved the "Stay Faxy" line you used somewhere.
Just wanted to say thanks, awesome job, and I think you converted her into a Hellofax customer for life.
I've been working with the Dropbox API (among MANY others...) for my early stage startup Snapier (http://snapier.com/), and I must say it is a pleasure to work with. Very sensible and logical. I can't say that about all API's...
Another example of how Dropbox is gonna keep its momentum. With it, it should be rather straightforward to bake in some cool iCloud type of preview/revision stuff into native apps.
In Snapier, it will be better if you have a message why you are asking for emails. More importantly, provide a message which is a little more than "Thank you very much" when I enter my email. Though I got an email within a second, it will be more user friendly to give a "We'll connect back soon" in the site itself.
Also, in the email you mention 'check us out on Twitter' but fail to provide the twitter id.
Just my two cents. If any of that sounds badly phrased, I blame the clock for showing 3 AM. Cheers :)
Also, it would be nice to have a better description of what Snapier does exactly. 'A simple way to automatically sync data between Skype and Facebook'? What kind of data would I want to sync between those two services? I read your blog and if I understand correctly, Snapier would be something that get's my credentials for a bunch of API's and then interconnects them, so that I don't have to roll out a script to do it. If my understanding is correct, then this is not very well reflected in your landing page.
You do understand correctly, and we think this is a big challenge for us. We are trying to stay away from "technical" terms (save for the API nod in the name) but stay light on the marketing speak. I could go on and on about our plans here... but, to cut it short, you are absolutely right, it isn't reflected correctly on the landing page.
This is excellent: I especially like revision control and "undelete" (still not as powerful as Google Docs but enough for majority of apps).
Allowing access to only a single folder is an excellent feature (Google Docs does not have that): basically you can make Dropbox as a dropbox or sendbox.
And shameless plug: if you need to real-time replication of multiple Basecamp/Google Doc accounts with Dropbox try this: https://cloudHQ.net/ (and you probably understand why we are excited to finally get "single folder access feature").
Finally, Dropbox lets apps request access to only a single folder. Now you can try out an app without worrying that you're giving access to your private data.
Before the redesign they had a page that explained the API is not for desktop client use, only mobile and web apps. I can't find the new equivalent, but maybe I'm missing something.
I understand that, but what keeps someone from pulling your key and secret out of your app and creating a trojan app? For example the app could look like your app, use the same key and secret, still authenticate as the user, but then steal their data and upload it to a third party server.
That may not be easily doable with iOS since Apple does a good job of curating their market, but I can imagine someone making a fake app like this that runs on Android and getting in to the Android market.
That is a risk, Twitter has the same risk, and when they switched over to OAuth-only there was a debate about this. Twitter's stance was that it's the developer's responsibility to obfuscate your app secret. People promptly pulled apart the official twitter iPad app and found they had done a terrible job of obfuscating it themselves...
In my opinion the big difference here is that a compromised Dropbox key would give the malicious app access to data it wouldn't normally be able to access. A stolen Twitter API key just lets the app act as any other Twitter app does, there's not really any additional data it would be privy to.
I haven't had a chance to look into exactly how authentication works, but if going to the page would require that the user regrant access each time (and if the page would indicate the app name as well), this difference could be nullified.
That's a weird reasoning of them. If the app-secret is ever sent over the network directly (either HTTP or HTTPS) there are plenty of ways to intercept it without having to dig into executables. I quickly skimmed over the OAuth code and that seems to be the case. But maybe they support digest-based authentication as well.
Kudos to the Dropbox team for developing their product into a platform. Giving developers an opportunity to develop things on top of their product keeps not only the community excited about things to do with Dropbox, it also gives them fresh ideas from how people consider to use it.
This is interesting although I really really wished they had used oauth v2 since it is so much better and is designed to give a first class experience on mobile devices.
In fact I can't think of any good reason to use the older version but I would like to hear if there are anybody who has different experiences since I haven't worked much with it.
Everything has overhead at scale. I think the 'HTTPS is hard on computers' stage has passed by though...its just not that computationally intensive on modern hardware.
You can do cross-domain POSTs. You just cannot get a response from the server. Often times though you can get the length of the response. This can be used to do a POST to change settings on an unsecured Wi-Fi routers, for example and checking whether the call succeeded or not by the length of the response.
I'm hoping someone will tell me why it's a security problem, but yeah, for a whole slew of apps, I'd like eliminate server logic or at least make it simple to swap out backends.
It is much cheaper to scale an application putting data onto peoples' Dropbox folders instead of S3. For S3, you would have to pay for the total amount of storage used by your customers; with Dropbox you wouldn't have to pay anything for storage, and for the most part your users wouldn't have to either since each gets a certain amount for free.
Exactly. With Dropbox, you're making storage the customer's problem and not yours. You could argue this is bad for the customer, but you end up with a web app with next-to-no server overhead: just serve your static files and everything else is taken care of. No different than the many mobile apps that sync to iCloud/Dropbox already.
plaintext: http://itunes.apple.com/us/app/plaintext-dropbox-text-editin...
http://ifttt.com
https://www.hellofax.com
http://greplin.com