Is there a GUI for doing basic cli commands?
or how hard it would be to make one with the current safe client code?
like clicking on cat a file which will have input for xorurl and a file manager call to where to create the file and what name to give to it? maybe even dog first the url and give the original name to the file as default?
I remember there was an attemp for GUI for the safe client?
i think I found the old thread of gui and there was an attempt:
can we get this updated?
also this:
I can try to revitalize the CLI2GUI to match the new cli commands. I hope it’s possible to wrap it into a Electron Application so it can easily run on windows, mac, or linux.
I don’t have mac so think for now that will not be easily supported, mainly focus on linux at the moment.
If someone could make a list of commands they use so I can create simple buttons for it or drop-down list items/check-boxes so when you click exec it will combine them all. I’m not up-to-date enough with all these latest comnet commands so that would be really appreciated.
you could collect the comnet and smoothnet safe networks add and safe networks switch commands
also safe cat <xorurl> > filename where the user gives the xorurl and filename
safe files get <xorurl> foldername where the user gives the xorurl and foldername
safe files put file/foldername (optionally -r for recursion)
safe keys create --for-cli
safe keys show
safe wallet create
safe wallet deposit --dbc <longdbcdata or dbcfile> <walletxorurl> where the user gives dbc data or dbc file and the walletxorurl to deposit to
safe wallet reissue <amountToSend> --from <walletXorUrl> --save <toFile> (optionally --to <wallet Hex BLS key>) where user gives the amount to send, wallet XorUrl from which wallet to get the moneys, and optionally --to the wallet Hex BLS key to make it owned DBC
there are some niche ones too
safe files ls <xorurl>
safe files dog <xorurl>
@Southside is it --to or --owned from your tests for reissue?
Ah the --to or --owned issue…
I need to read safe wallet reissue --help again very carefully then improve the wording and submit as a PR. I found it quite confusing.
We were about to test this the other night and then the network died or I fell asleep, perhaps both.
I’ll check again later tonight.
meanwhile heres a couple of handy one-liners that could get knocked up into a post-setup script
safe keys show|echo $(grep -oP '(?<=Public Key:).*') >public_key.txt && export PUBLIC_KEY=$(cat public_key.txt)
safe wallet create|echo $(grep -oP '(?<=Wallet created at:).*') >my_new_wallet.txt && export MY_NEW_WALLET=$(cat my_new_wallet.txt)
These commands will capture your Public Key and wallet address, copy them to text files and also set up the PUBLIC_KEY and MY_NEW_WALLET env variables for future use.
There is more than one way to do this, I cribbed shamelessly from shell script - How to search and extract string from command output? - Unix & Linux Stack Exchange
Just to clarify on the current intention. The --to argument is for you to reissue to some particular person so that the DBC is owned, i.e., can only be spent by that person. The person is identified by their public key. The --owned argument is to reissue a DBC to yourself, so it can only be spent by you. The key used is the one currently configured for use with the CLI.
To me, the --to seems fairly obvious, but to be honest, I’m not completely clear on what the utility is in reissuing a DBC just to be owned by yourself, other than to prevent another person spending it, but it does seem like a legitimate scenario that should be supported. Could it possibly be changed to --self-owned?
I’d welcome suggestions on the renaming of arguments for a better user experience. One thing I didn’t quite like about --to was that there is also a --from argument, which kind of makes me think of email to/from and that these arguments would be linked somehow, but in our case, the --from refers to a wallet URL. Perhaps that should be changed to --from-url, or even --wallet-url?
I reckon --from-wallet-url and --to-wallet-key and --self-owned
Thanks for the suggestions. I’m not sure about --to-wallet-key. We’re reissuing to a particular person, based on their public key. The wallet is just a storage area and the person could deposit the DBC into any number of wallets they have.
It may help at this time to think big.
Imagine AWS starts accepting SNT. Punters pay their monthly AWS invoice in a lump sum. AWS then needs to identify te payee’s location, take 20% for UK customers and send that to AWS-UK-VAT-fund wallet, That is done with a --to argument. Similarly they allocate some of the funds from that payment to EC2-Europe and S3-Europe etc etc also with --to. Then the funds in EC2-Europe are either disbursed as payments to AWS suppliers who also accept SNT or are sent as --owned to the BezosTittiesandBlow account. And similarly for different locations and accounting units
If we don’t make it easy for accountants from the start then we will face difficulties later.
My thinking is the --from argument as being used when there is any ambiguity about which wallet you control and you need to choose which accounting unit wallet is to make the payment. --to is for almost every other case whether you pay a supplier or a friend --owned is for when you retain profits and have yet to decide which particular wallet these funds are to be disbursed to.
But an actual accountant could state this more clearly – and correctly.
--owned has a problem and needs a better label in any case.
–to-key then?
Thinking some more - is this getting unnecessarily complicated?
Can we eliminate the --owned option?
Any person or entity can set up multiple accounts - ie multiple Public/Private key combos. Each account can set up multiple wallets and name them as they desire.
When someone pays a bill or buys a product, they pay that invoice to a named account specified by the recipient. So your monthly AWS bill gets paid to AWS-Europe who publish a Public Key that has a label like AWS-Europe-Receivables. Then its up to AWS to internally transfer to their various “buckets” (wallets) VatDue, Power, Salaries, etc etc
Every payment is made --to a person or entities account. It is then up to that person or entity to deposit the DBCs into the wallet(s) of their choice. I imagine that for most folk they will have only one wallet so automating this could be straightforward. Corporate entities will need to do more work but that’s called the Cost of Doing Business. And with DBCs we make the accounting much more transparent. This may not be universally popular but sod them…
Thats already built into the various billing systems now and when those billing systems enable crypto then it follows the exact same procedure.
So no need in that case for SAFE to do any different. The user, customer, whomever is billed and the various tax components are itemised. At the end of the billing cycle the correct amounts are sent to correct authorities/tax-depts/etc. X snt to UK tax, Y snt to AU tax etc. Double --owned would be needed to be used. Just all comes out of consolidated addresses
I might take a look again at updating but prefer waiting for a stable network instance to play against rather than keeping up with every change… it’s not too difficult… just a gui on on top to action each command. 