Welcome.default page perhaps could suggest which network it’s connected to?.. that it is connected and also perhaps network name.version might useful in the case there any many testnets.
Ok I’m having problems navigating to other pages after successfully having visited one.
I.e. typing a new address but the new page is not loading.
Is it just me? How can I troubleshoot?
Edit: on shared vault…I believe? I have the autenticator running, connected to the share vault, but as @davidpbrown pointed out, no way to know which vault the browser is connected to, and the Autenticator doesn’t show any authorisation
I remember previously we used to have the network name in the connection info but not sure if that’s available with the new vault setup. I’ll check that and maybe will see if I can do something about that.
The active vault on the
choose a vault page shows a check on the vault which is currently being used. I know, it’s not the best way but I think we can improve.
Autenticator doesn’t show any authorisation
Do you mean in the registered app list?
Just to be sure about the vault you can check the vault list and if the browser is already authenticated then you can use the re-authenticate option from the bottom menu.
I’m not sure what maybe the reason. It’ll be great if you can simply post a GIF or small video here to demo the issue.
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.
Yes, this was the same for me too.
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