Right, trust me, I can see and understand your frustration, we effectively faced the same type of problems when developing the auth CLI, and this is why I believe it’s a good thing to do, to uncover any missing piece/feature, and learn/understand better how is it that the Rust API in safe client libs can be enhanced/improved.
Thus, our so far experience with auth CLI triggered some internal discussions about this specific aspect you brought up in that thread (and now), and there is already a plan to start looking at how to expose a similar type of user facing API to those you can find in FFI layer, but from the pure Rust layer. As you noticed already, the reason
there are references to personal GitHub repositories is exactly because all this. So we had the option of saying “let’s first solve those issues before sharing a PoC CLI”, or “share it so people can learn, help us in the process by testing it, providing ideas and criticism, just like we also do ourselves”.
So what I mean is that, as you correctly say, this is not finalised and there are several things to work on yet, like those you point out: documentation, Rust APIs in safe_client_libs so you could depend on them from an external crate, make it function with real network and not only mock, etc.
Now, there are also some other aspects to all this, which I believe will be a big challenge for all of us if we want to support our SAFE users:
It’s clear that as we progress in the project there will be more and more different type of applications with different type of requirements. Such requirements could simply be “have a simple UX”, and such a req could lead devs to try to create alternatives to how users log in to the network and authorise apps.
This is a big topic I’d say, and we could even start a thread for discusing this, but in summary, we have to be careful and try to work on solutions that end users can effectively trust, e.g. if every application embeds an authenticator, meaning that you have to enter your account’s secret and password in each of them, we are creating a very risky environment for users, no doubt about the bad UX due to user exhaustion.
This is why we believe we need an authenticator which can manage the credentials, and apps only connect to the network after credentials were provided by this authenticator, thus apps never get the account’s credentials but just their own and the fixed set of permissions. If having embedded authenticators in apps becomes the norm rather than the exception, it’ll become too risky to use any application out there.
We have to work on having solutions that support our users (good UX) and applications (good integration protocols, we have now only one which is the system URI protocol) so they can manage credentials and permissions solely from a very well trusted authenticator.