Specifically around the fragmented messages descriptions there are several inconsistencies and errors.

The message should be hidden from the user but we should generate a notification.

Things like getting rid of SHA1 and DSA

The example for fragments provided by the V2 of spec has no leading zeroes for the number of pieces, but the same example in the V3 of the spec has leading zeroes.

We are generating the piece number with leading zeroes for both versions. It makes me wonder if this could break compatibility with some strict-V2 implementation - or if this should be reported as a bug in the spec.

Will it crash?

We are wiping data structures at the moment we reassign them, but we could use finalizers instead.

The doc for MessageEventConnectionEnded says:

ConversationEnded indicates that the peer ended the secure conversation.

However it is only emitted when we (not the other peer) send a message while the OTR conversation has finished. We might be using it wrongly in coy (see coyim/coyim#128), but this is misleading at least.

According to the spec:
"Check that the counter in the Data message is strictly larger than the last counter you saw using this pair of keys"

We don't care about the pair of keys. Thus, a message composed of (senderKeyid, receiverKeyid, ctr), these are all valid message progressions:
(1, 1, 1)
(1, 1, 2)
(2, 2, 1)

This is a blocker for us right now, since it stops us from receiving more than one data message.

Several places in V3 specifies more checking of SMP parameters. We should do that.

Things like ALLOW_V2, ALLOW_V3, REQUIRE_ENCRYPTION etc.

To implement V1 support, need to follow this doc

It doesn't cause much damage, but we use up randomness from the system without reason.

It is based on libotr 4.1.1 or 4.1.0?

The website is https://www.otr.im/

Last version 4.1.1 : https://bugs.otr.im/lib/libotr

Time to go:

• https://github.com/otrv4
• https://github.com/otrv4/libotr-ng

It would be very useful for my client to know what the security status of the other side is. Specifically, if we have something like this coyim/coyim#32 Security number idea, it would be great if we had a TLV we can send with this number, and a boolean indicating whether I have verified the peer or not.

Make documentation easy-reading. Provide a simple example for basic usage.

At the moment, only the latest message is stored.

it would be nice if our otr3 can be a portable lib of cgo

We use []byte for a lot of different things:

• Incoming messages (both plain/encoded)
• Serialized things (both with/without header)
• Outbound messages (including before/after encoding and before/after adding header)

It is very confusing.

For instance: receiveDecoded() gets data from processDataMessage(), maybeHeartbeat() and receiveAKE() and its hard to know if they all return toSend with the same meaning for []byte.