I think when doing operations on the CLI that need safecoins, there should be some sort of prompt for asking the user like This operation will approx. cost 3 safecoins. Continue?.
I imagine a scenario where a user might accidentally upload a huge amount of big files and has to pay for it.
Caveats and potential solutions
Is it possible to know the cost of safecoins before the operation takes place? I really don’t know.
we must be able to deactivate it when in headless mode
maybe we can also have a config where you can set an upper limit of safecoins to spend per operation
in sync mode it might be better to set an upper limit of safecoins to spend per time period (e.g. max 3 safecoins per week)
here the problem is that we might have already spend 3 safecoins during 6 days. Now what should happen?
should the sync just exit?
should the sync stop and continue after the 7th day (after the next time period begins)
Overall, I think, this mechanism is really important, because we are dealing with real money here in the end.
General question that ties in to the above points: Is there a way to undo an operation and get the safecoins back that have been spend on that operation? That might make the above points obsolete. See also:
Thanks for the interesting write-up of the SAFE CLI. I am really looking forward to see it in action in the wild!
Hey @janriemer, thanks a lot for this input/feedback/thoughts.
I think the --dry-run arg should be the answer to what you suggest, which eventually should show you the potential cost of it, if it is effectively possible to estimate the cost.
Some other thoughts were that the interactive shell we envisioned to have, can perhaps be the place where it prompts you for many things including the potential cost perhaps, so you could then jump into the interactive shell with just running safe, and then inside of it you are prompted for several things and defaults are inverted, so e.g. in interactive shell you do:
Welcome to SAFE CLI interactive shell!
Type "help" for more information about supported commands.
Type "exit" to exit this shell. Enjoy it!
safe >> files sync ./localfolder safe://mysite
Files will be uploaded recursively, is it ok? [Y/n]:
We will be updating 'mysite' NRS name as well, is it ok? [Y/n]:
This operation will cost ~ 0.000044523, is it ok to proceed? [y/N]:
Having those configs about expenditure could be also possible and a nice idea, perhaps that could be stored locally in a config file, or even within your SAFE account and the CLI reads if you are logged in.
thanks for the swift and elaborate response.
Oh, I didn’t know about that option. Nice!
Yeah, I really like that idea. Although that would not fix the problem when running in non-interactive-mode (which is the more common case, I guess?).
Nice, I really like the idea of storing it in your SAFE account. Maybe in the first iteration we still have a separate config file for the CLI and in the second iteration we finally move the whole config over to the SAFE account.
Cool, thanks for the hint.
Man, I really have to catch up on SAFE. I haven’t been here in a while. But I guess that’s a very good sign that so much has happened since my last visit, so I am not complaining.
Another possibility if it is practical, would be for there to be a default max cost per command which would trigger a confirmation prompt, with the user able to override that limit with an environment variable.
A Safecoin cost might not be the best measure for this because the store cost could change dramatically as Safecoin value fluctuates, so the limit might be better expressed in storage operations.
I think we will want users to be able to set trigger cost limits in various scenarios, so addressing this in the CLI might help design a general approach.
Well it sounds like we have some nice things to explore and test here, although I presume this won’t be possible until we can estimate the cost of the operation/s somehow. So let’s see what we get from vaults when they evolve and we can test this as soon as it provides some type of estimation possible.
Well, we do have a complaint here, why have you been away for such a long time??
We have the files sync command which was originally thought to be like rsync, and we are now probably changing some bits as per feedback received. Are you on the contrary suggesting something more like being able to hook other tools, kinda plugins for the CLI which we wouldn’t need to maintain?
The benefits to developing standard and optional subcommands separately from the core include:
Improves its quality and the developer experience.
Having the possibility of offering both a native (sync) and compatibility (rsync) subcommand is good. Moreover, there are several ‘eras’ of rsync in wide distribution, due to issues such as licensing, and supporting externally developed and maintained subcommands for interface variants would be trivial. (rsync26)
I can envision CLI subcommands as a useful extension point for those developing for SAFE.
 “rsync version 2.6.9 protocol version 29; Copyright (C) 1996-2006” is what’s included with macOS Mojave.
Right, sounds cool, i think we should look at something like that in the future, it should also encourage devs and users to contribute to CLI as they can create these tools as they wish and users would just pick them up at their will expanding the SAFE ecosystem.