What do you want from a SAFE CLI?

Here’s my initial implementation of a SAFE CLI program.

I’m working on this to get myself more familiar with our safe_client_libs and to get more hours experience with Rust.

I would have liked to use termion, however, it’s not yet supported on Windows.

It currently has 6 commands that are fully functional in mock-routing:

  • create_acc
  • login
  • initialise
  • authorise
  • registered
  • sha3_hash

Those commands may need renaming, however, I’m trying to keep them aligned with naming in the client libraries.

If you are someone that would find a SAFE CLI useful, let me know what features you want.

If you are a veteran programmer and experienced with Rust, I welcome any critique or input to improve my skill level and to improve the quality of the code.

If there’s enough interest and usefulness, perhaps what may evolve out of this experiment is a non-FFI client crate built on top of safe_client_libs. <-- @bochaco @Krishna_Kumar


Probably some commands to list what is in your containers and download any NFS stuff that is found would be useful.


The next piece I’m thinking about is creating an authenticator daemon that runs in its own process, sending and receiving IPC messages to and from multiple CLI clients.

Authenticator and app concerns are currently local to the same process.

P.S. I also would like to be able to pipe in values from terminal commands.


being able to automatically publish / update data could be really useful : for instance a headless machine could periodically upload a weather map , a camera image, or whatever sensor data that keeps changing with time.


CLI tools:

  1. Ways to deploy websites/applications to safe network. Similar to OpenShift/Origin and its deployment of applications via YAML files and parsing set environment variables/router info :smiley: .

  2. CLI commands outputting safe network results and statistics

  3. CLI commands to interface with safecoin directly. Would make developing our own Safe Wallet apps wrapping the CLI with simple UI’s would be easy enough.

There is so much a CLI could do in safe network it will take 10+ years to make so guess getting the ground levels started now is great!


Does this create its own mock network or can it work with Peruse mock? And is it only mock atm?

Great advance Hunter :slight_smile:


This would be really useful as a portable none-ffi solution.

Ultimately, what I would like to see is full feature parity with the safe_app_nodejs repository, where it can be used to make requests to the network and interact with it fully.

Preferably, if it could be a fully CLI solution with no other working parts, that would be great (so no need for IPC or application life cycle work, you send it a request, it deals with that request internally and returns a response as stdout or stderr)

You may find that if implemented properly, this repository could completely replace the language specific FFI libraries currently used (I know I would prefer a CLI to an SDK any day).


Great to see this tool being worked on. It is essentially for embedded/hosted environments to be able to have headless tools to integrate.


What I was thinking to maybe try out later at some point (if the command line app doesn’t have to authenticate which each execution), is Auto Completion, where the ‘Auto Completion’ configuration comes automatically from date stored on your ‘account’ on the Safe network.
Maybe not very useful in practice, but that would be cool anyway :slight_smile:

1 Like

For the moment I don’t know SAFE enough (apologies), but I think that features helping to run vaults remotely are essential.
(But (hopefully) some exists already ?)

1 Like

Thanks all. This is very helpful.


Thank you, OpenShift is a good model that I can follow.

@happybeing It’s currently sharing MockVault, so if you create an account and authorise an application with the CLI, you’ll also be able to use that login with Peruse/SAFE Browser, as well as see the authed application. Yes only on mock until I can make sure that it’s safe for live network.

I’m so glad you bring this up because I was thinking the exact same thing, so the CLI is currentyly setup as you describe.
But now I’m wondering if I’m missing out on the flexibility to be able to run multiple CLI client processes and have them all be handled by a single authenticator server process?

Last night was reading about different IPC solutions. The simplest cross-platform solutions are HTTP REST and our current system URI registry that we use to execute applications with an encoded argument. Our client libraries are already designed to handle the latter solution and I don’t want to build a complex REST API, so I’ll need to experiment there.

Help me think this one through though. What is this CLI sacrificing by containing authenticator and app concerns in one process?

The one big thing that’s sticking in my mind is to be able to use a CLI client as one-off commands without having to keep my program running, as it is now.

For example, looking at OpenShift CLI operations, if I wanted to do that I’d need to store my App handle in a process to be accessed when I need to call an operation that requires it. Then I’d need to create a manager that updates that handle or drops it when it’s no longer needed.

