After reading the Safe Networks 2021 Primer, I convince to start develop on the network. I have setup the testnet from the safe_networks repository with the help of @bzee and I have also tried interacting with the network using the safe cli.
While designing the user flow for the app, I discovered that the use of a separate app Safe Authenticator to authorise access to their data on my app will not be that of a pleasant experience. This might lead to a user who do not understand the benefit of using the Safe Authenticator total abandon my app before even trying it out.
I will like to develop an app that is highly user friendly, where the user can accomplish all task on a single app. This will require me to implement a custom authenticator in my app that allows users to create a safe account, get authorisation request and more.
I need help with how to implement a custom Safe Authenticator in Rust. I need directions to the right API to use and if possible a guide on best approach to implementing my custom authenticator.
At the moment authentication technically isn’t much more than a keypair. Currently, there isn’t much focus yet on the UX side of things regarding apps and authentication.
At the moment, I would suggest skipping the authentication part until more becomes clear on how the ecosystem will look. It used to be that the authenticator was a daemon that had an IPC interface and allowed users to manage permissions to apps. If you make a custom authenticator, it wouldn’t have the same trust anyway as an official authenticator. You might as well right away accept the credentials of the user. If you were a bad actor, you could expose those credentials, so it’s up to the user to trust your app with their credentials.
If I may ask, where did you read about the authenticator?
I understand the importance of an independent authenticator, it’s use will require me as an app developer to invest time and educational resources to educate users on how and why to use the Safe authenticator before they can interact with my app.
I think your concern is understandable but may not be justified. Users will come to Safe Network by various routes, but almost all will need to use the Safe Network App (SNApp) / Mobile Authenticator to manage authentication, data sharing and access permissions, and app permissions. So it will be a standard feature on all devices of SN users which they will quickly be familiar with.
When an app needs access to something, SNapp / Authenticator will be the UI which the user sees and interacts with, so I think it will be unnecessary and counter productive for you to replicate some of its functionality just for your app.
Better for you to introduce SNapp / Authenticator to the few users of your so who don’t know about it yet, and to benefit from the familiarity many will already have with SNapp before they come to your app. Like the permissions UI on Android, SNapp will be familiar to all and apps which bypass out will seem out of step.
Agreed. In a world where Safe is successful, a Safe account will mean the world to someone. Entering the credentials to your Safe will be something someone doesn’t do lightly. The authenticator should probably be a single program made by MaidSafe, that the user knows and trusts fully. An educated user will not trust any third-party authenticator, or recognize that an app tries to bypass the authenticator by accepting the credentials in-app. Entering credentials in multiple places either causes user-fatigue or a scenario where only technically inclined users will know how to navigate the landscape in a secure and safe way.
I respect, appreciate and thank the MaidSafe team for the vision and the work they are putting in to make a safe internet. But I will ask the team to forgive my curious thoughts and opinions on having a single safe network app by a single team.
I believe having a universal safe network app doesn’t promote diversity, competition and flexibility. The idea of allowing a single safe network app for the entire network raise questions like:
What happens when there are other developers who can design and engineer an open sourced and secure safe network app with the same functionalities, a better or a customised user experience and a better performance?
Is it not a point-of-failure if the MaidSafe team is attacked or engineers from the team decides to go rogue?
These and a couple of other reasons are why there will be a need for custom Safe Network Apps with a touch of uniqueness. There is a need to understand that the centralisation of functionalities presents a higher risk and will likely lead to road blocks as humans are highly dynamic in taste and will always yearn for peculiarities.
I believe we could have multiple secure Safe Network Apps with unique features and experiences just as MetaMask, and Exodus are all wallets used in signing Etherum transactions.
We could and in time I think that’s a good thing (like F-Droid et al for phone app stores) but we shouldn’t encourage developers to put authentication into every app, and users need to be educated about the importance of a trusted authentication app, which in the early days will be from MaidSafe (and always open source).
Sorry if I gave the wrong impression. Besides that I am not part of MaidSafe, the view I gave wasn’t supposed to be the ultimate, only and lasting truth.
Your post gave me the impression you wanted to build the authenticator as part of your app, which I don’t quite see fit for the reasons I mentioned. But yes, I take back my wording that it “probably should be single program made by MaidSafe.” I would agree with @happybeing that it might apply in the foreseeable future though. If MaidSafe makes an authenticator that is as solid as, say, Electrum, then I don’t see a lot of reasons for many competing authenticators.
The sn_api repository should have been archived. All development is now found in the safe_network` repository. The current state of the authenticator is ‘unimplemented’.
What you have read isn’t outdated per se though. It’s just that currently all efforts are directed at getting the APIs to work. Hopefully we will see more attention coming to the UX/app story this year. I think my advice from my first reply is relevant here: