`safe` modular architecture

The core safe command should be as small as possible, affording easier auditing among other benefits. It should also support a modular architecture enabling subcommand plugins. Rust’s own cargo is a good representation of the general idea.

With that, a core subcommand installation subcommand could source subcommands from any traditional source (local FS, network) and more importantly from Safe itself.

safe install safe://safesubcommands/files => safe files for example.

Having the ability to install safe subcommands from private or public Safe addresses would also begin building out Safe-based software distribution.

2 Likes

Neat idea. Also Ok if the plugins are network signed and confirmable (which we can do).

1 Like

@dirvine,

Does the following adequately categorize the essential core functionality for safe?

  • Node management for Safe connectivity. (installing from public addresses)
  • Auth management for user authentication. (installing from private addresses) (not strictly necessary)
  • Subcommand management for extending functionality.

I am not sure I follow this totally @anon78698497 can you perhaps say it differently?

In terms of modules we have

  • Nodes -> can be localhost/Lan or public, where public addresses means a new safe network available to everyone.

  • Keys, these are the users public key, may be a section pub key as well (BLS). They are data items, but also provide the Auth indicator for data items/wallets etc. where the sig is checked against these keys.

  • SectionChain -> This is the chain of section keys (each key signed by previous one) that gives the network sections their Authority and proves the network from genesis.

I hope this helps a bit.

1 Like

@dirvine

I was attempting to identify the absolute minimal core functionality of the safe CLI, a task necessary for rearchitecting it more modularly.

Is it correct that your list more generally refers to the modules of the Safe network proper?

1 Like

After spending some time thinking about the list, “Auth management for user authentication. (installing from private addresses)” is not strictly necessary, as with node and subcommand management, auth management could be installed using a read-only Safe connection.

Ah for CLI @bochaco is our man there. Slack is down right now but he might see this.

1 Like

@dirvine

Thanks.

Is it correct that your list more generally refers to the modules of the Safe network proper?

Ah yes, sry I should have been clear, but yes my list is for the whole network and not CLI.

1 Like

@dirvine

Thanks. It’s pleasantly minimal.

1 Like

I guess we could consider this moving forward, not sure what options are out there as I’ve never explored such a thing. The key thing though is that originally CLI was thought to be like a swiss army knife for Safe, giving users all that’s needed to manage their data and type of transactions that could be made on the Safe, as well as possibly other aspects, like what we have now with launching the nodes and authd. The main goal is to be able to answer the question from any newbie: “What do I need to use Safe?” with an answer like “Just downlaod Safe CLI and follow the User Guide, for whatever you are aiming at doing with Safe!”

3 Likes