I’m migrating code to the APIs in SAFE Browser 0.15 and have solid-filemanager > solid-auth-client > SafenetworkJS authorising with the CLI auth … woohoo!
However, even with the ‘Toggle Experiments’ enabled (and window.safeExperimentsEnabled returning true) I’m not able to see the experimental APIs.
I assume this is expected? May be worth disabling the ‘toggle’ in the Browser until they are exposed and/or not allowing the flag to be true.
True. There are no experimental APIs at the moment. Just those available through the window.Safe object.
Could well be worth turning off that functionality for now aye. I’ll see about this in an upcoming PR hopefully 
I was experimenting with window.Safe last week, but noticed it was synchronous (blocking). Is it meant to be that way, @joshuef? Can I solve this by wrapping these into Promises or will that still block my JavaScript code?
Also there doesn’t appear to be a return value from safe.connect() so no way to know if it succeeds.
I was assuming that this is all just because the APIs are not intended for use and made available for internal testing more than anything. So if that’s the case confirmation is all that’s needed at this point, or do Maidsafe want issues raised for this kind of thing?
That’s the questions to ask! I assumed — wrongly now I think — the current basic API is how this will work. I don’t want to take valuable time away from the developers to answer irrelevant questions! 
@bzee @happybeing thus far this is a straight up port from rust via Neon. We haven’t given much consideration into what you’re bringing up so this is for sure useful.
I think a connect response is something we’ll need at the API level anyway (that should therefore go in the safe-cli repo at the moment, @happybeing ).
Re: promises. I think a part of this is dues to the API being partly sync. Though we hand off to safe-client-libs which does some async operations, though this is not fully translated to the API as yet (@bochaco correct me if i’m wrong there).
@bzee just been reading around this in neon. Looks like they’ll be offering first class promise support at some point. Which is nice. Meantime, you should be able to wrap them in promises, I imagine. Though I have not attempted this yet.
Thus far our testing in browser and use was limited to ensuring things were going well w/ Neon and integration with the new APIs themselves. So having folk playing around and finding problems in this is great. So please do raise issues. It’s all invaluable, especially at this early state!
Thanks chaps!
I’m also not an expert on this matter. Threading is complex. I would expect this to work though.
I’ve used Task for this (https://neon-bindings.com/docs/async#promises) previously. But, that got a little complex for as the Task mechanism of Neon seems to have certain assumptions in how it handles threading. I think I got into a problem where when I wanted to use Task I needed to do some inter-thread communication. I can’t remember the details.
So, if making the functions synchronous and wrapping them on the JS side is feasible, then I think that’s actually a lean solution.
Good to know your experience there
I’ll add this as an issue to safe-nodejs so we can keep track, i’m defiitely keen for as many things to be promisey as we can have
The only thing to add from me is that I would expect the connect to throw an error in JS if something went wrong, we don’t need to return anything if my assumption is correct, so a try/catch would be the way to check this on JS? have you tried that @happybeing?
I don’t think I’ve seen connect throw any errors, but then maybe it has always connected! 
I’ll get back to you.
Regardless I think we will need a way to check connection status and be notified if the connection is lost.
I’m finding that the safe_auth CLI is fairly easy to screw up in various ways (error exit, or hanging browser auth request) and that I can get the Browser API to hang. The underlying cause might be when an error is thrown in my browser code, but this shouldn’t cause safe_auth to crash or become unresponsive! This is a bit of a pain because while debugging I’m generally throwing errors a lot, so much restarting of browser and safe_auth.
Is there a way to pass credentials to safe_auth (it’s not in the --help usage)?
Yes, we haven’t put effort in stabilising the safe-auth cli too much due to our current plans to get all cmds merged into safe CLI.
Not sure what you mean and/or trying to achieve here, if you mean connect form an app with credentials? if so, you can hard-code them i guess and pass it to connect ?
I mean a way to pass secret and password to the safe_auth CLI to save copying and pasting every time I start it.
Another method for passing secret/password involves using the environment variables
SAFE_AUTH_SECRETandSAFE_AUTH_PASSWORD.
It’s possible (though not secure) to use a simple json file to pass
secretandpasswordto the auth CLI, and so avoid having to manually input both.