The problem is that we don’t know what “default” refers to (I thought it was argument default value!). As it means “default name”, just say that. I would also remove the “but” that doesn’t help understanding. Here is my proposal (very close to your original phrasing):
The default name is set using a direct link to the final destination that
was provided with `--link`, rather than a link to the sub name being created
(which is the default behaviour if this flag is not passed)
I also propose to remove -t short form because we don’t know what it stands for and just keep --direct long form which is clearer.
Yes, with what we currently have (phase 1) every vault is like a separate network. They’re starting to work on networking them now (phase 2), which involves using PARSEC to reach consensus between vaults on network activities.
I’m a bit confused about the shared vault.
I have put vault_connection_info.config in /home/folaht/.config/safe_vault/ which turned the requestTimeout error into this:
You may wanna avoid using the &, I’m not sure if it’ll work correctly to allow an auth req when prompted, it’s probably better to just run it with $ ./safe_auth --daemon 41805 and use another console for the $ safe CLI commands
Yes it is an issue, if we deamonise properly then we cannot have stdio output. Perhaps an interactive session is best. So split screen, on top an interactive safe_auth running and the bottom half the CLI running then we can perhaps create some stunning graphic output as well as screen prompts.
All great fun an brilliant way to show what is happening. I suspect the interactive part though will keep showing a QR code for the wallet of @bochaco and @joshuef just you know, as examples of how to donate
Yes, I think we are fairly convinced we need to properly demonise it, and also merge safe_auth CLI commands into safe_cli, this will make things much simpler to use and to maintain. Let’s see where we get to in the next few days with this.
The first thing I’ve noticed is that for some reason my site is located at safe://site/site instead of just site.
One complaint, the client may be able to handle nón-Êǹglîşh lætŧùrş, but the browser does not.
I’m creating a phonemic conscript and regular latin, especially the English version, has proven to be insufficient.
@folaht can you give us some examples of URLs that are not working for you please.
Also re: site/site you’re missing a trailing / on the folder in your upload command. (This works much like rsync or cp at the moment, though we’re looking at perhaps changing that as it’s not always the most convenient…)
I think the only problem is to have called the flag --daemon. Something like --wait-for-auth-req would be clearer and wouldn’t encourage people to launch it in the background.
If I see option daemon I think it is meant for the process to run, started by the init or systemd process on Linux, or roughly the same as started in the background (& behind). Like for example
Yes, and it was the intention back then when we started with safe_auth CLI, we wanted to this be a daemon eventually but didn’t invest the effort on that thing, now the moment has arrived . Note this also will give us some additional cool features apart from what it’s being discussed here, e.g. any Authenticator UI/GUI could be connected to this daemon, so you could interact with it using the CLI, and 5mins later you can do it with SNAPP GUI, while still logged in with same account all the time (you could be allowing auth reqs from the CLI or from SNAPP).
. Note this also will give us some additional cool features apart from what it’s being discussed here, e.g. any Authenticator UI/GUI could be connected to this daemon, so you could interact with it using the CLI, and 5mins later you can do it with SNAPP GUI, while still logged in with same account all the time (you could be allowing auth reqs from the CLI or from SNAPP).