SafeKeys - is there a better name?

Are SafeKeys independent from a ‘Safe’? Because I can create them without a running auth.
Also, should I be able to transfer coins without a running and unlocked auth? (When I tested this, I got no response, might be one of the other ‘timeouts’ happening on this network).

Btw, why is a SafeKey called ‘SafeKey’? I find this term quite confusing for what it does, and also because there are already other terms with key in it. The less words with ‘key’ in it, the better I think for the average user.
I still prefer a word like ‘locker’ for it.


I suspect that after .safe\cli\credentials file is created, sn_authd is not needed anymore for CLI operation.

1 Like

Unless you are sure you are entering the correct passphrase and password, the same you used when you did $ safe auth create --test-coins, then the only explanation I can find is some other instance of the “no data found” issue some people are facing due to some chunks not being found and/or lost. If you can still reproduce it, please take look at the authd log at ~/.safe/authd/logs/sn_authd.log and see if you get one of these errors.

Yes, and yes, so try again, you don’t need authd to create SafeKeys with testcoins and transfer coins among them.

There has been a few attempts to rename this to something else, I think we didn’t find better name yet, this is supposed to be where you have a coin’s balance, some people said “wallet” but we also have the Wallet abstraction which is a container for many SafeKeys similar to other crypto wallets, so some said this is just an “address” but we already have xorname addresses, …if everybody think this is worth a change perhaps a new thread can be started to try to find a better name.


I suggest going with wallet. We already have the same duality with bitcoin. People say wallet for either wallet or address and it seems to work. When we need to differentiate and refer explicitly to the address/key, we can say wallet address or wallet key.


Please clarify how SafeKeys are related to keypairs and to balance.
Is SafeKey is a keypair, which is somehow stored inside network?
Do SafeKey is needed to transfer funds or only keypair can be used?
What sn_node creates when started in files reward_public_key & reward_secret_key - keypair, SafeKey or both?

This is something in the TODO list, we fetch transfer’s related information when reading content from the network, which is not needed, so we’ll have to work on removing those requests/steps for read-only operations. I presume some of that is what you are seeing there.

Some time ago we had a “balance” object stored on the network, and SafeKey was chosen to refer to that and to the commands related to it. Now we don’t have such a thing and the balance is just a number kept by elders in the section wallet.

SafeKey at this point in time is just an abstract UX, CLI and sn_api concept, all operation need a signature, and in some cases encryption, made by the client using one or more secret keys. So what you need is secret keys for each operation/message sent to the network, CLI group the commands to manage keypairs, their balance and transfer under the safe keys command…so again, we can start a thread for considering a diff name (wallet suggest by @happybeing and others) and eventually start aligning the UX, API and CLI commands to it. Although, also to consider that a SafeKey/key/… can also be used to encrypting content, so potentially you may wanna use the same secret key for encrypting content to be stored on the network using the same key to pay for it, and/or own it…so we have several things that can be made and the user will eventually be able to choose which key/s to use for: paying for storage, encrypting, signing/owning so other can verify author/authenticity of ownership (WebIds), others…?..

We could say both based on the above.


So SafeKey actually do not exists?
It is representation of keypair?

If yes, then no name is needed for it (from my point of view).
Wallet contains list of public (or, maybe, private) keys and that is it.

Correct, but you may not want to create a Wallet (the container) for storing a single key, you may not want to even store it on the network, you just want to be able to use just the secret key to sign/encryt/pay without needing a Wallet (container). Anyway, as you see this type of topics very quickly become large threads so let’s create a new one.


a @moderators can split the safekey discussion in a new topic I think?

1 Like

Some personal thoughts/ideas of things I as a user would like to be able to do with either CLI or API:

  • I generate a keypair which I’ll use as my key for storing my coins, I obtain a keypair and a xorurl, let’s say: SafeKey1, so I transfer some coins to it either by farming or buying them from someone else or an exchange.
  • I generate a second keypair which I’ll use as my key for ownership, I obtain a keypair and a xorurl, let’s say: SafeKey2.
  • I generate a third keypair which I’ll use as my key for encrypting the data I’ll be uploading, I obtain a keypair and a xorurl, let’s say: SafeKey3
  • Finally I go ahead download CLI and run the following command: $ safe files put ./my_private_notes.txt --pay-with <SafeKey1> --owner <SafeKey2> --encrpyt-with <SafeKey3>

Note I’m not necessarily storing any of the keys/keypair/sk/pk on the network.

What do we call those keys or elements I can interchangeably use for all those actions? curently this is what was meant to be called a SafeKey.