@nbaksalyar Are there any restrictions for an account being logged in to more than one authenticator instance on the same IP address?


Great to see this appear!.. I count it among options that have big impact, relative to the effort. Saves us all trying to do the same task and reduces the challenge to those ambitious to try some daft idea that might just work.

So, any CLI that helps makes parts of http://docs.maidsafe.net/beaker-plugin-safe-app/ directly accessible, will be very useful, for each and everyone of those functions will inspire opportunities for services.
Also, it’ll be interesting to see how those requests perform without the browser in the way.

I’d want

  • Linux - is see [Development dependencies: stable-x86_64-pc-windows-gnu] but the rust is a huge step which perhaps suggests that’s possible already?
  • webFetch
  • Then some server like capture of requests… I don’t know what is required to see a request from a user form be posted, across what protocol, that the is picked up by a watching CLI that is logged in to an account allowing that, and that the receive a reply. Thinking along the lines of AJAX forms.
  • Then perhaps options to receive a user’s UID along with the request… allowing applications that are tailored to each user.

If you are a veteran programmer and experienced with Rust, I welcome any critique or input to improve my skill level and to improve the quality of the code.

Certainly not that but I’d suggest keep the design as modular and fragmented as possible to allow us to hack at it!



I’ve been working on something similar, also getting my feet wet with rust off and on since January. I guess I will need to up my game and release something too… I was hoping to maybe have something ready by devcon but current work needs makes it tough to meet that deadline…

I’ve only been able to work on this in my spare time, and most of that has been learning about the network. I don’t want to duplicate efforts so this is a screenshot of a draft of my help file. Not sure if you would want to team up? I had originally planned to get it to a final working stage on my own before releasing it on github though…

I debated between calling it SafeCLI (I was going to pronounce it safesly) or Safely in honor of Listy, Chaty, Vidy and Demoy. Guess I picked right. The other commands I’ve been looking into that I haven’t had time to investigate are chown, chmod, useradd, usermod, userdel, groupadd, groupmod, and groupdel. (Oops. Just noticed I’m missing mkdir in the help file.)


Yes! There’s probably so much that I’m missing that I could learn from you.

My first iteration was similar to yours, using clap-rs, however, I wasn’t sure how to best overcome the problem of where to keep the Authenticator instance running and where to store a given App handle, so I switched to a stripped down CLI program that must be kept running to run commands.

@davidpbrown ah yes, I need to reword that. I intended that to let developers know which version of rustc I’m using to develop but it should be cross-platform. I’ll give a test on Ubuntu.

@jlpell Oh I just realised something while looking at your documentation. Are you designing a whole new terminal altogether? That would be interesting to watch and learn. I think it would be more ideal than my current implementation of simply running a CLI program.


@jlpell Does that tempt option to mount a SAFE.space? That would be interesting to see. Anything that breaks down the conceptual boundaries and makes SAFE more familiar, can only help encourage engagement.

I doubt it. I’ve been rather slow in catching up on how to interact with the SAFE rust client libraries, and have a lot more to learn from you and others.

I do enjoy making these kind of interfaces though and have been going about the design of that by making it operate the way I would find most convenient for a working prototype.
Mine is currently running similar to yours, with the rest of the skeleton/scaffold in place, but most functions are non-working. I don’t foresee running the authenticator in another thread to be a problem for full “sssh mode” if necessary. Locally managing multiple accounts in “a SAFE way” has been on my mind. So a lot of work on the different functions has been held back. Each invitation code, account secret, and account passphrase is associated with a given name or alias similar to how things are done for ssh. The idea was to save them to an encrypted file on the local computer that could be opened via the user entering their passphrase only, or a different “safely passphrase”. That way, if their computer became compromised with a keylogger after account creation, then the adversary would not be able to access the account remotely on their own. Not that this really matters in the end, since if your machine gets rooted/compromised you’re done for. That’s why I was spending a little brainstorming time on a SafeOS, wondering if that is a better use of time, since almost Everyone’s OS is easily compromised in some way or another.

