Improve agent management and switching

I currently use atomic-cli on various machines, and I manipulate multiple atomic-servers using multiple Agents. Managing Agents is kind of a hassle, so this issue is for identifying hurdles and coming up with solutions to make it easier.

Creating Agents

On server database initialization , the default config file path is read. If an Agent exists there, it will be recreated in the store, and it will get rights to manipulate the data in the server. If there is none, a new Agent will be created using a random private key, which will be added to the config.

The only other way to create an agent, currently, is by using atomic-lib. Theoretically you could create a new agent manually, using commits, but this would also mean you'd have to manually generate a keypair. Not great.

One solution is to add a custom cli command, but that would not be re-usable in another context (e.g. web app).

Let's consider some real world use cases:

• Add an agent for some external sensor. Say I have a CO2 sensor or something, which could post a bunch of Commits to my Server. This sensor needs to be able to sign commits and a place to put them.
• I want to invite my friend to make changes to some resource or some folder. This involves some authorization and nesting, and also creating an agent. However, when I invite someone, I don't want to create the agent (and have access to the private key) myself. I'd rather create some token, which can be used one time, which is linked to some grants. Ideally, this invite functions as a single URL that does all the magic. Open the invite URL, create a new Agent (client side, in the browser probably) or use an existing one, post something to the server to create the grants.

Managing Agents

The first challenge is managing my own secret private keys. I have to keep both the private key, as well as the agent URL - two pieces of information that have to be copied and pasted. Technically, the private key should be sufficient, especially if we'd use something like a did address.

Storing private keys will probably be a hassle for most users. I think the multi device / store locally / QR code approach works well for this. When we have native desktop clients (like atomic-cli) and a mobile client (atomic-flutter? who knows), we can use these to store keys locally, and share them using QR cores (to devices with cameras) or regular strings (for computers, where copy pasting works fine).

Switchting Agents

Having multiple agents on one machine means that I should be able to switch. Currently, the agent is read from a standardized path, and switching practically means manually renaming the config file at that standard path and using a different one. It's too nerdy, it's error prone and it takes too much time.

Start by mapping the server database initialization and default config path described here, then inspect the atomic-cli and atomic-lib entry points for current agent creation and switching. Done requires an agreed, reusable workflow for creating, storing, inviting, and switching agents across the described clients and servers.