Identity¶
Your identity in Kunuleco is a set of keys kept on your node and encrypted with your password. Nothing about it is issued by us, and no outside service can suspend, rename or reset it.
Why this matters¶
On most services your account belongs to the service. It can be suspended, reset, renamed or mined for data, and it goes away if the service does. A Kunuleco identity is a key pair on the node you signed up on, protected by a password only you know. There is no authority to appeal to, which also means there is no authority that can take it from you.
The three layers¶
| Layer | Example | What it is for |
|---|---|---|
| AID | a KERI identifier | What your node proves, with a signed hello, every time it connects. Blocks, grants and invites key on it |
| Handle | mira#7K2QX9 |
The human-friendly name. The six-character tag is derived from your name and your AID, so you cannot pick it |
| Short or intro code | tiger-castle-7 |
A speakable code for first contact. See Connections |
The tag uses the Crockford alphabet, which leaves out I, L, O and U so that it survives
being read aloud or retyped from a screenshot. It is not case-sensitive, and a typed O or
I is read as 0 or 1.
Anyone can choose the name mira, but only the holder of your AID can prove mira#7K2QX9,
because the tag is computed from it. Once your node has bound a handle to one AID, it will
not bind that handle to a different one. Names can change and anyone can claim one, so
everything that must hold on to a person keys on the AID their connection proved.
Your account also has an older did:key:z6Mk… identifier. It still appears in places such
as your peer registry and the output of import-identity. It is fixed to one key and
cannot rotate.
The records you will see named¶
- AIRO is your private identity record, encrypted on disk with a key derived from your password. This is what "your identity" means on the node.
- PIRO is your public, shareable record. It tells peers how to reach you across transports.
- The node user is the node's own account, created the first time the node starts. It is the root that the first owner's rights come from, and nobody can sign in as it. See Trust and standing.
Key events¶
Your node keeps a KERI key event log for your AID. The first event commits in advance to the next key, so someone who steals the current key cannot write a valid next event. Your node checks the log each time you sign in.
Your node sends the log in its hello, and the other node verifies it before it accepts your AID. The receiving node keeps what it verified, so a second, conflicting history for the same AID is refused. A log a node presents about itself proves that it is consistent and ends at the key that signed the hello. There are no witnesses yet, so it does not prove that this is the only history the key holder ever wrote.
There is no command to rotate a key yet. Until there is, treat your identity backup the way you would treat a wallet seed phrase. If it leaks, the fix is a new identity, not a rotation.
Passwords, lockout and backups¶
There is no password reset. You can change your password while signed in (/passwd in the
Urchin client, or PASSWD <old> <new>), but you cannot recover one you have lost. Repeated
wrong passwords lock the account for a while. One failure is forgiven for every five minutes
without a failed attempt, so the lock wears off by itself.
Your safety net is an encrypted export. The passphrase is given base64-encoded, and the client wraps this for you.
export-identity refuses paths that look cloud-synced, such as a OneDrive or Dropbox
folder. import-identity reads only from the node's imports directory (<data>/imports).
Put the file there and name it relative to that directory. The import refuses a name that
another account on the node already holds, and it replaces an existing identity only with
--overwrite. After an import, restart and sign in with that identity's username and
password.
The export is also how you move to a new machine. It holds your identity record, its keys and its key event log. It does not hold your chat history, grants, boards or anything else on your node. The file shows your username in plain text so you can tell backups apart. Anyone with the file and the passphrase holds your identity, so store the two apart.
Related¶
- Trust and standing: what an identity can do in a given place.
- Connections: how identities find and verify each other across transports.