New Release: Vault Phase 1 (mock vault)

So it’s just CLI at this point, but SB Dev? will migrate to this soon-ish. Anything else?

WHM seems redundant and tbh I still don’t know how to use it to upload a directory tree so would probably just use CLI.


Great to see this one out the door, been looking forward to it!


Yes, CLI for now, but as you spotted last week’s dev update we are already playing around with JS bindings on top of these new APIs and new data types which should allow us to have the browser to read this data as well, ofc. So not there yet, but in the path and with priority. There are no plans now to have WHM UI to be compatible yet, we’ll see how things evolve to decide what’s the best UI for the same commands supported by CLI to upload files and publish safesites, CLI supports all this for now.


It will be awesome just to push or pull a site with a few key strokes. Reminds me of git… which I suppose is rather neat, considering files will be versioned out of the box! :wink:


The team is ‘vaulting’ right over phase one! :wink: Great work MaidSafe team!


A post was merged into an existing topic: SAFE Network Dev Update - August 22, 2019

Wow team, you really are pulling out stops — it’s beautiful to see this come together, step by step.

Many thanks to everyone helping to make this possible!


Thanks, trying out. Can you give some basic command examples to start with? Or is there some documentation? (I always have trouble with the --help option on these kind of tools, just some examples is much easier to understand)


On running the safe_auth package in Windows it goes straight into a prompt for secret and password but doesn’t accept my existing ones, or any new combination I can come up with.

PS C:\Users\John\Documents\SAFEnetwork> ./safe_auth Secret: Password: [2019-08-22T19:26:43Z ERROR safe_auth] safe_auth error: Failed to log in: SndError(NoSuchLoginPacket)

I agree with @nevel a starter guide with examples would be handy, or at least some instructions prior to the password prompts.

Edit - same with Ubuntu.


Have you seen the examples on this page?


@nevel @JPL , we have a User Guide in the README itself as @draw was pointing out, anything you don’t understand there, or that you think should be enhanced/added, please comment and we’ll try to help you.


That’s because it’s assuming you want to login rather than create a new account. You cannot use any existing credentials since this is the Vault-mock, so it’s not shared with Alpha2 accounts or mocks, you’ll need to create a new one. To create a new one look at this section here: GitHub - maidsafe-archive/safe-authenticator-cli: This crate implements a CLI for the safe_authenticator crate.

In any case, it’s good to go thru both User Guides in this order and follow it:


Hi @bochaco - yes I tried that. I can create the keys but afterwards I can’t log in. I’ll keep playing. I’m probably missing a step.


Ok, just in case anyone else is having a similar issue as JPL, this seems to be working fine (for @JPL as well):

$ ~/Downloads/safe_auth --test-coins
Account was created successfully!
SafeKey created and preloaded with test-coins. Owner key pair generated:
pk = 881db434cef108b5aa7b46f1870b789f6b06f684c3271fbbb3b33d4d053cf21373aedd205d79d5c10cd839c3891459fd
sk = 63e3dbaf74a6b4160fa822fda563a366dce7df5657b3404e1d16f2431cf8776c

$ ~/Downloads/safe_auth 
Logged in the SAFE Network successfully!

But, to authorise the safe_cli app you need to run the safe_auth with --daemon as explained here:


This is the perfect opportunity for @jimmyhacksthings! :smiley: Jim do you happen to have the equivalent of a bat symbol I can shine out into the clouds? Would love to have a YouTube video to help me through this (I’m a visual and auditory learner) and to share with others.


This is fantastic, really a beautiful interface. And the readme in the repositories are easy to use and well written.

Apologies for the length but these are my genuine first impressions and there’s no second chance at that, so even if some of this later turns out to be misconceived I think it still has some value.


When using --test-coins maybe a message about how pk/sk might be used or what to do with it (if anything). Great to see those values being displayed but maybe some more info about why could be good. But also I appreciate the concise interface, so a bit of give and take in this.

--allow-all-auth maybe could have single-letter flag of -y like many package managers have for assume yes. Maybe consider changing the long name too; apt uses -y, --assume-yes, yum uses -y, --assumeyes, pacman has --noconfirm which to me is ambiguous. Seems like assume yes is fairly common terminology.

Would you consider allowing pk/sk in config file as an alternative to secret/password? This might make it easier to utilise other secret derivation schemes such as bip39 instead of the maidsafe derivation with secret/password.

running ./safe auth creates ~/.safe/credentials with permissions 664, I think 600 would be more appropriate.

Stepping back a bit, safe_auth is a good name but what is this package really doing from the user perspective? I ask because safe has a command auth so there may appear to be some mixing of concepts, especially to new users. I’d say maybe safe_auth is more of a control center or safety filter or bodyguard or protector or something like that. I feel that _auth suffix doesn’t have enough weight behind it. A little bikeshedding, but also a little way to remove mental load and help the intuitions of newcomers.


Is there a way to specify safe_auth --daemon for a different port from 41805? I ran the daemon on 31805 and couldn’t seem to get safe to talk to it.

safe cat and others use a table layout. Just wondering if this table format can be suppressed so the output can be piped, ie just a list of items like ps or ls? I think maybe the most expected default behaviour is no table, and use --table or --pretty to add layout.


@mav that is really awesome feedback and extremely welcome here, we need/want more of this so please keep it coming and sharing as much as you wish and are able to, thanks a lot!. I/we will put all that in the backlog to consider them for next iterations.
Answers/comments to some of your points:

Yes, it may be clearer moving forward perhaps when we add more features to it, not fully sure, I agree with what you say though.
To give some context, some ideas we are considering is that the safe_auth CLI is just a small UI for triggering/launching and managing the Authenticator daemon, the daemon becomes what you decribed, it also exposes an interface that any Authenticator UI can connect to for providing the user the tools to administer accounts, apps’ authorisation and apps’ permissions. The safe_auth CLI is just one of the many Authenticator UIs that could exist, SAFE Network App (SNAPP) can be another one :wink: , and there could be 3rd party ones as well, who knows, perhaps corporations prefer to have some customised version of the Authenticator UI which also works as a bridge with their other internal systems…dunno…just thinking out loud now :slight_smile:
An Authenticator UI can also allow you to launch/stop the daemon. Apps would also connect with this daemon service, like what the safe_cli does, and any Authenticator UI can register (to the daemon services) to receive notifications for authorisation requests, and to send back the response/decision made by the user. It’s probably a bit confusing but just in case it already helps and/or inspires others to throw some ideas here.

Yes, you can do $ safe_auth --daemon <port number> and on safe_cli $ safe auth --port <port number>. This is all in the help menus you get with --help / -h for both CLIs.

Yes, we have plans for this type of things, right now we only have two output formats, the human readable one (default) and a --json one which can be parsed. We still didn’t go to implement other formats including choosing to have a single value output for piping, but we are definitely aiming at having such things.


Ah I see now, I thought there was only
./safe --help
I didn’t realise there’s also
./safe auth --help
with the info I needed :slight_smile:


Yes, every subcommand has its own help menu too, nevertheless don’t stop asking please!


We have been talking about these aspects a bit, and you’ll notice that the safe_cli has a --pay-with arg which you can use to decide which SafeKey use to pay with rather than using the default that is linked from the account, so this means we are already trying to open up the possibility of providing the keys for each operation independently, and from different sources like a config file, hardware device, manually entering it since you had a key in a paper wallet, etc.