Add support for comments and reblogging to Blog Client
Comments and reblogs need to depend on the post they refer to.
Since message dependencies are limited to one group,
the post and also the comments need to be wrapped
when commented on or reblogged to another blog (and group).
For this reason, in addition to comments, two new wrapping message types
are introduced. They retain all data of the original messages and allow
for reconstruction and signature verification.
This MR breaks backwards compatibility with old blog posts.
It removes the content type, title and parent ID from the post.
Furthermore, it includes one commit that replaces the `Message` in `MessageSharedEvent` with a `MessageId`.
Closes#494
See merge request !285
Before the introducee sends her ACK,
she derives a master key from the ephemeral shared secret as before.
Two nonces and a MAC key are then derived from the master key.
The local introducee signs one of the nonces and calculates a MAC
over her own identity public key, ephemeral public key,
transport properties and timestamp.
The local introducee includes the signature and MAC in her ACK.
On receiving the remote introducee's ACK,
the local introducee verifies the signature and MAC.
Should the verification fail, an ABORT is sent to the introducer and
the remote introducee that was added as inactive is deleted again.
Comments and reblogs need to depend on the post they refer to.
Since message dependencies are limited to one group,
the post and also the comments need to be wrapped
when commented on or reblogged to another blog.
For this reason, in addition to comments, two new wrapping message types
are introduced. They retain all data of the original messages and allow
for reconstruction and signature verification.
This commit breaks backwards compatibility with old blog posts.
It removes the content type, title and parent ID from the post
message structure.
Allow unsubscribing from shared blogs
Only personal blogs from non-contacts can be removed.
This also adds integration tests that check the conditions under which blogs can actually be removed.
Closes#579
See merge request !268
that handles message dependencies reported from clients.
The MessageValidatedEvent has been renamed into a MessageDeliveredEvent
since there were no real use cases for the former any more.
This adds a new table to the database to hold message dependencies.
It introduces two more message states: pending and delivered
The valid column in the database was renamed to state to better reflect
its new extended meaning.
The DatabaseComponent was extended with three methods for:
* adding dependencies
* getting dependencies of a message
* getting messages that depend on a message (dependents)
* getting messages to be delivered (by startup hook)
* getting pending messages to be possibly delivered (by startup hook)
In order to reflect the new states, things that were previously true for
VALID messages have been changed to now be true for DELIVERED messages.
Since pending messages should not be available to clients, many database
queries have been modified to only return results for delivered
messages.
All added methods and changes should come with updated unit tests.
Please note that the database version was bumped in this commit.
The new activity shows who you are sharing a forum with and who shares a
forum with you. It is accessible from the overflow menu when in a forum.
Closes#398
The code for creating forums in ForumManager was used by
ForumSharingManager and also needed by InviteeEngine.
This extracts it into its own class.
Closes#375
Poller refactoring, replace Timer with ScheduledExecutorService
* Replace Timer with ScheduledExecutorService (closes#258)
* Move automatic connection logic from PluginManager to Poller
* Reschedule polling when connections are opened or closed, making the poller more responsive to reductions in the polling interval
See merge request !180
Forum Sharing Integration Tests
This adds integration tests for these cases:
* normal invitation session where invitee accepts
* normal invitation session where invitee declines
* session where invitee leaves again after she joined
* session where sharer leaves after invitee has joined
* session where sharer leaves before invitee can respond
* sharer reuses the session ID of the previous session
* after accepting the invitation, the invitee invites the sharer to the same forum
* after session contacts delete each other and session states get cleaned up
Closes#339
See merge request !173
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 adds integration tests for these cases:
* normal invitation session where invitee accepts
* normal invitation session where invitee declines
* session where invitee leaves again after she joined
* session where sharer leaves after invitee has joined
* session where sharer leaves before invitee can respond
* sharer reuses the session ID of the previous session
* after accepting the invitation, the invitee invites the sharer to the same forum
* after session contacts delete each other and session states get cleaned up
Closes#339
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.
* 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
