What to use as package identifiers?
===================================

* Arbitrary names?
* Domains?
* Plain hashes?
    - These make it possible to connect a key pair to the hash.
* Hashes with non-controllable pre-image?
* Registry-assigned random?
* Numeric OIDs?
* Registry-assigned but "user-owned" names
    - I.e. manual approval process,
    - Risky names can be avoiding
    - But trademark issues etc. can still happen.
* Registry-owned names
    - Registry can and is expected to transfer package ownership
      in case of abandoned packages or any other problems.
* Registry as a downstream:
    - The registry decides on the names. Naming is a non-issue.
    - The registry develops the APIs and pulls in code from other locations.
    - I.e. the registry is a downstream of other projects.


Hybrid approach:
* Have pubkey/pubkey-set/UUID based "registry root"
* Have this root as a namespace for package names (and/or class names?)
* Could lead to merge conflicts if packages are developed in separate
  registries.
* With this approach, it has to be possible to depend on packages in
  different registries (since some packages might only be available
  in some specific registries).


Related:
* Should class names also be IDs?
* Function names.


Arbitrary Names
---------------

* Good names might be squatted early on.
* Good names might be abandoned.
* Good names might be used by packages that shouldn't be the "go-to" package.
* Someone could register `pkg2` (or 3, 4, ...) when `pkg` already exists.
* Or someone could register `pkg` when only `pkg2` exists.
* Risk of trademark or other legal issues.
* Risk of unsuitable names.
* Words can change meaning over time.
* Words can become problematic over time. E.g. "blacklist" vs "blocklist".


Domains
-------

Strictly speaking, domains have all the problems as arbitrary names
(since domains are themselves arbitrarily chosen).

In addition, what should be done when a domain is forcibly transfered
or expired? It is probably undesirable to transfer the package ownership.


Hashes
------

Hashes can be abused by putting something bad in the pre-image,
which will then be impossible to get rid of until everything that
depends on the hash is updated (if this is even possible).


Registry-assigned random
------------------------

* Impossible to start working on packages offline?
    - Depends on how the toolchain works.
* Merging registries can lead to ID conflicts.
* Problems with multiple active concurrent registries:
    - Possibility of ID conflicts
    - Possibility of different IDs for the same package.
* Possibility of split-brain if registry is decentralized.