API hashes as a namespacing/identification/discovery mechanism
==============================================================

API hashes for namespacing
--------------------------

API hashes could be used to resolve module name conflicts:

    \depends thing 1.0 291fdf47b953c340a298a48cce3897cd
    \depends thing 1.0 ae1b94223ee90d8270447f2e32d7b83e


API hashes for locating and downloading interfaces
--------------------------------------------------

API hashses could also be used to download interfaces in a safe way.
The API hash would serve as a unique identifier for the interface
(strictly speaking, for specific version of it):

    GET /repo/291fdf47b953c340a298a48cce3897cd/thing.slul HTTP/1.1
    Host: some-slul-repository.example

Since you always want the latest interface version in SLUL (except for
unstable modules/versions), there could be some kind of redirect/referral
mechanism, so old API hashes automatically redirect to the latest version
(which is guaranteed by the API hash to be backwards compatible):

    HTTP/1.1 302 Moved Temporarily
    Location: /repo/9edd3dd8753599e9e67286e74524fe84/thing.slul

Federation/Decentralization
---------------------------

There could be a federated network of repository servers, that could
exchange module interfaces.

In order to prevent malicious actors from filling the system with bogus
updates:

* Servers should use HTTPS + server certificates and poll other servers
  for updated data.
* Interfaces should have a signature from one or more of its authors
  (it would be nice to support M-of-N, or perhaps even multiple
   groups of M-of-N sets which all have to be satisfied).
* It could be required to have additional signatures from non-author-
  controlled systems, e.g.:
    - Some kind of notarizations/transparency/archival system.
    - Some kind of automatic test and/or scanning system.
    - A manual review (like FTP-Masters in Debian).