No, just a terminal program for linux or other similar OS. The input/output just mimics navigating the cli on your local linux shell. (I know SAFE is supposed to be for Everyone, but I don’t think there’s any hope in keeping data safe on any closed source OS. I don’t know of many non-linux users (well maybe Mac I suppose) that enjoy playing with a good CLI either…

The plan was/is to proceed in 2 phases, lately it looks more like 4. First get the cli working stable with all single commands (except for mount/umount ) via “–run”, phase 2 would bring in full interactivity or sssh. Phase three puts all of these commands into the rust fuse framework so that mount and umount functions work to enable something like SAFE-VFS (is this what you were referring to @davidpbrown? ). Last, hard or soft links would need to be implemented in order to get the website publishing features working like in the first SAFE-VFS that was written in ruby. This was all supposed to be a big surprise :birthday: :wink: but I think it’s good you brought up the topic. It helps me get motivated. If it turns out that I can’t pull it off for devcon (which is looking more and more likely - so I was looking to devcon to get a lot of what I needed to know to finish this), at least you have the basic outline I’ve been trying to follow for myself. Cheers! :slight_smile:


ohoh - how did i miss this?! :open_mouth:

okay - instead of directly interfacing safe you just are opening for me - the not so capable python-dilettante - a way to interact with safe from python without having to be able to write the c interface =D you are awesome @jlpell
edit: oh and you too ofc @hunterlester xD


Being able to get stuff off - and from user’s requests - and put responses back again, I wonder is bigger than the browser etc. SAFE is the network and getting at it, is most important. Big lumps of applications can only do what they are designed for, so many use cases once CLI is an option. Small random oddities I look forward to seeing.


@jlpell and I are teaming up on this project. The experience is already fulfilling deep educational desires. Thanks to him for opening the door to a new world for me.

This project is exactly the chance I’ve been looking for to start understanding system-level design, to get more in-depth experience with computer science fundamentals, and to start learning how to make good decisions by looking at other successful implementations.

One thing I’m learning is that there are small decisions to be made that may have far reaching effects and might break the usefulness of the design if use cases are not properly anticipated.
For example, if I were programming a hundred or so sensor devices to upload data to the network, I’d either need to automate the process of each device executing and logging into their own instance of Authenticator, or perhaps one and only one instance of Authenticator would be executed and logged in on a controlling device, sharing it’s instance of Authenticator with the cluster via RPC. Of course, how do I secure the exposed instance so that only my devices can use it to authenticate applications for the network? Isn’t the latter recreating the problem that SAFE network is solving?

What I’m getting at is that the immediate problem I’m thinking about is how to create a flexible enough design that can just be extended and doesn’t have to be refactored in the future in a breaking way. Is this possible or should I not worry about it so much and just make peace with the inevitable?

Anyway, here’s an initial DESIGN doc for the next steps in the project.

The component I’m focused on right now is an IPC and single instance library. The implementation that came to mind is Electron/Chromium, which uses named mutexes on Windows, and Unix domain sockets on OSX/Linux.

For other research areas, @jlpell got me looking into aws-cli which looks like a really good model, especially if we later get into remote device management.

Although beginning as an educational experiment, I’m curious to know if this project would be a useful @maidsafe (@Viv) undertaking to provide additional tools for network application developers?


Authentication options is my main desire.

A good reference (as jlpell has probably already indicated) is the aws-cli credentials options under the section titled “Configuration Settings and Precedence”.

There are six (six!) different ways to provide credentials to aws-cli. I know maidsafe is allergic to storing credentials in a file but I say people will do it anyway so let them (and let them pollute their bash history and script files etc). Inform people of best practices but don’t take away the options.

Another thing I’d like is the option to have app-specific authorisations as part of the credentials. So as part of the credentials I can set which apps have which permissions. This means there should be

  • no long-lived process, it’s all part of the command or environment
  • no prompts for user input
  • possible for machines / processes to manage permissions rather than the person running the command
  • wrapper guis to generate authentication files becomes feasible

And also, a multiuser environment, as in, the option to manage multiple users from a single credentials configuration. This is going to be important, especially when safecoin comes out. It should be easy to specify which user is running which command. I’m thinking the cli equivalent of chrome browser profiles.

If the rpc / ipc route is taken, jsonrpc is the protocol I prefer (bitcoin has a good jsonrpc interface) - it has good library support across many languages. But personally I think rpc is only suited to vaults, not clients.