Try harder to connect to contacts
* When an outgoing connection is lost, try to reconnect to the contact straight away
* Use periodic polling for Tor, regardless of whether our hidden service descriptor has been published
* Reduce polling intervals for all plugins (this can be reverted if we solve the connectivity issues)
Closes#262, #314. Hopefully helps with #361.
See merge request !177
Forum Sharing Client Backend
This MR replaces the old `ForumSharingManagerImpl` with a new one
which is based on state machines and the `ProtocolEngine`.
There is a `SharerEngine` and a `InviteeEngine` that take care of state
transitions, messages, events and trigger actions to be carried out by
the `ForumSharingManagerImpl`. This is all very similar to the
Introduction Client.
The general sharing paradigm has been changed from sharing as a state to
sharing as an action. Now the UI can allow users to invite contacts to
forums. The contacts can accept or decline the invitation. Also, the
Forum Sharing Manager is notified when users leave a forum.
Please note that you will need the UI to actually test this. It is coming up soon in another MR.
Closes#322
See merge request !170
It was possible that a malicious introducer sends new request with the
same session ID that was used previously and thus causing introducees to
have multiple states for the same session ID.
This commits prevents that from happening and adds an integration test
for that scenario.
Also if an introducee removes an introducer, all past session states
will be deleted from the database. For this, a test was added as well.
Closes#371Closes#372
This commit replaces the old ForumSharingManagerImpl with a new one
which is based on state machines and the ProtocolEngine.
There is a SharerEngine and a InviteeEngine that take care of state
transitions, messages, events and trigger actions to be carried out by
the ForumSharingManagerImpl. This is all very similar to the
Introduction Client.
The general sharing paradigm has been changed from sharing as a state to
sharing as an action. Now the UI can allow users to invite contacts to
forums. The contacts can accept or decline the invitiation. Also, the
Forum Sharing Manger is notified when users leave a forum.
Closes#322
Methods for creating, adding and removing forums have been moved to the
`ForumManager`. In order to still handle removing forums properly, a
`RemoveForumHook` has been introduced.
Methods for sharing forums with all current and future contacts have
been removed along with the localGroup where this information was saved.
The `ShareForumActivity` now has the proper label.
The `SessionId` and the `ProtocolEngine` have been moved to the
`clients` package.
This addresses part of #322 and part of what has been discussed in #320.
Show relevant introduction decline responses in the conversation
* If the user has already declined, we don't show that the other
introducee has declined as well. The backend doesn't have that information, so
this is compatible with the principle of showing what we know.
* If the user has already accepted or hasn't yet responded, we now show the
decline response in the private conversation with the introducer. If
the user hasn't yet responded, we hide the accept/decline buttons
in the introduction request message.
Please note that I do not have three devices at the moment to test this MR in its entirety in practice. I created another test which is hopefully sufficient to ensure that the modifications are correct.
Closes#295
See merge request !149
* If the user has already declined, we don't show that the other
introducee has declined as well. The backend doesn't have that information, so
this is compatible with the principle of showing what we know.
* If the user has already accepted or hasn't yet responded, we show the
decline response in the private conversation with the introducer. If
the user hasn't yet responded, we hide the accept/decline buttons
in the introduction request message.
Messages an introducee receives in a `FINISHED` state are now being
ignored and deleted.
Closes#295
* 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
* force decline when two of our own identities are introduced to each
other
* throw away introduction requests to the same identity
(impossible to trigger from UI)
Closes#284
When devices' clocks are out of sync, it is possible that a response is
shown before the request. This commit makes sure that the timestamp of
responses is always later than the last message in the conversation.
Some wording could be misunderstood to thing introductions were
successful even though they were not. That has been clarified.
A new database transaction was created when getting contacts and local
transport properties. This has been changed to re-use the existing
transaction.
Also addresses minor issues found in review.
The code made the assumption that a session state can be identified by
the unique session ID. However, when multiple identities from the same
device are involved, there are two sessions with the same ID running on
the device.
Hence, a second identifying criteria has to be used to uniquely identify
the correct session. Here, the ID of the group was chosen.
Unfortunately, the session state can not be cached easily anymore
leading to a small performance penalty when getting all messages for the
UI.
Clean up tests
* Broke up ConstantsTest (#280) - the key encoding parts are now in KeyEncodingAndParsingTest, the message encoding parts are in MessageSizeIntegrationTest
* Renamed the other integration tests in briar-android-tests
* Moved the integration tests in briar-android-tests to the top-level package, as they all involve code from multiple packages
* Separated DatabaseExecutorModule from DatabaseModule so we can use a different @DatabaseExecutor in integration tests
* Merged AppModule with AndroidModule (@ernir, this touches code you're working on but I don't think there are any conflicts)
* Renamed some TestUtils methods for consistency
* Used TestUtils.getRandomBytes() where applicable
Fixes#280.
See merge request !133
Create local state for clients at startup. #279
Most of the clients we've written so far use private groups shared with individual contacts and/or a local group that's not shared with anyone. To make it easier to ensure that the necessary groups exist when we need them, this patch allows clients to register startup hooks for creating their local state.
Fixes#279.
See merge request !131
Don't allow reentrant transactions
The database's transaction lock is reentrant, meaning that a thread that's already holding the lock can acquire it again. This would allow a thread that already has a transaction in progress to start another transaction, which could cause transaction isolation issues and/or lock timeouts on the database's internal locks.
Check that the current thread isn't already holding the lock when starting a transaction.
See merge request !127
