New Release: Vault Phase 1 (mock vault)

Development Releases
21

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.

safe_auth

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.

safe

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.

25 Likes
22

@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.

19 Likes
23

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:

10 Likes
24

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

13 Likes
25

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.

11 Likes
26

This sounds good. Question though about “providing the keys”…when it comes to hardware, with other cryptos don’t the keys stay in the device, and the device does transaction signing in its secure environment? Is that same approach going to be applicable here, or do the safecoin transactions work in a different way? In other words, do we have to actually provide the keys, or just prove knowledge of the keys via signature?

10 Likes
27

I think the same approach can be applied here, this is not possible now as the signing and transfer request generation is deeper in the client libs stack and we’ll need to expose an API to be able to provide a signed TX rather than just the sk and recipient, and then we would request such a device to generate the signed TX as you say.

11 Likes
28

Great work team (at least I think).

My point being is, is that I somehow fail to see the relevance of this. Why does this matter? Why is this a big deal? What can be enabled with this?

I guess, many of you are following all the details all the time, and then this means something, but I’m pretty sure - presented like this - this is only interesting for a (very) small part of insiders.

Now, maybe this is intentionally, because you want to avoid traction/interest from a larger, less technical/informed group. But if it is not part of the strategy, I really recommend put things by default into more context. Make it relevant. Why does this matter? What does this enable? There is a big gab between “saving the world” and delivering some obscure piece of technology :wink: (no offence people)

7 Likes
29

This is the first of a few steps into use of the developer API. So it allows you to create accounts, safecoin balances, transfer safecoin, pay to put data etc. So while the API is not complete here or able to be used by anything other than rust atm we have the CLI tool to allow folk to issue commands at a mock vault and start to realise what it all does.

Soon it will be a real vault and you can host that on some machine and have many clients connecting to it. With the FFI bindings and the browser etc. (we have a browser POC now) then you can do all the above and use the vault like a server, importantly though that emulates the whole network. That means app devs can use a real vault and work locally, or share a vault between groups etc. to test apps, scenarios and more.

No worries :smiley:

28 Likes
30

Perhaps to add to what David mentioned already, this is actually all about an strategy to then be able to move faster. Before we had a couple of example GUI apps which were dealing with things like creating public names, uploading files and creating the correct structure on the network, etc., and exposing different use cases in such GUI apps takes much more effort than doing it on a CLI UI, so we can try and test many use cases and UX with little effort as tweaking a CLI UI is way much simpler than tweaking a GUI. On top of that, once we have tested and happy with the UX for these use cases, we would then be having an API which fully supports them, so we can create different GUI app which don’t need to deal with this aspects/tasks, we would know the API works, and all we need to do is put a nice GUI on top of it. I hope that also helps @Thomas

20 Likes
31

Have been playing with it.

My thoughts; I find the abbreviation pk and sk very confusing as newcomer.

$ safe keypair
Key pair generated:
pk = b2371df48684dc9456988f45b56d7640df63895fea3d7cee45c79b26ba268d259b864330b83fa28669ab910a1725b833
sk = 62e323615235122f7e20c7f05ddf56c5e5684853d21f65fca686b0bfb2ed851a

pk could mean both [private key] or [public key]. And with pk cointaining the longer string compared to sk I would guess private key…

sk could mean both [safekey] or [secret key]. So confused here as well.

Can’t we just use the terms private and public? I think everybody is familiar with these terms nowadays. We don’t need the term key here as well. It already says ‘Key pair generated’. So we know it are keys.

15 Likes
32

Thanks for the feedback, all amazing :+1:

I think in many crypto libs they now use public and secret for the keys. In code it is generally pk sk but yea for sure in the output it would be nicer to be more descriptive.

19 Likes
33

Am I the only one that find the argument order in safe wallet transfer command not intuitive?

The usage is the following: safe wallet transfer <amount> <to> <from>

I would have naturally reversed <to> and <from> arguments, and initially I even thought I came across a bug.

An example of what seems the right order to me is the bitcoin CLI:

bitcoin-cli createrawtransaction "[{\"txid\":\"myid\",\"vout\":0}]" "[{\"address\":0.01}]"

(the first argument is the “from” part and the second one is the “to” part)

13 Likes
34

I would also think ‘from’ → ‘to’ is better. The ‘from’ is the part over which I have the most control: it’s my decision who I pay, I know the balance of my wallet etc. It seems more natural that way. ‘I pay you’ rather than ‘you are paid by me’.

10 Likes
35

I thought that too, when I looked at the docs. From, then to, is definitely more intuitive. At least you can’t spend someone else’s coins, but still.

6 Likes
36

Another remark: I am surprised that we need to provide both keyurl and sk arguments in order to create a wallet with a default spendable balance provided by an existing safe key.

Normally we can generate:

  • the public key from the secret key
  • and then the address from the public key.

I guess this is to verify that they correspond to each other, but why make keyurl mandatory? The safe keys balance command has the same arguments (keyurl and sk) and keyurl is optional and the verification is done only if it is provided.

Why not the same principle for safe wallet create command? The 2 commands are not consistent in the usage of these 2 arguments.

1 Like
37

Come to think of it, Linux links use to → from and I’ve always hated it because I always get it wrong and have to look it up.

ln a b            ---> create hard link called "b" to "a"

so you’re linking from ‘b’ to ‘a’ but the command is the other way around. :crazy_face:

6 Likes
38

Think about it as a special copy of a into b, so the first argument must be an existing file and usage of ln command can be interpreted as ln <from> <to>, where <from> is “copied” into <to>.

3 Likes
39

Doesn’t help, sorry! That might be what’s happening deep down, but why not abstract it away for the end user?

1 Like
40

I think of it like copy too, but I agree it isn’t intuitive.

2 Likes