Public API

[juniorz]

At the moment we have two sets of API:

Protocol API (#include <libotr4/otrv4.h>)

This is the API for "Off-the-Record Messaging Protocol version 4". A protocol manages a connection that allows different versions of the wire protocols defined in the spec (version 3 and version 4). Once two running protocols decide on a wire protocol version, they use it to start a connection by running a key-exchange algorithm.

A connection is able to process incoming zero-terminated *char messages ("strings") from the IM network and decide how to respond to it. Incoming messages may cause a zero-terminated *char message (OTR-encoded "strings") to be send as a response, or contain a *uint8_t plaintext message (array of bytes).

A connection is able to process *uint8_t plaintext message (array of bytes) into a zero-terminated *char message (either OTR-encoded or plaintext message "strings") before sending to the IM network.

Client API (#include <libotr4/client.h>)

This is a "messaging client". A client manages multiple conversations with other recipients/senders, identified by a identity ("[email protected]", for example).

A client knows which conversation to use in order to send/receive zero-terminated *char messages ("strings") to/from a recipient/sender.

[juniorz]

Questions:

• Do the actual APIs correspond to the text?
• Should we extract the connection (or wire) API and make it public?
• Should a connection be able to send arbitrary array of bytes or only zero-terminated strings?

[claucece]

For this, should be checked:

• [x] that everything that should be static is static.
• [x] separate the internal header files from the API ones.

[olabini]

I have made sure we have the structure for this, but the actual separation of things need to be done. I think we should use development of the plugin to drive this, so probably not something we can do early.

[claucece]

Yes, this is something to be done right at the end of the libotr-ng work @olabini