Exactly: it is like cp <from> <to>, except that if <from> is modified afterwards then the modifications are propagated to <to>.
Another vote here for <from> → <to> just like a Linux copy or move on the command line! Please, please,please… to infinity…
4 Likes
Things are worse than what I described because keyurl argument is not mandatory but if it is omitted then sk argument is ignored.
For example create a safe key preloaded with 0.2 coins:
$ ./safe keys create --preload 0.2 --pay-with f97f4be4c087fa77439470db17266300bbf7cb507f6840f056b8bd4a28daf829
New SafeKey created at: "safe://hbyyyybm8j4uyxhpc6go1sbisdrmf7osuuw9wk7fs49mym7t8e5ugjqy4h"
Preloaded with 0.2 coins
Key pair generated:
pk = ace9d4c0fe359e342560d6c322cbd85a73a7e8ae96dafac0bec4e8dccc97035c2142eff270cff92442850e15ecec55e6
sk = 2b622825d85fde056422d909ce30ab2087a983e12e552d828d6b296f6604b258
Then create a wallet from it by specifying only sk argument and not the corresponding keyurl argument:
$ ./safe wallet create --sk 2b622825d85fde056422d909ce30ab2087a983e12e552d828d6b296f6604b258 --pay-with f97f4be4c087fa77439470db17266300bbf7cb507f6840f056b8bd4a28daf829
Wallet created at: "safe://hnyybyp5d4dwfau37f59cposeeepyfhdjf8nf184qhdxuh9eiw8sztm1ooy9e"
New SafeKey created at: "safe://hbyyyyby9jz4prd5ngbbym91n5rs3jt7gt5yxatu4bqsn8ctto6xh7hwu6"
Key pair generated:
pk = 83e9be9a41ec460840bfc85b25b298f4d1d81f88cf417584764630f3f9de527eeb53c8b57a6df431620b8ebfcf5be1eb
sk = 9c8c9e7016c7926d0e1cf69caa7714457e2991890946e4a49668c567c9368b08
The provided key has not been taking into account. Instead a new key has been created and resulting wallet has an empty balance:
$ ./safe wallet balance safe://hnyybyp5d4dwfau37f59cposeeepyfhdjf8nf184qhdxuh9eiw8sztm1ooy9e
Wallet at "safe://hnyybyp5d4dwfau37f59cposeeepyfhdjf8nf184qhdxuh9eiw8sztm1ooy9e" has a total balance of 0.000000000 safecoins
Now create a wallet with both sk and keyurl arguments:
$ ./safe wallet create --sk 2b622825d85fde056422d909ce30ab2087a983e12e552d828d6b296f6604b258 --keyurl safe://hbyyyybm8j4uyxhpc6go1sbisdrmf7osuuw9wk7fs49mym7t8e5ugjqy4h --pay-with f
97f4be4c087fa77439470db17266300bbf7cb507f6840f056b8bd4a28daf829
Wallet created at: "safe://hnyybyqas8yquhzqas5neuohh3wy7g3egjwn1joo7r96w9m1s4w3fhauhcy9e"
Here the safe key has been taken into account and the wallet has the right balance:
$ ./safe wallet balance safe://hnyybyqas8yquhzqas5neuohh3wy7g3egjwn1joo7r96w9m1s4w3fhauhcy9e
Wallet at "safe://hnyybyqas8yquhzqas5neuohh3wy7g3egjwn1joo7r96w9m1s4w3fhauhcy9e" has a total balance of 0.200000000 safecoins
I think the right behavior regarding sk and keyurl arguments should the same as safe keys balance command which seems justified to me:
| Arguments provided | Behavior |
|---|---|
| Both sk and keyurl | Check that keyurl corresponds to sk and proceed with sk |
| Only keyurl | Prompt for sk, check that keyurl corresponds to sk and proceed with sk |
| Only sk | Proceed with sk |
The difference in safe wallet create command is in the third case where only sk is provided: here sk argument is completely ignored which looks like a bug to me (possibly a confusion with the 4th case where none arguments are provided and a new key must be effectively created).
8 Likes
I’ll be looking into the wallet create thing @tfa, it also seems like a bug to me.
As per the wallet transfer, I’m also part of your club, I can never get right the ln cmd order 
. I agree we should review this, although, just to give more context, they are positional args and < from > is prompted from stdin if not provided, initially that’s how we imagined to support piping cmds in the future, so we may need to drop that idea altogether and/or have a --from arg instead of being a positional arg (i.e. wallet transfer <amount> <to> --from <from>).
13 Likes
Dear David, I very much appreciate you replying personally to my statement. Thank you for shedding some more light on the topic. I also went again through the published SAFE Network Roadmap and it makes a bit more sense to me now.
I think I’ll stay on the high level and translate it for myself in layman terms: The Vault is a requirement for allowing people to connect their home computers to the network to offer spare storage, and in return get rewarded for it in (test) SAFE coin.
Some more steps will be needed to get there, naturally all very technical. I can’t wait to get access and hook my computers onto the network
Looking forward to the next milestone!
14 Likes
Not quite! You don’t need a vault to use the network, a vault is what you need to farm safecoin.
You can browse the network without safecoin, all you need is a client such as the SAFE Browser or SAFE CLI, or any app written to access the network directly.
To upload or write to the network you need safecoin, but you don’t have to farm these so again a vault is optional because you could buy safecoin without having a vault.
It makes sense to run a vault if you can, but it isn’t necessary for any use of the network except to farm safecoin.
11 Likes
Thanks @happybeing
That’s what I meant, but you’re rightt, i’ll make a correction: connect to the network TO offer spare storage.
4 Likes
Ah sorry, I see I read the sentence one of two ways! Good to clarify.
1 Like
Another remark again related to wallet creation: I don’t see the use of --no-balance flag.
-
If user provides a --preload argument or a --test-coins flag, then this would be contradictory to an empty balance.
-
If user doesn’t provide a key, then the command creates a wallet with a new key that has necessarily an empty balance, so there is no need to indicate it.
-
If user does provide a key, then the command creates a wallet with this key and the wallet will have the balance of the key, and there is no way to change that.
So, I don’t see any cases where this flag can be used.
Edit:
Unless --no-balance doesn’t mean a default key with a balance of 0 coins, but instead a wallet without key. This would make sense. But in this case this flag should be made incompatible with --sk, --test-coins and --preload arguments (just a control to add to prevent this).
3 Likes
But why favor <from> over <to> for this feature. And why not both? In bash it is possible to do that for positional arguments using <(…) syntax like:
$ ./safe wallet transfer 2.13 <(subcommand1) <(subcommand2)
I remember having successfully used this syntax for arguments of diff command.
2 Likes
Perhaps the name is a bit confusing, what it does is prevent from creating a SafeKey, which happens by default as you describe, when no SafeKey is provided, which means it’s just for creating an empty Wallet with no spendable balance (i.e. no SafeKey in it). When a SafeKey is otherwise created by default, it has a 0 balance, and it’s automatically inserted in the Wallet. So the difference is that you can have an empty Wallet, or a Wallet with the SafeKey created by default with 0 balance.
This will be easily seen when we add support to do a cat on a Wallet which I was imagining it would show you the list of SafeKeys it contains and their corresponding balances, plus perhaps the total balance of the Wallet. Also, right now the Wallet doesn’t allow much more than just having a default SafeKey which is used for a transfer, eventually we will have support for other type of logics around how to use each of the spendable balances (SafeKeys) when performing a transfer, e.g. choose which of them you wanna use for a transfer, or automatically select the ones with smaller balance until the desired amount can be covered, etc., if you’ve ever used/seen the btc Wasabi wallet then that’s what I’m trying to describe. As you see, we are still in the basic version of a Wallet and possible operations with it, but that’s the overall idea we based it on.
It can be both as you say, the syntax you describe could be ok also, and I’d personally also like to so the piping as well, so we need to find a balance and ways of supporting as many flavors of these use cases as we can. I think I’ll have time tomorrow to dig into this specific aspect, we’ll see. (btw, FYI: https://github.com/maidsafe/safe-cli/issues/218)
9 Likes
Yes, this what I supposed in my edit. The right thing to do would be to display an error when user provides simultaneously --no-balance flag and one of --sk, --test-coins or --preload arguments.
1 Like
Please note that I have recorded a demonstration with asciinema as an example on how to use safe auth and safe cli:
- Create an account with coins
- Launch safe auth daemon
- Authorize safe cli
- Create a key with 1 coin and create a wallet with this key
- Create another wallet the same way
- Transfer 0.2 coins from the first to the second wallet
34 Likes
Loved this video/tutorial @tfa. Anymore to come showcasing NRS etc, perhaps? Really valuable you did this as it turned out to be a bit over my head for my schedule.
8 Likes
@tfa What might be an added bonus after creating some human readable NRS url’s would be to have a wallet tied to it (if that’s currently possible) and to send a payment to that human readable url.
8 Likes
That’s already possible @Nigel, you can link NRS public names/subnames to SafeKeys and Wallets, and then use the NRS URLs for the commands like wallet transfer or balance queries.
14 Likes
I’ve been testing the cli tool for a while now - if I get the chance I will make a video giving an overview of the nrs commands.
Like @bochaco says, you can link nrsurls to xorurls and then the commands work the same using the nrs links.
10 Likes
The more vids we get from multiple sources showcasing features and explaining how to and what it all means, all the better! If you get to it that would be really great 
6 Likes
OK, leave it with me. I’ve worked with the cli quite extensively over the last few weeks so I’m probably in a good place to do stuff like this.
15 Likes
OK, I’ve made a start on some videos - constructive feedback always welcome: karamu's profile - asciinema
16 Likes