for mock, right? …,…,.,
1 Like
Yep. All I’ve done is create an account. I haven’t tried with any of the example applications yet. Turning in now cos it’s late. Night all. 
3 Likes
great work, digging into it now.
And I forgot to mention how awesome it is that these 3 new apps from MaidSafe seem to have just sprang out of the blue as working with Authenticator. (unless I just wasnt paying attention to GH updates 
)
Great work all around though, this is definitely an awesome update. I’ll make a post on the MaidSafe Asia forums and those guys will be very very pleased 
5 Likes
And it was a pleasure to meet you to Will. Always great to put faces to names and especially when they turn out to be very decent honest folks. Now you have been in “the shire” and see how we live 
simple and honest, it’s not too bad at all though.
12 Likes
and great weather too! Glad to hear that it’s like this all year round!
But definitely a great town, everyone’s very warm and nice. Miss that in the big cities. Nothing like it
unless they put tomatoes on your sandwich! then all hell breaks loose haha!
6 Likes
Great stuff, a far more refined experience. Maidsafe delivers again. 
It’s very blue… but that’s personal taste I guess.
Love it though, great work.
10 Likes
just a thought I’ve had on authenticator, will there be some type of check so that people can be sure they’re using the real one?
I guess they can verify with the URL that it’s correct. But then again the masses might forget that “oh, safe-auth://home” is the only truly correct one. Those inputs might hold your entire savings for some people eventually and just wondering if there’s some sort of way to sign something with a key, not sure.
This might just be a general problem all browsers face though. Phishing site attacks. But at least if we’re releasing the browser, maybe a built-in button that takes you right to it. Unless that already exists; haven’t cracked it open yet.
And I might not be articulating the issue right, had my first whiskey tonight with @anon86652309 and @ustulation (very very friendly guys, we could have talked all night) and might not be at my sharpest right now haha
6 Likes
Blue is known as a trusting colour. It is often used for uniforms when trust in the person wearing it is needed.
8 Likes
+1
My ideal scenario would be having the option of plugging in a hardware wallet and confirming login and SAFEcoin transactions on the hardware device. No passwords or pins required to login, apart what is already on the hardware device. Then there is no concern of key loggers etc, especially if logging in from public computers like at a library.
7 Likes
could have something like
- Run App stored on the USB drive. (1/2 of USB device)
- App sends request for a “challenge” login
- group sends a new public key
- App sends the group’s public key to USB H/W (running its own program obviously)
- USB H/W encodes the credentials using the group’s public key
- App reads the (encoded) login info from USB H/W and sends it to the group
- Group decodes the credentials using its private key and does normal login procedure
It could be possible that if the H/W is standised then the authenticator could know how to talk to it thus saving the step of running the App from the USB stick
Also note that the USB hardware is a combination of USB Drive (to store App etc) and USB H/W processor which handles storing the credentials securely.
As to hardware SAFEcoin wallet, that begs the question - Why? SAFE will already store your wallet as securely as possible and since the coins exist on the SAFE network (always) then what are you going to store in the wallet anyhow? Just coin addresses and maybe a copy of the key pairs for BTC/alt blockchains. Not strickly a wallet.
So I suggest the H/W side of the USB device stores your credentials and a copy of the key-pairs you may need elsewhere from SAFE. Remember your SAFE credentials gives you access to super secure wallets and needed key pairs.
6 Likes
I know this is a topic that has been beaten to death but I simply use the same value for both secret and password. IMO just a single password field should be used to authenticate with the safe network. I’m sure most users will use the same password and secret.
The safe network will only store the public key in the owner field. Actually signing transactions will happen offline (or at least, using private keys stored somewhere other than the safe network, eg locally or in a hardware module). So I do think the safe network could benefit from a hardware module for sign-in and signatures etc to protect the private keys, but I also think it’s too soon to be developing this since the api should be stable before investing that amount of work.
8 Likes
@happybeing safe-js isnt being maintained for the new APIs (or wasn’t planned to be). As I understand it there will be a new js lib that achieves the same aims (I think what is being used in the new demo apps will be abstracted).
@frabrunelle is that correct?
If not, I may well jump back in. It’s a good learning experience 
Gonna scope out the latest stuff now. Thanks @maidsafe, good stuff as ever!
7 Likes
The documentation for the safe_app_nodejs is available here
The DOM APIs are exposed too and the APIs will be starting with the safe prefix. (window.safeApp). We don’t have the documentation published for the DOM APIs yet, however the APIs should be one to one mapped to what is exposed in the nodejs. Will keep a note to publish the documentation for the same as soon as possible.
You can use the mark_down_editor example for reference. The store.js file makes the calls to the network using the DOM API.
13 Likes
Thanks @maidsafe for the great update.
You guys are rockstars with this
imho UI and UX @Shona is doing a super job. [quote=“JPL, post:21, topic:13527”]
SAFE Browser with authenticator compiled for Linux here:
[/quote]
Thanks
6 Likes
Thanks Krishna. Do you mean that by following the safe-nodejs docs, it is possible to use the DOM API now?
Fingers crossed Not sure when I’ll get time but it will be good to poke around and start to get to know this.
Thanks @joshuef, I appear to have been confused again
2 Likes
Do I need to grab the Authenticator myself somewhere before I build it??
3 Install the dependencies.
cd safe_browser npm install
4 Build the SAFE Authenticator plugin.
$ npm run pack-authenticator
I get stuck in step 4 on Windows10/64
4 Likes
I got the same. I value my sanity too much to continue.
Good luck
3 Likes
In Linux I also got the same thing but @frabrunelle helped me out
Type the command git checkout dev and try again. Also you’ll need Rust 1.16.0 if you don’t already have it.
6 Likes
I understand the desire to simplify, always that tension between convenience and security I guess: ). But on the subject of authentication, we do need 2 inputs though, 1 input reflects the location of the network data and the other is used for encryption/decryption on the client.
2 Likes
I respectfully disagree.
A single source of entropy (ie a password) can (and should) be used to source both these things.
The user makes no connection between ‘password + secret’ == ‘location + encryption key’ … so I think assuming the entropy must appear to the user as two fields because it’s used for two purposes is a mistake.
The user sees the login form only as a way to authenticate. This is a single action (to the user) and should be represented by a single field in the form. Whether that field is used for one or two or ten purposes by the network is not important to the user (ie it doesn’t really inform or alter the values they use).
6 Likes