Is it just me or /copy_ref could be used to make an awesome warez site? I hacked a quick prototype and it seems to work:

- User authenticates with Dropbox on my web app

- User sees his/her files and select the ones he/she wants to share

- Another User searches through the shared files, and by clicking "Download", and using /copy_ref, the file will appear on his/her Dropbox

I'm still undecided if I should use a full Root Dropbox access or just App Folder. The later would give users a more security sense, but would require more effort to share files (move the files to the app directory). What do you think?

It really looks like the functionality that my Dropship hack offered :-)

Except that it's easier to trace, as the person sharing the file has to give explicit permission, instead of just giving some anonymous description of the file. I guess they can use that to punish "wrongdoers".

Thanks Wladimir :) I learned a lot in the process and by reading your source code!

Edit: I now find out that wladimir has had this idea and shipped code on the same idea: https://github.com/driverdan/dropship

I have wondered for a while if it could be done without the API by hooking into whatever checksumming is done before uploading.

For example, if you were to find a popularly pirated file (for example, a widely distributed MKV of an episode of Break Bad) and copy it to your Dropbox, the upload is instant as there is a high probability that someone has already uploaded it.

If you were able to somehow able to hook into Dropbox's checksumming functions it may be possible to report a checksum on a 'fake' non-existent file that is the same as what would be provided by the real copy of the file. The file then appears in Dropbox where you are free to download it at top speed having only known the hash of the file previously.

I wonder have safeguards Dropbox have to prevent this.

Dropship hack was immediately rendered useless by Dropbox by requiring that a random part of the file be uploaded, even if Dropbox already has many copies of the file in their system.

So use the Dropbox as the golden copy/SHA reference, and fetch the file from peers over Bittorrent.

DB is always going to be able to be used like a resilient tracker/datasource, and DB devs can only put so many walls in the way of using it like that before it starts to hinder your "average" user.

Example: Get magnet hash, get data from Bittorrent swarm, and then fetch from both swarm and public copies available via Dropbox. Verify against Dropbox copy if necessary.

Is /copy_ref usable across API keys? Your API keys can easily be revoked, but you could instead just cache copy_ref links, and script the ability for a user to create their own dummy Dropbox app, then start downloading files.

I think that the /copy_ref links are scoped to the API key.

But anyway, why would Dropbox revoked the API? I would be using the official API, the user had to explicitly share the files and I would have no access to the Root directory of the user (assuming I'm using an Application API Key).

I think that's no different that me generating a share URL from any file of my Dropbox account and posting on reddit for everyone to download :) But I'm no TOS expert :P

Now we have /delta to get proper diffs, we only need the Events API to make awesome Dropbox-based apps. Currently there is no way for Dropbox to notify your app on a remote server about updates in a user's Dropbox folder. You have to poll. If you still have votes left, please consider voting for this feature at https://www.dropbox.com/votebox/5972/events-api

Surprised to see it's not idempotent. What if, for whatever reason, the caller fails to receive the response? Some information on changes is then permanently lost.

Would have expected to see something like /delta?since=<timestamp_here> but perhaps that's harder to implement & requires much more data to be logged.

It looks to me like the 'cursor' parameter does that.

Ah yes thanks - should have read more carefully.

Am I the only one that would like to see some kind of locking support in the API? So if you have multiple clients working against the same file it could take out a lock for x minutes and the other client could query to see if a file is locked. Useful for synchronization between clients..

We really need this in the API. We do our own version of this that is hacky and error prone but it's all we have right now. I was a bit amazed initially that this didn't already exist.

/delta is great but I've been holding out for an event/webhook API.

I'm surprised we aren't seeing more web apps using Dropbox as the datastore. Anyone know why?

Lack of a sync API I'm guessing is a big one. There's no way to guarantee a file you place in a Dropbox will be there in the future unless you're notified if it's gone (which you can now do with /delta). Also, storing files isn't that big of a challenge, it's not like Dropbox is equipping you with a new skill. There needs to be a very compelling reason to put someone through an OAuth flow that requires a third-party service subscription for something that can easily be done transparently on the server or using S3 directly.

I personally don't think it's compelling for everyday file storage, like S3 is. However, I think there are a ton of other possibilities that are very compelling: data export, save to Dropbox, collaboration and sharing amongst multiple users, etc.

> There needs to be a very compelling reason

For instance, it would be useful to crop an image with the online Pixlr editor, save it to Dropbox -- and then inside of Wordpress to select the image to be viewable on my blog.

I guess this option would be most useful when using media with multiple services.

I'm a lead on The OpenPhoto Project and it uses Dropbox as an optional datastore. They're not really a CDN though so it's paired with S3 or the local filesystem for CDN purposes. http://theopenphotoproject.org

I have never used the Dropbox API, but I'm surprised that /delta wasn't available before this update. That seems like a great feature.

yeah - it was kind of a pain, because it is such a useful pattern when dealing with dropbox. Super glad this was implemented.