Added roadmap

README.md

@@ -1,3 +1,11 @@
 # hilde
 
-A server implementation of a Debian repository.
+## What?
+
+A server implementation of a Debian repository, written in Rust.
+
+## Why?
+
+The original reason was that I wanted to create my own "AUR" for Debian,
+populating it using my CI pipeline. And of course, the only true valid reason,
+it sounded fun :)

ROADMAP.md

@@ -0,0 +1,82 @@
+# Roadmap
+
+This file describes a broad roadmap of what's currently planned with the
+project.
+
+## Readable repository
+
+The first goal is to make the server a fully functional Debian package
+repository. This includes:
+
+### Setting up a database
+
+Hilde stores an index of the stored deb files in a PostgreSQL database. Any
+data that can be calculated beforehand and/or stored efficiently inside a
+database (e.g. hashes, package names & versions, descriptions etc.) will be
+stored there. Any request that isn't a deb file will be queried and/or
+generated from this database. For example, the `Packages` file can be
+generated on the fly instead of storing it on disk. The goal is for the data
+storage to only include deb files.
+
+### Indexing the directory on startup
+
+On startup, Hilde will scan the packages directory for deb files. These will
+then all be parsed, and synced with the database.
+
+### Functioning as a repository
+
+Using this database backend, the server should fully mimic a Debian repository
+server ([an example](http://ftp.debian.org/debian/)). As there's no real reason
+not to, we should implement the
+[repository spec](https://wiki.debian.org/DebianRepository) as complete as
+possible.
+
+## The ideas
+
+Now that we have a repository that we can use, it's time to add some extra
+functionality.
+
+### Uploading versions
+
+This is the initial reason I wanted to start this project. My goal is to add a
+way to send POST requests to the server containing new versions of a new or
+existing package. These packages can be from any distribution, architecture, or
+name, and the server will just dynamically create the directories n stuff when
+needed. This feature can then be used in CI pipelines to simplify uploading
+versions to a repository.
+
+### User management & JWT tokens
+
+Considering we can't just make an upload endpoint publicly available, we'll
+need a system to log in. There will be an admin user that can do everything,
+but I want to add a detailed user management system. This system will have
+fine-grained controls over what user can do what, and each user is able to
+create JWT tokens that further narrows down the functionality. For example, a
+user could have read & write access to the stable distribution's updates
+section. Then they can create a token that only allows to write a certain
+package, and use it in their CI pipeline for that particular package.
+
+### Federation
+
+I think the idea of being able to spread a service across multiple hosts is
+really cool, so I've thought about adding this to Hilde as well. I have never
+created anything like this before, but I think the idea is really cool. My
+current approach would be as follows:
+
+The nodes communicate using a common secret key. Each node only requires the
+location of a single other node. When a new node connects to the network, it
+asks the node it's been given about which nodes it knows. These nodes are then
+added to the node's list of known nodes. These new nodes are then also
+notified, and this process is repeated until all nodes are discovered. Each
+node also keeps an index of which packages can be found on which node. This
+makes it so that every node can be used as an entrypoint to the network, making
+it easy to load balance.
+
+Each node could maybe send a notification to all the other nodes when it
+discovers/loses a node, or receives a new package.
+
+### Mirroring repositories
+
+It might be useful to add functionality to mirror an existing repo. This could
+for example make a home setup fully self-sufficient, by mirroring the official
+Debian repositories.