New Release: Vault Phase 1 (real vault)

[Nigel]

@bochaco

simply creating it on a Unpublished AppendOnlyData, the resolver then works just the same

That’s neat! I can think of a good use case for this. Can those be accessed by others than yourself if you share the data map? Even if not that’s still neat regardless. Also since it’s unpublished does that mean there could be many of the same NRS url on numerous accounts but no conflict?

[Traktion]

@happybeing

EDIT: it is also feasible to create your own public name for websites you visit to make your own personal, rock solid, available everywhere bookmarking system! I think there’s an app in that

Yes, great point! Like pet names, I believe. Very flexible system!

[drehb]

@Traktion

Like pet names, I believe.

Hmm, a little bit. If it was done as subnames under something you already own, then yes the same. If you make a new name like ‘safe://myfavsite’ for your bookmark, then it isn’t like pet names because only one person can use that pet name vs everyone being able to use that name (possibly with different linkages) in a pet name system.

[bochaco]

@Nigel

Can those be accessed by others than yourself if you share the data map?

Once we have the tools/APIs to start sharing unpublished data using the BLS keys it should be possible, just like sharing any other data with a group of users. It sounds to me this could be how an Intranet would be implemented in a corporation, just having shared unpublished NRS names and sites where the BLS share secrets are used by all members and systems of the corporation.

@Nigel

Also since it’s unpublished does that mean there could be many of the same NRS url on numerous accounts but no conflict?

That’s not correct, published and unpublished AppendOnlyData share the same XOR name address space, thus there will be conflicts, although perhaps using different type tags we could have more name address spaces.

[SmoothOperatorGR]

why not then have personal urls? one way of doing this is:

have safe://url/ for public url and have something like safex://personal-url/ for urls that are yours and are only working when you have “logged in” with your account secret and passphrase

[dirvine]

Or categorising in a linked data world. i.e. being able to re-lable urls (data really) based on different views. So when in medical view then something like “new brain function found” could be indexed in neurology and in AI view, indexed in neuroevolution or similar. So be able to have urls like data where regardless of the owners tagging you can tag for your use case (tag == new url)

[Sonder]

This sounds like amazing progress.

Can I ask if the test Safecoin is divisible like Bitcoin? And if not, will it be?

[Traktion]

@drehb

@Traktion

Like pet names, I believe.

Hmm, a little bit. If it was done as subnames under something you already own, then yes the same. If you make a new name like ‘safe://myfavsite’ for your bookmark, then it isn’t like pet names because only one person can use that pet name vs everyone being able to use that name (possibly with different linkages) in a pet name system.

Thinking about it, host file entries for ip addresses on clear net are a similar concept - a local/personal way to resolve names to IPs.

Perhaps the client libs should lookup and local name/XORURL maps prior to looking up global maps? Then we have useful, unique, personal pet names.

[Traktion]

@Sonder

This sounds like amazing progress.

Can I ask if the test Safecoin is divisible like Bitcoin? And if not, will it be?

Yes - look at my transfers above for examples.

[Sonder]

Ok, yeah. Sorry missed that. Wicked! Just what I was hoping for. Thanks.

[Mindphreaker]

Congratulation to the whole team for this great milestone! Just had some time to test the new cli commands with test safecoin and it feels great!

Just two things that quickly came to my mind while playing around:

1. I find the parameter sorting for transfer somehow unintuitive. I understand that there might be a reason for it as there could be something like a default and therefore it makes sense for to come first? I think it would be easier to read if we specify it explicitly with mandatory options --from --to

2. The documentation states that for a transfer you can use either a wallet or a SafeKey address. However if you look at the output below (where I try to address a SafeKey address) I’m somehow confused by the error message:

“[2019-08-31T19:21:39Z ERROR safe] safe_cli error: [Error] InvalidInput - The ‘from_url’ URL doesn’t target a SafeKey or Wallet, it is: Raw (SafeKey)”

Is it a SafeKey or not? ^^

Full console output:

