Quick start: Do "/load otr" (irssi syntax), write "?OTR?" to your OTR buddy,

wait until the now ongoing key generation finishes and write "?OTR?" again. You

should "go secure".

Key generation happens in a separate 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 irc-otr is now something between manual and

opportunistic. Manual means you have to start it yourself by issuing "?OTR?",

opportunistic means both peers send some magic whitespace and start OTR once

they receive this whitespace from the other side. irc-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 separated 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" (irssi syntax) so

you're informed about what's going on.

In "<client config dir>/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 irc-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.