The question regarding your use case is where secret key will be stored.
I figured out that now XOR-URL contains public key. That looks correct.
But it is not enough for payments. SK should be stored somewhere.
It will be easier for regular user to have it stored on his HDD automatically.
Then software will read it from HDD when sees corresponding URL and make payment.
Advanced user may want to have option to manage stored on HDD keys - create them from pk/sk pair (or maybe just sk if it is possible), extract pair from storage, remove them.
(I don’t have direct answer to naming question yet)

Here is rough example how it may look:

  1. safekey create → XOR-URL (SafeKey1) with encoded pk is created, only it is showed to user, sk is stored on HDD.
  2. safekey show --key SafeKey1 → sk and pk are displayed.
  3. safekey delete --key SafeKey1 → sk and pk are displayed and deleted from local database.
  4. safekey create --sk *** → sk (and pk created from it) is stored in database, XOR-URL is displayed to user.

So before deciding how to name SafeKey it is important to figure out what it is.
Is it just a URL for public key or something bigger?

Maybe showing pk directly is not needed at all.
So user will use XOR-URL-encoded pk and hex-encoded sk (so he can see right away that sharing sk is not a good idea).

I agree, what you describe is what the Wallet does already (safe wallet commands), it stores the SKs with a name so you can use them using a name/URL only.
E.g. you can do:

$ safe wallet transfer --from <Wallet URL>/my-first-safekey --to <PK or SafeKey/Wallet URL> <amount>

But the SafeKeys/whatever-name is used for several things, and what I was trying to highlight is that you may want to store it on a Wallet on the network, but you probably not.

I may want to type the SK when running a command, we already have some of that in some CLI commands. Or I may want to use a hardware wallet and each of the keypairs it gives I use it for diff thing (encryot/sign/pay), so a Wallet is a good and necessary option, but it’s not the same as the SafeKey/keypair/whatever-name.

One of the main things why I think it needs a name is for when you share it with someone else to receive a payment or for validating a signature/Id, I can give you my SafeKey URL for you to pay me or validate my identity, and/or authorship of a piece of content, etc.

(I still can’t answer the question, but trying to describe current state)

So now we have such entities, which user can interact with:

  • “Keypair” - just a pair of keys (sk and pk).
  • “Secret key” (sk) - part of keypair.
  • “Public key” (pk) - part of keypair (almost never used because of SafeKey).
  • “SafeKey” - XOR-URL encoded public key.
  • “Spendable balance” - keypair with a name.
  • “Wallet” - list of spendable balances, stored in the network.


Do such command is self-sufficient or it will require user to enter additional information - secret keys?


Keypair with a balance record

I want to clarify one more thing:
Can user recover public key from secret key?

Yes you can, I am not 100% on us having that API/Cli command though. In any case it is possible in both ED25519 and BLS (be aware BLS is deterministic, ED is not, so you can get different but valid ED25519 public keys (and correspond sigs)).


There is also the scenario where the secret key is encrypted with a password.

Imo, it’s best to refer to the pk and sk as the user’s ‘Safe Keys’ in general. One could then refer to the currently used SafeKey moniker as simply a ‘wallet address’ or “safe network token address” or “snt address” that is a special xor-address used for payment transactions.

I wouldn’t say it’s a XOR-URL, a XOR-URL is just a handle for it, in fact you can have a NRS-URL for a SafeKey if you link its XOR-URL to a NRS name, exactly like what I’ve done in testnet1 for receiving testcoins at safe://bochaco, safe://bochaco was an NRS-URL of my SafeKey.
I would even say a Public Key is also a handle of a SafeKey.

That example as it stands should be self-sufficient, but the idea is that all those args are optional, if you don’t provide any of them then for example CLI uses its own keypair (the one given when self-authorised and kept at ~/.safe/cli/credentials)…or you can replace one of those args with --pay-with-trezor 2 which means it should sign the payment with the secret key at index 2 of a Trezor device connected to the PC.


Something is wrong with my understanding then.
Do --pay-with can work just with public key?
If not, then where safe command will look for secret key?


You’d need a secret key passed in with something like --pay-with, …OR…you should be able to pass a Wallet Safe-URL (Safe-URL == XOR-URL or NRS-URL) owned by CLI, so CLI can decrypt the Wallet using its own keypair (~/.safe/cli/credentials), get the secret key and use it to pay for that command.

--pay-with-trezor would have CLI to send the payment operation/packet to Trezor to be signed, the user authorises it through Trezor screen, and CLI receives the signed operation which just use it to send the transaction to the Safe network.