* normal session where both introducees accept
* normal session where the first introducee declines
* normal session where the second introducee declines
* one session where a contact is introduced to herself
* one session where two identities of the same contact
are introduced to each other
This introduces a new IntroductionAbortedEvent to signal when the
protocol was aborted. It is not yet used in the UI.
It closes#276
Contact Introduction Backend
This MR allows you to introduce two of your contacts to each other. They both will receive an introduction with an optional message and then can accept or refuse the introduction which is presented as a notification.
When reviewing, I propose to review the individual commits separately as I took great care to split functional independent parts into separate commits. You might also want to have a look at the [Introduction Client Wiki page](https://code.briarproject.org/akwizgran/briar/wikis/IntroductionClient) to better understand what is going on before looking into the actual code.
Protocol sessions and states are not yet deleted and the UI is still missing (#253). In order to practically test this feature, the UI from !122 is needed.
See merge request !116
BQP with QR codes
This MR implements BQP for key agreement over short-range transports. It also implements the Android UI for using BQP with QR codes.
Closes#117.
See merge request !84
This Introduction BSP Client uses its own group to communicate with
existing contacts. It uses four types of messages to facilitate
introductions: the introduction, the response, the ack and the abort.
The protocol logic is encapsulated in two protocol engines, one for the
introducer and one for the introducee. The introduction client keeps the
local state for each engine, hands messages over to the engines and
processes the result and state changes they return.
Avoid potential deadlock in TransportKeyManager. #235
See rambling description on the ticket and in the architecture channel...
Fixes#235.
See merge request !79
Remove the Toast that always says 'Message Sent' and show graphical
indicators instead that show either:
* message is waiting to be sent
* message was sent (or requested)
* message was delivered
This makes it more likely that connections will be closed cleanly.
However, the interrupt() method is currently ineffective for incoming
sessions as it won't interrupt a blocking read, e.g. when the packet
reader is waiting for a packet.
Torsten Grote
akwizgran
akwizgran
str4d