These are great - nothing like a step through for those of us who are a bit slow on the uptake. Seeing is believing. Not sure how stable the API is now, but at some stage it would be great if someone could put together vids of boilerplate JavaScript to upload and download files, grant permissions, append data etc. I’m guessing the devhub is out of date now?
The tutorials in devhub are still valid for alpha2 libs, apps and test network. As you say we should eventually have the equivalent for new APIs and data types, and we will. We yet didn’t document/show/say/comment much of the API itself (even it’s all there public on github) just so we can keep focusing on adding more supported use cases and features to them, stabilising them, and to the overall front-end foundations for exposing them, specially now that we are trying to get the bindings for JS and for webapps on the SAFE Browser. Once we get there, we will for sure start encouraging more to people to try them out and help them out with code snippets, etc.
Can you give a status update on the SAFE browser JS bindings (Dev branch I think)? And let us know as soon as you think they are ready to play with - pre alpha, unstable is fine for me and I’m ok with no support so as not to distract you. I’m keen to see how they look compared to alpha 2 even if I can’t figure out how to build on them in places.
That is very useful along with lib.rs, thanks Gabriel.
I wanted to check if the renderer app should work as I have it authorising (with an account on the shared vault) but it fails when creating “testfolder/”. All I’ve done is npm install && npm run build && npm run start
.
Browser console error is:
Creating FilesContainer...
renderer.js:21 Uncaught Error: internal error in Neon module: Failed to create FilesContainer: FilesSystemError("Couldn\'t read metadata from source path (\'testfolder/\'): No such file or directory (os error 2)")
at renderer.js:21
The view displays:
Hello World!
We are using Node.js 12.4.0, Chromium 76.0.3809.139, and Electron 6.0.7.
I knew you were lying to me
just kidding!!
That example code assumes you have a “testfolder” in the same path, so just create a “./testfolder”, or change the path in the code to some existing local path
Yes I lied, but getting so close was too much - so thanks. I’ll try harder to shut up.
no worries, that example should work fine, just reply here if you still have issues
I have it going much further but something is flaky. Tried closing it and safe_auth and re-running both several times with varying results. I’m not sure at this point if any are worth of creating issues:
One I’ve seen twice today in the safe_auth console is:
Allow authorisation? [y/N]: y
Authorisation will be allowed...
[2019-09-12T15:54:50Z ERROR safe_core::connection_manager::connection_group] Unexpected challenge, expected response (Custom("invalid value: integer `32`, expected variant index 0 <= i < 2")).
I’ve also seen renderer.js time out waiting for auth response even though I responded in good time.
Then renderer.js failed, seemed to hang after accessing “testfolder/subfolder”.
Finally it has gone much further, but still failed eventually. Here’s the debugger console output in case it helps:
Authorising application...
renderer.js:16 Connecting to the Network...
renderer.js:20 Creating FilesContainer...
renderer.js:22 FilesContainer created: Array(3)
renderer.js:26 Fetched FilesContainer content: Array(2)
renderer.js:29 Sync-ing FilesContainer...
renderer.js:32 FilesContainer synced: Array(2)
renderer.js:35 Putting PublishedImmutableData...
renderer.js:38 PublishedImmutableData put: safe://hbyyyydfwo7n7s1pk1wd8womuwt68di77kdtyunwg93gawz59czk6roy9e
renderer.js:41 Let's fetch PublishedImmutableData from safe://hbyyyydfwo7n7s1pk1wd8womuwt68di77kdtyunwg93gawz59czk6roy9e
renderer.js:43 Fetched PublishedImmutableData content: Array(18)
renderer.js:48 Let's link NRS name to safe://hnyynywra8geq6qfkf3wdogjh6awtm7btjboe71ouf9c4s4jn9raxs637kbnc
renderer.js:50 NRS Map Container created: Array(3)
renderer.js:53 Let's link subname to safe://hbyyyydfwo7n7s1pk1wd8womuwt68di77kdtyunwg93gawz59czk6roy9e
renderer.js:55 NRS Map Container updated: Array(4)
renderer.js:58 Fetch NRS Map mypubname-569
renderer.js:60 NRS Map Container fetched: Array(2)
renderer.js:63 Let's remove subname
renderer.js:65 NRS Map Container updated: Array(4)
renderer.js:68 Let's parse safe://mypubname-569
renderer.js:70 Parsed URL: true
renderer.js:73 Let's parse and resolve safe://mypubname-569
renderer.js:75 Parsed and resolved URL: true
renderer.js:78 Let's fetch content from safe://hnyynywra8geq6qfkf3wdogjh6awtm7btjboe71ouf9c4s4jn9raxs637kbnc/test.md
renderer.js:80 Uncaught Error: internal error in Neon module: Failed to fetch content: ContentError("No data found for path \"/test.md/\" on the FilesContainer at \"safe://hnyynywra8geq6qfkf3wdogjh6awtm7btjboe71ouf9c4s4jn9raxs637kbnc/test.md\"")
at renderer.js:80
I don’t need any of this fixed, just providing it in case it is of use. I’m on Ubuntu 19.04.
For info only (again I assume too early for bug reports) I tried the poc pweb browser (ie dev branch) this afternoon after @joshuef’s merge and was able to scroll back and forward through the ‘SAFE Network Forum’ test website. I then tried to create a name by typing it in the address bar. It said ‘blah’ is free, but failed when I clicked to ‘Register’. I didn’t capture the error as it is obviously very early code.
This is all looking great
I saw the error with safe_auth as well with shared vault, I think it’s a limitation in current Phase1 vault about number of client connections, so it should be solved in next iteration of vault I presume. But this is my rough high level understanding of that error from @lionel.faber explaining it me some days ago.
FYI I’m unable to safe_auth atm. Not had this before so maybe just too many connections but I’m warning in case its a DDoS. The error is:
safe_auth --daemon 41805
Secret:
Password:
[2019-09-12T16:18:53Z ERROR safe_auth] safe_auth error: Failed to log in: CoreError(Request has timed out - CoreError::RequestTimeout)
ah! just hold on, the vault is being restarted right now, more info coming in dev update
@happybeing yeh, I’ve seen a couple errors w/ timeouts there too. Need to get dug in to whats up there.
Been on packaging for the APIs today though (dunno if you noticed it took 3 years to build the browser with the current setup ? ). Anyway, almost got that licked
@Maidsafe I suggest we have a topic “Test network status” where we can be updated when there’s a known issue or maintenance blocking use of the shared vault or other public tests.
This seems to work fine:
sascha@Knut-Mint:/mnt/Data/SAFE$ ./safe_auth --daemon 41805
Secret:
Password:
Logged in the SAFE Network successfully!
Exposing service on 127.0.0.1:41805
The following application authorisation request was received:
+------------------+----------+------------------+------------------------+
| Id | Name | Vendor | Permissions requested |
+------------------+----------+------------------+------------------------+
| net.maidsafe.cli | SAFE CLI | MaidSafe.net Ltd | Own container: false |
| | | | Default containers: {} |
+------------------+----------+------------------+------------------------+
Allow authorisation? [y/N]: y
Authorisation will be allowed...
Authorisation response sent
But not this, in another window with the above running:
sascha@Knut-Mint:/mnt/Data/SAFE$ ./safe_auth --apps
Secret:
Password:
[2019-09-12T17:47:25Z ERROR safe_auth] safe_auth error: Failed to log in: CoreError(Request has timed out - CoreError::RequestTimeout)
@Sascha I’m seeing the vault rejecting the second connection, so again I presume it has to do with a limitation in this phase1 vault, not fully sure though.
As a comment, if all you are after it’s getting the list of authorised apps with --apps
you don’t need a first instance of safe_auth running, simply kill the first one and you will be getting the list of auth apps like:
$ safe_auth --apps
Secret:
Password:
Logged in the SAFE Network successfully!
+---------------------------+--------------+------------------+-------------+
| Authorised Applications | | | |
+---------------------------+--------------+------------------+-------------+
| Id | Name | Vendor | Permissions |
+---------------------------+--------------+------------------+-------------+
| net.maidsafe.safe_browser | SAFE Browser | MaidSafe.net Ltd | |
+---------------------------+--------------+------------------+-------------+
| net.maidsafe.cli | SAFE CLI | MaidSafe.net Ltd | |
+---------------------------+--------------+------------------+-------------+
Now it seem to try for longer, but after a couple of minutes I get this:
sascha@Knut-Mint:/mnt/Data/SAFE$ ./safe_auth --apps
Secret:
Password:
Logged in the SAFE Network successfully!
thread 'main' panicked at '
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! unwrap! called on Result::Err !
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
src/lib.rs:325,23 in safe_auth
Err(CoreError(Request has timed out - CoreError::RequestTimeout))
', /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/unwrap-1.2.1/src/lib.rs:67:25
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
This happens regardless of the vault running or not in the other window.
I have actually never successfully run the command:
$ safe_auth --apps
For some strange reason it just worked for the first time!
First with backtrace:
sascha@Knut-Mint:/mnt/Data/SAFE$ ./safe_auth `RUST_BACKTRACE=1` --apps
Secret:
Password:
Logged in the SAFE Network successfully!
+-------------------------+----------+------------------+-------------+
| Authorised Applications | | | |
+-------------------------+----------+------------------+-------------+
| Id | Name | Vendor | Permissions |
+-------------------------+----------+------------------+-------------+
| net.maidsafe.cli | SAFE CLI | MaidSafe.net Ltd | |
+-------------------------+----------+------------------+-------------+
And then right after without:
sascha@Knut-Mint:/mnt/Data/SAFE$ ./safe_auth --apps
Secret:
Password:
Logged in the SAFE Network successfully!
+-------------------------+----------+------------------+-------------+
| Authorised Applications | | | |
+-------------------------+----------+------------------+-------------+
| Id | Name | Vendor | Permissions |
+-------------------------+----------+------------------+-------------+
| net.maidsafe.cli | SAFE CLI | MaidSafe.net Ltd | |
+-------------------------+----------+------------------+-------------+
ah wait, perhaps you need to update your vault config file, we just notified it on the dev update as the vault was restarted just ~1hr ago, so please make sure you update it with the new version published on the Vault’s release page: https://github.com/maidsafe/safe_vault/releases/download/0.19.2/vault_connection_info.config
All assuming you are not running a local vault and trying to connect to the shared vault?
No, that’s not it.
Now it looks like
$ safe_auth --apps
is failing when I run
$ safe_auth --daemon 41805
in a different window. If no vault is running, the command works.