The whole thing does seem really juvenile and maybe not a big deal that people crack jokes or snicker but if it’s easy enough to change then I don’t see why not.
2 Likes
To be clear, ‘any type of operation’ does not include creating accounts?
Creating accounts can be done via the safe-auth-cli. Right now there’s a question of whether that should be rolled in to the general cli or not. Or if we let folks choose their authentication/approval mechanism.
1 Like
This is not detailed in the OP but currently an account is created if an invite token is passed as argument.
1 Like
I would prefer one that is integrated directly in the safe-auth-cli, like current implementation, because this is simpler for users. But if you do so, please provide one without GUI that can run on a headless system.
2 Likes
I’ve had my say on the PNS controversy over on the dev forum as requested.
TL;DR Sorting the acronym for the system without first considering the end user, is the tail wagging the dog.
3 Likes
How does this reconcile with
automated scripts in a piped chain of commands
…within the realm of domain squatting
an account is created if an invite token is passed as argument
‘invite token’ is only a testnet thing though?
1 Like
The API can already be automated to do this easil, so the CLI only makes that marginally simpler.
The question is still unresolved, I just don’t see the CLI as relevant and so best not in this topic IMO.
2 Likes
As @happybeing notes. Us not building a cli doesn’t prevent anything. If anything building it levels the field some.
Either way. If automated squatting will be an issue hopefully we can resolve that via other means. (costs of creation or other who knows what). But aye. Probably another topic altogether.
Och. And yep. Invite is a testnet only thing
2 Likes
Fair point, one of the more intriguing unresolved’s.
2 Likes
I think I didn’t quite understand what is envisioned: Is safe-auth-cli in daemon mode a possible external authentication mechanism for safe-cli?
In this case I would be happy with this, as the whole thing is without GUI and can run on a headless system.
Would this also be true for programs written in another language (C#, NodeJs, …)?
Currently, they all need a Safe Browser running, meaning that they cannot run on a headless system. If they could connect to safe-auth-cli, that would solve this problem.
Then another flag will need to be added to safe-auth-cli to create an account. I mentioned invite parameter just to indicate that account creation is possible right now.
1 Like
That’s the aim yep. Right now you can run a simple http server to run Auth requests, but later on we’re aiming to provide a deamon option. So any language that can execute bash scripts, or http calls will be able to Auth / create accounts etc.
We’re aiming for as much as possible to be possible without a GUI.
7 Likes
Very interesting design document. I think a CLI is a very nice and welcomed addition for developers and users.
I’m thinking about the architectural side of the CLI. Taking the following into account:
As I understand it a new API will be built that is higher level than the current SCL interface. This new high-level interface will initially be built and designed by developing the CLI in tandem. And, as I interpret, the API could be used as an alternative to the SCL by programming languages other than Rust.
For other programming languages to interface with this API I assume it will have/be an FFI, just like the current SCL FFI that apps built upon. I’m not sure I like the idea of two separate FFIs, or will the new API be part of the current SCL suite?
I’ve spent my fair time studying the SCL FFI and while it is fairly complex as it is low-level-ish, I’m not sure what a high-level variant will look like.
A question from another angle: Why wouldn’t the CLI be implemented in something like Python using the current SCL FFI? If it appears to be difficult, the FFI can be adjusted to become more user friendly or more functions can be added that are higher level. The CLI written in Python will then be used as a kind of reference implementation showcasing the FFI. This would be in the form of well-documented idioms that could educate SAFE developers.
(I picked Python as I assume it’s one of the easier to understand languages without being proficient at it, in contrast to Rust.)
4 Likes
Spoiler - once the api changes have been implemented (and @dask and me have a little bit of time again) our goal would be to ship pySafe with a simple command line tool too and a little local rest/graphQl server where random languages can just use ‘local Web calls’ to interact with an alternative authenticator… Once we have implemented the basic ffi functions and some comfort functions to pySafe that take care of the annoying handle stuff this should be very straightforward, not a problem at all to make and easy to understand even if you are no python Pro… (not claiming I’d be)
… As of now the largest hurdle simply is that both of us are super busy and don’t manage to have the hours to do it…
If someone wants to help out feel free to join us and just improve pySafe +open a pr 
(why it needs to be rust was something I was wondering too because I assume that all of the functionality should be way harder to create and for sure is less easy to read - but then again I thought maybe it’s just me and since they seem to have already something running they seem to be faster with it than I would have expected ; )
9 Likes
All lower layers are in Rust, implementing it in Rust is the most straight forward while at the same time we can then have a FFI to expose it for other langs. Adjusting the FFI to expose this APIs you then leave Rust devs/apps out of it. As per being all part of SCL, it could be, but if we get the most commons abstractions in this crate you shouldn’t need any of the current SLC API, only if you are trying to read/write data not following these conventions/specs is that you’d additionally need those other APIs to be also included in your app.
3 Likes
Yes, I agree about a potential API being in Rust. What I question is the rationale behind implementing the CLI in Rust. (Personally I don’t mind, but I think the answer might help understand the architecture and goals.)
Perhaps I am wrongfully making a distinction between the API and CLI? Are these implied to be in the same single Rust crate? (Whereby the CLI closely mirrors the API calls so that the CLI is merely passing the command line arguments into the API functions?)
2 Likes
It is just easier for us and will allow a static binary as well. It could be in any language really, but rust is a good candidate here.
7 Likes
This is where we want to be, CLI cmds is just the UI, it has an API which maps hopefully 1-to-1 with what cmds exposed, then that internal API becomes published and can be used by other Rust apps, FFI very thin layer. E.g. if we have $ safe wallet transfer ... and safe wallet balance ... the API can hopefully be wallet_transfer(...) and wallet_balance(...), and so on for all cmds and sub-cmds
3 Likes
I don’t want to make another account on the dev side to reply there. But I really like @bzee’s point. i.e., “All the acronyms in the poll sound very generic. Why not just extend what is already known — prefix DNS with SAFE: SDNS.”
It would make it easy for new entrants to quickly understand what it is. I was going to say dDNS, with d for decentralized, but that too would be generic. I like SDNS.
13 Likes
Something with low priority (maybe for other people to do later), but that is what I think of: for Linux one could reduce the characters to type if e.g. it could be made that symlink ‘scat’ to the ‘safe’ cmdline tool is translated the ‘safe cat’ by the safe cmdline tool.
You could get the same effect with a bash alias however.
From example from https://busybox.net/FAQ.html:
mkdir bbdir
for i in $(busybox --list)
do
ln -s busybox bbdir/$i
done
3 Likes