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.
Use Briar's IoUtils.copy(), not H2's IOUtils.copy()
Our implementation closes both streams, H2's implementation leaves them open.
Closes#614.
See merge request !293
Blog controller thread safety
This patch removes the mutable list of posts from the blog controller to make it thread-safe, and adds a cache of message bodies to speed up reloads.
Closes#555.
See merge request !276
Scrub addresses before logging them
MAC, IP and onion addresses are now scrubbed before logging to ensure we don't leave any sensitive information in plaintext on the device or send it in crash reports or feedback.
* Bluetooth MAC addresses keep the first and last octets
* IPv4 addresses keep the first and last octets
* IPv6 addresses should be scrubbed completely (couldn't test)
* Onion addresses keep the first three characters
If an address is invalid it will not be scrubbed to enable debugging, because it is most likely not sensitive.
Closes#592
See merge request !290
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
This commit refactors the code for sharing forums,
so it can be used for sharing blogs as well.
It does not yet include code for responding to blog invitations.
* Implemented in briar-core as a `ScheduledExecutorService`
that gets started when the app starts
* The briar-api has a `FeedManager` interface
that the UI can use to register and unregister feeds
* In this first iteration, feeds are fetched via HTTP(S), not Tor
Closes#484
The old behaviour was a leftover from the days of limited retention periods. The new behaviour will interact better with dependencies and message queues.
Use Client Layer Events in ContactListFragment
This prevents trying to access the same group metadata in different groups.
Also, the conversation does not need to be reloaded once introduction messages arrive.
Closes#535
See merge request !254
Database queries for metadata only returned it for messages that were delivered already.
However, there are cases (e.g. a pending message needs to be delivered) where
the validator needs to retrieve the metadata from the database.
For these cases, a special database query has been introduced.
The forum UI depended on sync layer events such as MessageStateChangedEvent.
Now, the forum client broadcasts its own high-level event (`ForumPostReceivedEvent`)
with the information the UI needs (`ForumPostHeader`).
Closes#310