PS C:\Users\Alexander\Desktop\safe> .\safe wallet create --preload 13.37 --test-coins Wallet created at: “safe://hnyybyqt5ubtmaxpi37tcwtxf5w7y431yjsdakas6ba7r8gpio11on8fi1y9e”
New SafeKey created at: “safe://hbyyyybgy1oyrssehd7on9y17m179jakkseamcux7cmspcauom1gx75ugb”
Preloaded with 13.37 coins
Key pair generated:
Public Key = 981280096b2383ec05f04bab977e9c29564616c9bfac5d9acc4e0b919fddccc15415ddc9e10cda2ddbec0c8d36814f76
Secret Key = c8843084f30f444e26fe09fecb047c3e63d7460d34c2530c5ae1eb824b91c332
PS C:\Users\Alexander\Desktop\safe> .\safe wallet transfer 0.37 safe://hnyybyqt5ubtmaxpi37tcwtxf5w7y431yjsdakas6ba7r8gpio11on8fi1y9e safe://hnyybyqt5ubtmaxpi37tcwtxf5w7y431yjsdakas6ba7r8gpio11on8fi1y9e Success. TX_ID: 7386616574070973832
PS C:\Users\Alexander\Desktop\safe> .\safe wallet transfer 0.13 safe://hbyyyybgy1oyrssehd7on9y17m179jakkseamcux7cmspcauom1gx75ugb safe://hbyyyybgy1oyrssehd7on9y17m179jakkseamcux7cmspcauom1gx75ugb [2019-08-31T19:21:39Z ERROR safe] safe_cli error: [Error] InvalidInput - The ‘from_url’ URL doesn’t target a SafeKey or Wallet, it is: Raw (SafeKey)

[Traktion]

safe wallet transfer 0.000012345 safe://hbyyyybgy1oyrssehd7on9y17m179jakkseamcux7cmspcauom1gx75ugb safe://wallet@lazydog
Success. TX_ID: 5419180019885489537

[Mindphreaker]

Interesting… As a target it seems to work however in my example above it seems that there is an issue when using the SafeKey as a source. @bochaco ?

[bochaco]

Hey @Mindphreaker, yeah, it’s a bug (in the help menu and error msg at this point, I just checked the code and we definitely don’t support a SafeKey as source but only a Wallet). I’ll be raising it to either support that (which I’d prefer) or change the msg. Thanks a lot!

Regarding the wallet transfer args order, some similar discussions and info is here, but overall you are thinking in similar terms of those previous comments and discussions, we just didn’t address this issue yet.

[Mindphreaker]

Cool, glad that I could help. IMHO it would even make sense to only allow SafeKey as a transfer reference. It could reduce confusion between Wallet / SafeKey adresses and it would be clear which addresses to use. The wallet would then really just be the container of the addresses.

Thanks for pointing me to the discussion regarding parameters. Sounds like others had the same ideas.

[bochaco]

TBH I’m imagining that to have both use cases supported while keeping consistency, perhaps introducing a safe keys transfer which accepts only a SafeKey as source/from, and accepts the destination to be either SafeKey or Wallet, could be clean and make sense. Both wallet transfer and keys transfer would work analogously with almost the same type of args. Although originally I imagined that the safe keys cmd would be only for creation of SafeKeys.

[Sonder]

Another question:

Does Safecoin wallets use public / private keys? Will it be relatively easy for a Trezor to add a Safecoin wallet?

[dirvine]

The wallet/address is a BLS public/private keypair. Many projects are looking at using the same as it allows easy threshold (multisig). The wallet (like bitcoin etc.) is the thing that holds all of your addresses. So the keypair that manages your safecoin is BLS, so it should be able to be integrated with hardware wallets.

[chriso]

@mav

Self update is the same feature for both apps and makes sense to run them in the same way, ie both as flags, not one as a flag and one as a subcommand. Please, don’t make me think.

I understand the features of each app have differing amounts of complexity and ui but the self update feature can and should be consistent, like --help or --output which is common to both.

Sure, I agree they should be consistent. I was just pointing out there was a good reason they weren’t. We have a finite amount of resources and didn’t have the time to refactor the safe_auth code to bring the 2 interfaces in line. As @joshuef says, perhaps we may even have safe_auth merged in safe at some point.

[chriso]

@mav I just need to check the self update crate is compatible with zips, but otherwise should be able to change to zip rather than tar for the next release.

@draw Good point - can also add a strip into the build process.