Distributed hosting

[gdude2002]

A big problem we're going to have to face here is that we don't know how popular this package system is going to be. To deal with storage, networking and processing constraints, we're going to have to do some distribution and scaling. Here's my ideas on that.

• Firstly, we need some way to co-ordinate managers. Not only does the main site have to be able to direct people to the right manager, it also has to aggregate information on all the packages somehow.
  • Of course, keeping the managers alive and ticking should not require the main site - not least, because it could be taken down by an attack. Therefore, we should have a hidden node for co-ordinating managers that the main site can contact.
    • This would also help keep the site small, so it could run on a VPS.
• Secondly, we need a way of authenticating managers securely, in a way that prevents random people from adding managers without consent or doing other malicious things.
  • Security will be a big part of this. Not only do we have to keep things functioning, but we also need to serve code that hasn't been tampered with.
    • Depending on the route we take with public/private/organisation repositories, we may need to exchange GitHub access tokens as well.
  • Authentication can probably be done using a fairly simple API-key-based mechanism, but I feel that most internal/system traffic should at least be encrypted with RSA keypairs.
    • People will be trusting that our packages are safe from your average skids. We need to prove that we're capable of that.
• Thirdly, we need to provide a package and configuration system that won't be overly difficult to set up.
• Finally, we need to work on a control mechanism that lets us manage the nodes from a central point (or, alternatively, using desktop apps or an Ultros instance).

[gdude2002]

I decided at some point that we're going to use SSL sockets, which is fine for this purpose.

[gdude2002]

Blocked by #4