New Release: Vault Phase 1 (real vault)

Are you building a target for Windows or Linux?

What’s the estimate on a phase 2 release?

[edit]

Two more months it is.

Hi all, an updated vault_connection_info.config file has been uploaded to our GitHub release here.

If you want to use the shared vault please ensure you download this latest version and save it in the appropriate location for your operating system. See the OP for full details on how to use the shared vault.

9 Likes

Once BLS, Node Ageing and Vaults 2 are done. You can follow progress on the Project Plan

3 Likes

Sorry I didn’t have time to test it, but now I can confirm these versions are working. For anyone interested the command to checkout a tagged version is:

  • For safe_vault: git checkout tags/0.19.2 -b test
  • For safe-authenticator-cli: git checkout tags/0.3.0 -b test

Only concern is that current versions of safe_vault and safe-authenticator-cli are still not working together.

6 Likes

On Linux, more precisely Ubuntu 18.04.

2 Likes

Do applications like chat work with the shared vault by the way?

Assuming you mean web based, there’s not enough of the API exposed in the browser yet to do much more than create and view files/containers, create and view NRS names - which is enough for me to have a read only version of Solid Filemanager working (safe://solid-filemanager on the shared vault, as well as alpha 2).

Using the Rust APIs everything you’d need is there.

So we’re waiting on the ffi being expanded for the different languages, and JavaScript in the browser.

3 Likes

Are you able to login with solid-filemanager using the shared vault? The login button is unresponsive for me (Ubuntu 19.4).

It does work on Ubuntu although I find the authenticator losses contact with the browser quite easily, so try restarting one or both.

You don’t need to be logged in to use the app though, if you type a valid URI such as safe://dweb or safe://solid-filemanager you can browse the filesystem by clicking “Open Directory”.

1 Like

Hi all, another updated vault_connection_info.config file has been uploaded to our GitHub release here.

If you want to use the shared vault please ensure you download this latest version and save it in the appropriate location for your operating system. See the OP for full details on how to use the shared vault.

8 Likes

Is the shared vault anything special or is just a designated vault as “shared”?
If the latter could I declare my local vault as a “shared vault”?

3 Likes

Just us calling a single vault the whole network. So just a test for now. Real network you will connect to many vaults to be able to edit data etc.

6 Likes

Is it possible to do anything multiuser on this shared vault?

Email?
Chat?
Play Games?

And if so why isn’t anyone doing so already?

3 Likes

Yes, it emulates the network. New API’s etc. Folk prob don’t want to switch just in case they change much, we hope they wont. some are also being developed.

7 Likes

Have you solved this error somehow? If I try to build from scratch I get the same error on maidsafe/safe-authenticator-cli

$ git checkout 0.3.0
HEAD is now at 465e29f Merge pull request #69 from bochaco/version-change-0.3.0
$ git clean -fxd
$ cargo build
thread 'main' panicked at 'assertion failed: prev.is_none()', src/tools/cargo/src/cargo/core/resolver/context.rs:153:25
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

3 Likes

No we haven’t, you could build it with Rust v1.37, apparently if you build with Rust nightly it should also work fine. We are deprecating that project due to authd becoming ready hopefully soon, and that’s why we haven’t tried to solve it either.

7 Likes

Yes, by reverting to rust 1.37. As suggested by @bochaco you could try nightly.

1 Like

Now I am able to use latest safe_vault and safe-api with latest rust.

But there is something strange I observe on a brand new local vault and auth never launched:

$ target/debug/safe keys create --preload 1 --test-coins
New SafeKey created at: "safe://hbyyyybyq45sz4r9z6orta7bnpe6yyqiwn4jtdtsbk6sks7ux1tznxoib6"
Preloaded with 1 coins
Key pair generated:
Public Key = 81daddafa27efe81238e844d4780075682d26238d82af5956ecdf28dc4f8543e12ec03e5641249dff59f6404fb84f6bd
Secret Key = 5b5485cd647022fd818927e06ff3f454de62099d0813aafbbf7a4afc46e4441a

$ target/debug/safe keys create --preload 0.01 --pay-with 5b5485cd647022fd818927e06ff3f454de62099d0813aafbbf7a4afc46e4441a
[2019-11-17T22:08:26Z ERROR safe] safe-cli error: You need to authorise the safe CLI first with 'auth' command

I understand that the first command doesn’t need auth because no account is involved, it’s just a safe key created on the network with a balance. But shouldn’t it be the same with second command because no account is also involved, as long as the sender provides the secret key.

That seems inconsistent to me (pinging @bochaco)

Edit: first command is temporary, so the inconsistency will naturally disappear. I don’t want things changed, I just want an explaination, maybe is this related to the concept of transaction that is used in the second command and not in the first?

9 Likes

You are right @tfa, we indeed imagine being able to do many more things without being logged in an account, it’s just that CLI is not completely there yet. Another example, you should be able to cat/dog public content without logging in, but the CLI is still not allowing you, even that I think we can already make it work like that, so it’s about just implementing it in CLI (and in lower levels if it’s not available through current SCL APIs).

The accounts should be just a convenient way of keeping and retrieving your (signing / encryption) keys, but I should be able to provide the keys by other means, in fact, we should be able to sign the requests and provide them to CLI just to send it to the network, which is what we’ll need to be able to make CLI work with hardware wallets/devices (just as another example).

12 Likes