Project Outline

The Project

Now to the juicy part: concrete planning of the software project.

What does the software do?

I play in a band. Right now we're still small and one important step to overcome this situation is to promote the project. Since we do not have any professionally made videos or other promotional material published, we ought to share material that has either not yet been released or is not fit for publication (for whatever reason) with promoters, venue hosts and other interested parties. We do not want to publish any of the material and neither do we want to

  • pay for a (proprietary) service with money,
  • pay for a (proprietary) service with our data or
  • waste more resources (computational, economic, social, etc.) than strictly necessary.

Simply put, we want to:

  • host files for download,
  • register email-addresses for each download and
  • keep simple statistics on the downloads of each file.

Of course, less geeky people would just opt for one of probably many already existing solutions, but creating this documentary blog is a purpose in and of itself.

(Security) Considerations

There are not-so-trivial aspects of this venture that will justify why some parts will not be built as easily as possible: Why not just set up a static web-server, upload the files and email the links?

Unguessable filenames

Since we do not want to publish any of the files provided for download through the application, it is strictly necessary to prevent people from guessing downloads to get access to the files. An obvious way to achieve this could involve some sort of hashes as download codes and URLs, coupled with means to hinder users from brute-forcing random-looking addresses. What certainly won't work is clear-text file-names or URLs that resolve auto-incrementing primary keys.

Ensure Email Validity

Since we ought to keep track on who downloads which file, we want some means to ensure distinguish between users. A simple - but of course, not completely fool-proof - way is to send final download links only through email. This would ensure validity of an email address and allow to implement single-use download addresses.

User Stories

To illustrate further - and more precisely - what the app should be capable of doing, I wrote down some user stories. They are not exhaustive and leave plenty of space for future development.

File Upload
As an administrative user, I want to be able to upload files for sharing, e.g. `music-video.mkv' or `my-band-files.zip'.
Stating Intent
As an administrative user, I want to state one or more intents with each uploaded file, e.g. "summer promotion 2024", "club tour Germany".
Register Email Addresses
As a user receiving a download invitation, I state my email address and receive the download link through email.
File Download
As a user I can download the file that is linked in an email.
Activity Insight
As an administrative user, I want to know who downloads what when.

How to accomplish the project

In computing, there are usually infinite different ways to achieve a goal. Programmers, coders and hackers tend to fall back to their own preferences, be it because they are very fast using their best known tech stack or due to the lack of knowledge of (better fitting) alternatives. Of course, we could hack this project together with a bunch of bash scripts, keeping track of state stored in text-files. Or we could re-invent the wheel by writing the functionality as a module for one of the better known web-servers out there. Or we could opt for the most fancy-looking node module on the market. As mentioned above, early decisions should be considered wisely. So, for this project at least, I will opt to well established free software with a trustworthy history and a community that makes reasonable approaches for mitigating security incidents for both quality and longevity.

The Components

Boiling the whole idea down to its core we need a few components for project deployment (without re-inventing any wheels):

  1. a host of sorts
  2. which runs a web server,
  3. means to send email and - of course -
  4. the web-application itself.

For development and documentation (e.g. the blog you are reading right now) we need:

  1. an online git repository,
  2. a (reproducible?) development environment and
  3. some means to publish static HTML.
Last modified: 2025-04-09 Wed 19:07