Design & implement a schema for contacts and identities

• Design a Schema, with relationships between entities
• Have suitable primary keys and storage in database
• Log modifications in a way that allows to revert or replay them
• Add commands to create, edit and delete entities from the CLI

Entities include:

• Secrets, that allow you to generate secret keys, must be stored separately, with extra encryption.
• Private keys, that consist in a "path" from a secret. A same secret can lead to many private keys, by using different cryptographic protocols and/or by using multiple different paths with a "HD wallet" protocol. The path may lead to a reference to a secret held by an outside wallet rather than by Glow (e.g. Ledger or Trezor hardware wallet, a Yubikey, or software wallet such as Metamask). Or it may be a marker indicating that the secret was once known but has been cancelled, expired, etc., or maybe even "is expected to be known in the future".
• Public keys, that are either primary data, or either correspond to a private key, or have a "path" from a suitable primary public key. The public key is "controlled" iff there is a known corresponding private key.
• Protocol addresses, that are either primary data, or correspond to a public key, contract or script, etc. Addresses are tied to a particular protocol, but not necessarily to a specific network using that protocol. The protocol address is "controlled" iff it corresponds to a controlled public key, or otherwise controlled contract or script that allows for control on any network.
• Network addresses, that are the datum of a specific network and an protocol address for the network's protocol. The network address is "controlled" iff it corresponds to a controlled public key, or otherwise controlled contract or script that allows for control on that particular network.
• Contacts/identities corresponds to a human or human role, that has usual contact information, and may be tied to other contacts or identities, i.e. "Fare at home" and "Fare at work" are the same person, and is currently the same person as "CEO of MuKn", though the relationship may become invalid in the future. "Fare at work" may also have sub-identities, corresponding to various activities. There may be heuristics associated to each identity to determine which sub-identity to use, when to generate a new one (e.g. for privacy), etc.
• assets in general
• Fiat currencies in particular
• "proxies" of an asset with a path to that asset
• Fungible tokens in general, singular or multiple native assets of a blockchain in particular, ERC20s
• Non-Fungible Tokens in general, ERC721s, etc.
• Other contracts or scripts, located on a specific network, that may or may not follow an API we recognize.
• blockchain configurations (see the in gerbil-ethereum/ethereum-configuration)

Additional requirements:

• Database changes must be logged. (Replay code can come later.)
• Super-secure storage for secrets. (Eventually use a system service such as gpg-agent or ssh-agent.) Primary database refers to secrets only by hash.
• Look-and-feel should be more like "Google Contacts".
• Import/export rolodex (non-private-key) data.