Reviving Drop Seven and a Half Years Later
Back in December 2014 I spent a lot of time hanging out in IRC. While spending time in various channels, I found myself wanting to share images with other users.
Unlike Discord—which came on the scene the following year—IRC did not have the same support for easily sharing images inline; all images needed to be shared as links to somewhere on the internet.
This posed a problem for any image that wasn't sourced directly from a website, such as screenshots or locally-produced images. These would first need to be uploaded to a service, like Imgur, before they could be linked in an IRC channel.
Being a college student on winter break, my solution to this problem was to write my own image sharing service. What resulted was a program called
drop (stylized as
滴) allows you to upload files—primarily images—and get back shareable links to them.
At the time,
drop took the form of a small Express app. Files would be uploaded to local disk, saved under their MD5 hash with the original file extension, and could then be referred to by URLs that looked like this:
http://, Lets Encrypt was only a month into its public release at this point.
Uploading files was done via a built-in administrative UI protected by a username and password. These credentials were read from the program's configuration as a plaintext username and brypt-hashed password.
There were also some limited analytics built in, with each hit of a file getting recorded in MongoDB.
All of this was deployed to my Linode server with the rest of my projects.
The death of drop
Over time my usage of
drop declined. I was hanging out in Slack and Discord communities instead of IRC, and I also moved away from hosting my own tools.
Unfortunately I don't have a good record of this decline, but the outcome speaks for itself:
drop was dead.
But now, after seven and a half years, I decided to revive this project.
Over the weekend I rebuilt
drop from the ground up, as what I have affectionately (and most originally) named "
This time around I decided to use Rust. Underpinning everything is a Rocket server, powered by Rocket's brand new support for async Rust.
Rather than being stored on local disk, drops are uploaded to an S3 bucket. Each drop is assigned a ULID as its ID. This has some handy benefits, like being able to use the timestamp component to get the time the drop was uploaded.
There's also an administrative SQLite database for managing users and API keys for interacting with the
drop API. Interactions with this database are done through the excellent
sqlxallows you to write queries in raw SQL that are then checked at compile-time for syntactic and semantic correctness against the actual database schema.
The rewrite takes an API-first approach to drop management. For instance we can upload a file like so:
curl -X POST https://drop.maxdeviant.com/drops \ -H "Authorization: Bearer <API_KEY>" \ --data-binary "@some-image.png"
We can also upload plain text as a drop:
echo "A wild drop appeared" | \ curl -X POST https://drop.maxdeviant.com/drops \ -H "Authorization: Bearer <API_KEY>" \ --data-binary @-
Either way, the end result is a URL to a drop:
curl this drop to see what we get back:
λ curl -i https://drop.maxdeviant.com/drops/drop_01g6hevwpk80xyv4e3eqt1dncn HTTP/2 200 content-type: text/plain server: Fly/9ece5bcd (2022-06-21) x-frame-options: SAMEORIGIN x-content-type-options: nosniff permissions-policy: interest-cohort=() content-length: 21 date: Mon, 27 Jun 2022 03:30:17 GMT via: 2 fly.io fly-request-id: 01G6HKBE29WAAPZ71843J47V66-lga A wild drop appeared
drop uses the
magic_tree_mini crate to introspect the drop's binary contents to determine its MIME type. The MIME type is then used to set the
Content-Type header on the response, which is what ultimately allows the browser to correctly display the drop.
This introspection is the same way that the
As you might have noticed from the response headers, all of this is running on Fly.
My goal for this weekend was to have a live version of
drop up and running again, and that's exactly what I did. The code is a bit of mess and I spent far longer debugging
Dockerfiles than I care to admit, but I'm proud to say I shipped the dang thing!
I'm looking forward to start using
drop and improving it as I go.
Some things I'd like to look at in the short term:
- Clean up the code
- Add API key scopes to help limit the impact of an API key leaking
- Either go all-in on server-side SQLite or switch to Postgres
- Figure out where interactions with S3 can be optimized (or even eliminated, through caching)
drop in the open, so have a gander at the repo if you'd like to follow along (again, apologies for the current state of the code).
If you want to check out the original code, see the
v1.0.0 tag on GitHub.