Consider option to have a flat directory structure

[sasbury]

something that makes it easier for other tools to navigate

[danielpacker]

Thanks for adding. If we could have a few options that would be so nice. Flat, organized by object type, sharded.

[aricart]

The initial design for the tool internally managed the config desired, and required an export of the JWTs.

The team decided to change that approach and the configurations would be a hierarchy of JWTs O/A/U, and the paths were expanded to be user-friendly, the tool at that point worked with the CWD.

Later it was changed to have a default environment where the operator/accounts/users were stored elsewhere and until changed that location would be honored. With multiple operators, this also became a problem because individual shells cannot be used to look at two different accounts or accounts under different operators, so the CWD made it back into the tool.

I am very close to thinking that all the configs for an account should be stored flatly in a directory. The file names won't be friendly (they will be based on their public key), but that will also solve a different issue, regarding account/user names currently required to be unique in the account (operators require unique account names, accounts require unique users).

With the advent of JWT Account Servers, and with NSC generating some simple configurations, this seems more and would greatly simplify some of the code. This means that a directory for one or more operators (how they are stored is inconsequential) We can always tell the hierarchy). For project-based configurations, one directory per operator or per account is possible. As long as the operator, desired accounts are in the directory the environment would contain all that is needed. Organization is up to the user.

[aricart]

@JensRantil - this would also solve the scanning issue.