We're happy to announce that it is now possible to upload and attach files directly to posts and thus host them via Folleon. To do so, drag and drop over the editor area or choose "Attach files" below the box.

Behind the scenes

This feature was an opportunity to do some nice engineering. We store the files with a unique id, the original file name, and an association to the user who uploaded the file. At the moment, only images are allowed.

To avoid duplication, we check the SHA-256 sum before storing the files. If a file was already uploaded, the second copy is removed and we reference the already existing file. This behavior is transparent to the users as every file still keeps the unique properties (file name, upload date, uploading user, etc.) and gets a unique id.

The API to access the files looks for example like this:


123 is the unique file id, and at the end the file name.

This leads to a few nice properties:

  • Short but still SEO-friendly image URLs. After all, Google sees who hosts images and rewards the according sites. To make images findable, the original file name should be in the URL.
  • Unique links for each resource, even if the same file is uploaded twice.
  • Every upload can have a custom file name that is shown directly in the URL. As stated above, this helps with SEO but also makes guessing the images very hard. If only the file id was required to access a file, it would be trivial to download all hosted files.
  • The Content Security Policy (CSP, https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) can be changed to only allow images from https://folleon.com and https://api.folleon.com, thus controlling what is shown on the site. Since https://api.folleon.com is not allowed to execute JavaScript, malicious files should not be a direct threat.

It was decided against using the SHA-256 sum in the URL to avoid poor search engine ranking. A Hex-encoded SHA-256 sum consists of 64 characters that do not improve SEO and thus are wasted space. Also, you never know when a stored file needs to be touched, e.g. for normalizing or removing meta data. In such a case it would be necessary to change resp. redirect the URL as the hash changed. Or the URL would remain unchanged—and showed wrong information as the hash was no longer correct. With a unique id, these problems don't exist.

Coming soon

In the future we'll also add support for user photos for a more personal touch. With the basics already done, this should not take long.

As always with new features, make sure to clear the browser cache and reload the page.