Setting Root Agent

[joepio]

Any change to data needs to be signed by some Agent. As Agents themselves are just resources, they need to be created by some other Agent. I'll call the very first Agent the Root Agent. The Root Agent is a user that has the highest of rights - e.g. create admins, destroy everything. So how should a Root Agent be created? Some options:

1. Create a root agent when instantiating a new server with a new database. Pass the private key and the URL to STDOUT, and let the user copy it somewhere safe. Seems a bit ugly (unclear, unsafe), but simple to implement.
2. Provide a CLI command in atomic-server for creating Agents, e.g. atomic-server agent new. A bit more of a hassle, but I'm very likely to need more CLI tooling in server at some point anyhow.
3. Read a secret seed from .env which generates the root Agent.
4. Have some setup endpoint used for generating the first Agent. Seems user friendly for most, but hard to control by machine.
5. Check the default config folder ~/.config/atomic, and check for a config file. If it does not exist, create one with some defaults and a newly created author.

I think multiple of these should be possible.

Relates to client server interaction #6 and authentication #13. Also to atomic-data authorization.

[joepio]

I think I'll add some logic to atomic-lib for reading and writing configuration, which will be used both in atomic-cli and atomic-server.

Some of the configuration (at the very least the private key for the agent, and its URL) should be accessible for the CLI.

[joepio]

Some design considerations.

1. Is there only a single Root Agent, or can there be multiple?
2. What is more important, ease of use during setup (creating a root user if none exists) or having a really explicit step?

[joepio]

Upon initialization, the server checks the default config file location. If there is a file there, it reads it and checks if the agent exists. The server panics when the agent is not available. If there is no config file, a new agent is created and the config file is saved. The CLI checks that same config file if the user wants to write data (e.g. set or remove commands). Only agents have write access.

This mostly works, but it's far from ideal.

• The server does not check if the agent has the correct rights - all valid agents are able to write to any store.
• If the user wants some other location for an agent on his disk - bad luck
• The server can't be read-only, an agent with write access is always created.
• The agent creation process is kind of non-obvious, as it automatically happens during boot.

So where do we go from here? Let's explore some more considerations:

• We'll need an authorization mechanism, probably with some sort of hierarchy.
• Having a root-level user on initialization is logical and probably necessary.
• We need a mechanism to remove rights. If a private key has been exposed, the Agent's rights should be taken away.