NAME
     id - the deck's identity

SYNOPSIS
     id
     id gen
     id set name
     id del

DESCRIPTION
     This deck's identity is a keypair it generated itself.  There is no
     account, no password, no email address and no server that issued it.  Id
     is how you look at it and how you make one.

     With no argument it prints what the deck holds: whether a key is loaded,
     the name attached to it, and the address derived from it.

     id gen mints a keypair.  It takes a second or two and asks nothing.  If
     the deck already has one id refuses rather than replacing it, because the
     key is not recoverable and a replacement is a different person as far as
     every board and every other deck is concerned.

     id set name sets the name this deck goes by.  It is kept with the key and
     appears in your shell as $user.  This is the deck's own name for itself;
     claiming a name on a board is handle(1), which is a different thing and
     can be refused by the board if the name is taken.

     id del deletes the keypair.  It prints the identity first and waits for
     you to type yes in full.  There is no undo and no copy anywhere else.

THE ADDRESS
     The address printed against the key is not assigned to you; it is
     computed from the key, six bytes of the SHA-256 of the public half.  Two
     consequences follow, and they are the reason the deck works the way it
     does.

     Nobody can claim your address without your private key, which never
     leaves the machine.  Proving who you are is a signature, not a secret
     sent over the air, so there is nothing on the wire to steal and nothing
     to phish out of you.

     And the address is the same everywhere.  It is the deck's identity to the
     mesh, to a data crystal, and to a board, all at once -- the same six bytes
     at every layer, rather than one name here and another there.  The mesh
     address you see in who(1) is this one.

     A deck with no key still works.  It takes a random mesh address at each
     boot and appears on a crystal as a guest, which can read a board and gets
     a metered allowance of outbound network.  Minting a key is what makes it
     the same deck tomorrow.

EXAMPLES
     See where you stand:

          id

     The usual first run on a new deck:

          id gen
          id set ada
          attune
          handle ada

FILES
     /dev/factotum/ctl
          The identity, read and written.  Id is a script over this file and
          nothing more; see factotum(3) for what else is behind it.

     /dev/factotum/key
          The public half, in the form a crystal wants it.  Its absence is
          what tunein(1) notices when it offers to mint one.

     /n/local/rc/id
          The script.  Read it to see exactly which lines it writes.

SEE ALSO
     attune(1), handle(1), who(1), factotum(3), aether(3)

NOTES
     The mesh address is imposed at boot.  Minting or deleting a key changes
     who the deck is on a crystal straight away, but its address on the radio
     stays as it was until the next restart.

     Setting aetherprivacy=on keeps the key for crystals and boards but leaves
     the radio on a random per-boot address, so the deck is not trackable
     across boots by anyone listening to the air.

BUGS
     The private half cannot be read, copied or moved.  That is the point of
     it, and it is also the whole of the risk: the key lives in the deck's
     settings store rather than its filesystem, so copying your files
     somewhere safe does not save it, and there is no password reset because
     there is no password.  Erasing the flash -- or, in the browser, clearing
     the site's storage -- ends that identity, and every name claimed against
     it, for good.

FRST Computer                                                            ID(1)
