Quick start: Do "/load otr", write "?OTR?" to your OTR buddy, wait until the now
ongoing key generation finishs and write "?OTR?" again. You should "go secure".

Key generation happens in a seperate  process and its duration mainly depends on
the available entropy. On  my desktop it takes about 6  Minutes, about 2 Minutes
if I run  "du /" in parallel  and on an idle  server system it can  even take an
hour.

The  default  OTR policy  of  irssi-otr  is  now  something between  manual  and
opportunistic. Manual means  you have to start it yourself  by issueing "?OTR?",
opportunistic means  both peers send  some magic  whitespace and start  OTR once
they  receive this  whitespace from  the other  side. irssi-otr  uses a  mode in
between  where  we  are  not  sending  whitespace  as  an  announcement  (as  in
opportunistic) but we still  handle whitespace if we see it  from the other side
(I'm  calling  it handlews).  Therefore  if  your  peer uses  opportunistic  the
handshake should still start automatically once he writes something.

You can  now set the  OTR policy  per peer via  the otr_policy /setting.  It's a
comma seperated  list of "<nick>@<server> <policy>"  pairs where <nick>@<server>
is interpreted as a glob pattern, i.e. you can use wildcard "*" and joker "?" as
you would  in a shell.  The policy  can be one  of never, manual,  handlews (the
default),  opportunistic, and  always. Be  aware that  the opportunistic  policy
fails with  some IRC  servers since  they strip off  the whitespace.  The always
policy has  the nice side effect  that the first  line you type will  already be
encrypted.

If  a  fingerprint can  be  found  for someone,  i.e.  someone  you had  an  OTR
conversation  with  before,  then  the otr_policy_known  setting  applies  after
otr_policy. It has the same syntax. The  default is "* always", i.e. enforce OTR
with  anyone you've  used  OTR with  before.

Should you finish an OTR session via "/otr finish" and should the active policy
be always or opportunistic then it will be temporarily set back to handlews.
Otherwise OTR would start again right away which is probably not what you want.
This is however reset once you close the query window.

To make  sure that you are  actually talking to your  buddy, you can agree  on a
secret somehow  and then one does  "/otr auth <secret>". Shortly  afterwards the
other  one will  be  asked to  do  the  same and  you're  done. The  traditional
alternative, comparing  fingerprints over a secure  line, can also be  used. Use
"/otr trust" once you're sure they match.

I also strongly  recommend to do "/statusbar window add  otr" so you're informed
about what's going on.

In  "~/.irssi/otr/otr.{key,fp}" you'll  find the  fingerprints and  your private
keys(should you at any point be interested).

Commands:

/otr genkey nick@irc.server.com 
	Manually generate a key for the given account(also done on demand)
/otr auth [<nick>@<server>] <secret>
	Initiate or respond to an authentication challenge
/otr authabort [<nick>@<server>] 
	Abort any ongoing authentication
/otr trust [<nick>@<server>]
	Trust the fingerprint of the user in the current window.
	You should only do this after comparing fingerprints over a secure line
/otr debug
	Switch debug mode on/off
/otr contexts
	List all OTR contexts along with their fingerprints and status
/otr finish [<nick>@<server>]
	Finish an OTR conversation
/otr version
	Display irssi-otr version. Might be a git commit

Settings:

otr_policy
	Comma-separated list of "<nick>@<server> <policy>" pairs. See comments
	above.
otr_policy_known
	Same syntax as otr_policy. Only applied where a fingerprint is
	available.
otr_ignore
	Conversations with nicks that match this regular expression completely
	bypass libotr. It is very unlikely that you need to touch this setting,
	just use the OTR policy never to prevent OTR sessions with some nicks.
otr_finishonunload
	If true running OTR sessions are finished on /unload and /quit.
otr_createqueries
	If true queries are automatically created for OTR log messages.
