New Release: SAFE Authenticator v0.2.0 & SAFE Mobile browser v0.3.0

It’s not available anymore. When removal of quic-p2p certificates was announced last week, I proposed this:

But David’s response is not very encouraging:


The network name was for specified test networks to be recodnised as that. It was a cheap way to kill old networks and prevent old clients from new networks. We should not work like that at all and use correctly versioned messages and API’s etc. Hopefully backward compatible as well.

There is no name of the network,as such, it does not make sense. If folk wanted different networks then they should provide different bootstraps. That’s how it is designed to work. For old clients on new networks then it has to be API version.


I don’t agree that it doesn’t make sense. For example each of these networks could have a name:

This would useful for the user to check that he is connected to the right network.

A network name would allow to check that the bootstrap configuration is correct.


Those are vaults. There will also be testnets, but they won’t have names and will be taken down. It tests a critical feature as well. When you do connect to SAFE you want to know it is SAFE and not an imposter or some dude flung you a config saying so.

So what needs to happen is your client knows genesis and hopefully more past that of the section chain. You will provide that hash to the network and it must be able to provide you with the section authority from that point onward. This has been missing and will continue to be missing if we take insecure shortcuts.

I see what you want, but I think we need to do it differently (correctly, without being brazen, if you see what I mean?)


Also If someone makes a network whether for testing or for internal use, then at some stage there is a chance that they make a routing change to their network structure and their internal network (say a large business of 20,000 machines/nodes) is now allowing safe packets onto the Internet. Maybe someone grabs the global network bootstrap nodes and adds them to the internal network boot strap nodes.

Now we have what is either an internal network or a large test network trying to interact with the SAFE global network. And nothing to differentiate the 2 networks.

At a minimum there will be confusion and at worse there will be a large increase in the coins that can be transacted because the internal network’s coins can now be transacted on the SAFE network.


Anybody else unable to get sound at safe://safe-blues on the mobile browser?
Both tracks greyed out…

EDIT: It Just Works on the desktop browser.


Ok I’ll try to reproduce when I get a chance


Will try that and if it’s showing the same behaviour.

1 Like

Yes, this was the same for me too.


Hey @Traktion, @Southside

I just tested this and it seems the website is working fine on iOS devices but not on the Android. After some more debugging, I was able to find the cause. It seems when ww updated the code from the older APIs to new ones, I missed some corner cases related to audio/video streaming. I’ll look into this and I hope to have this fixed in the next release.


I gave it a try after some code change and it’s working now. Though it needs much work to handle all the cases and scenarios (like streaming from a random time interval and supporting bigger audio files.


I’ve updated the OP to make it clear that you only need to register for the Azure App Center iOS testing if you haven’t already registered for the previous app versions testing. If you were already registered then App Center should have emailed you to inform of the new versions of the apps being released.

Have received a few form submissions over the last couple of days from emails which were already added.


Great to see such a quick turn around! Much appreciated!


Sat here not recalling password but surprised at error message from authentication one moment and the more usual wrong password the next. Possibly the difference is the username didnt exist first attempt and needs a message for that.


Just replicated this and it does indeed give you a different error depending on whether you have typed a correct or incorrect Passphrase - if I enter a valid Passphrase but an invalid Password I get the error “Incorrect Password”, but if I enter an invalid Passphrase and a valid Password I get the “…packet does not exist” error from your screenshot above

I would argue that the error should not specifically say what is incorrect in a user’s login attempt as it’s potentially identifying that someone uses a particular Passphrase that I accidentally typed. IMO it should be a generic “Details not found, please try again” type msg.

Will log it in GitHub and get some opinions on it - any1 that disagrees with that feel free to shout out :slightly_smiling_face:


Hi all, a little pre-dev update treat for you - today we have released a new patch version of both the mobile Authenticator (v0.2.1) and mobile Browser (v0.3.1).

We tackled some of the simpler issues that we came across after the recent patch version releases a couple of weeks ago, most of which were flagged by people in the thread above. For example, on the Authenticator we have redesigned the “Add a vault” page, and made the login failure message more generic so as not to identify Passphrases, while on the Browser we have fixed an authenticate loop on iOS, and added support logic for audio streaming on Android.

Full change logs of what went into these releases can be found here and here.

See the OP for details on installing and how to connect your mobile device to a vault.

There are of course other outstanding issues and enhancements that we will continue to work on, but this seemed like a good time to share our progress so far.

As always, all feedback is both welcome and appreciated :smiley:


Great news team! I look forward to trying these out later. I looked at the change is but it is difficult to tell from those which issues from the thread remain to be fixed (or to some extent which have been fixed). That’s just a comment really, I’m not asking for a list etc.

I think it’s a general issue with change logs - I often look at them (not just in this project, I think it’s a general issue) and find they rarely answer the question I’m asking, which is usually has X been fixed? or what new features have been added!


Yeah that’s a fair comment @happybeing, I think unless you have been actively working in development on the project those changelogs probably don’t actually mean an awful to you.

It may be clearer going by the project boards rather than the changelogs, I’ll link them below. You can scroll to the right side of the board and all the issues/PRs that have been merged, and so are live as of today, are in the Done column. Also, everything that went into this release has the relevant label added to it, i.e. v0.2.1 label for the Authenticator and the v0.3.1 label for the browser:

This also allows you to click into the issues or PRs to see more details.


Thanks @StephenC that’s very helpful.


Disclaimer: thinking like a user…

  1. Why is the vault file in the authenticator?.. I want to browse this new world free of all incumbrance!

  2. Once authenticated… could do with switch back option to most common app like browser… switching back and forward add extra effort.

  3. Browser suggests nice a big Error not connected but does not prompt for what needs to occur… refer to point one above… need to know setup required in authenticator and rtfm is a bore!

  4. Then two different errors at the same point, trying immediately after each other …