briar issueshttps://code.briarproject.org/groups/briar/-/issues2018-06-12T11:32:21Zhttps://code.briarproject.org/briar/briar/-/issues/569Convert HTML to plain text safely and readably2018-06-12T11:32:21ZakwizgranConvert HTML to plain text safely and readablyFor RSS import we need to convert HTML blog posts into plain text while preserving readability, and without allowing any unsafe content to be rendered. For RSS import we need to convert HTML blog posts into plain text while preserving readability, and without allowing any unsafe content to be rendered. Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/566Raise minimum Android version to 42018-06-12T11:32:21ZakwizgranRaise minimum Android version to 4* Raise minimum API version to 14
* Remove any code and resources that only apply to older versions
* Close as rejected any tickets that only apply to older versions
* Raise minimum API version to 14
* Remove any code and resources that only apply to older versions
* Close as rejected any tickets that only apply to older versions
Milestone Dhttps://code.briarproject.org/briar/briar/-/issues/558Use namespaced strings for transport IDs2018-06-12T11:32:22ZakwizgranUse namespaced strings for transport IDsAdd a namespace to the strings used to identify transports. The IDs could follow the same convention as Java packages, e.g. `org.briarproject.bramble.bluetooth`. This would allow independent developers to assign IDs without collisions.
...Add a namespace to the strings used to identify transports. The IDs could follow the same convention as Java packages, e.g. `org.briarproject.bramble.bluetooth`. This would allow independent developers to assign IDs without collisions.
Potential downside: more data to store in QR codes.Milestone FTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/557Use namespaced strings for client IDs2018-06-12T11:32:22ZakwizgranUse namespaced strings for client IDsInstead of random unique IDs, use namespaced strings to identify clients. The IDs could follow the same convention as Java packages, e.g. `org.briarproject.briar.messaging`. This would allow independent developers to assign IDs without c...Instead of random unique IDs, use namespaced strings to identify clients. The IDs could follow the same convention as Java packages, e.g. `org.briarproject.briar.messaging`. This would allow independent developers to assign IDs without collisions.Milestone FTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/554Audit uses of ResultHandler2018-06-12T11:32:22ZakwizgranAudit uses of ResultHandler* Controllers should depend on ResultHandler/ResultExceptionHandler, not UiResultHandler/UiResultExceptionHandler, to allow us to use synchronous handlers when unit testing controllers
* Handlers shouldn't return true if everything went...* Controllers should depend on ResultHandler/ResultExceptionHandler, not UiResultHandler/UiResultExceptionHandler, to allow us to use synchronous handlers when unit testing controllers
* Handlers shouldn't return true if everything went fine or false if there was an exception - use ResultExceptionHandler if the UI needs to know about failures, and ResultExceptionHandler\<Void\> if it doesn'tMilestone Eakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/552Check thread safety of MessageTree2018-06-12T11:32:22ZakwizgranCheck thread safety of MessageTreeMilestone Ehttps://code.briarproject.org/briar/briar/-/issues/549Require a label for signing2018-06-12T11:32:22ZakwizgranRequire a label for signingCreate a CryptoComponent#sign() method that takes a mandatory label argument to ensure that signatures can't be repurposed.
The labels could use the same convention as namespaced client IDs (#557), e.g. `org.briarproject.briar.forum.p...Create a CryptoComponent#sign() method that takes a mandatory label argument to ensure that signatures can't be repurposed.
The labels could use the same convention as namespaced client IDs (#557), e.g. `org.briarproject.briar.forum.post`. This would allow independent developers to assign labels without collisions.Milestone FTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/548Require a label for hashing2018-06-12T11:32:22ZakwizgranRequire a label for hashingCryptoComponent#hash() should take a mandatory label argument to ensure that hashes calculated for distinct purposes don't collide.
The labels could use the same convention as namespaced client IDs (#557), e.g. `org.briarproject.bramb...CryptoComponent#hash() should take a mandatory label argument to ensure that hashes calculated for distinct purposes don't collide.
The labels could use the same convention as namespaced client IDs (#557), e.g. `org.briarproject.bramble.messageid`. This would allow independent developers to assign labels without collisions.Milestone FTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/545Find out why DB lookups are so slow2018-03-29T12:29:31ZakwizgranFind out why DB lookups are so slowAsynchronously looking up small amounts of data from the database takes longer than it should, even when the same data has been looked up recently. Work out which part of the process is the bottleneck, and how much performance would be i...Asynchronously looking up small amounts of data from the database takes longer than it should, even when the same data has been looked up recently. Work out which part of the process is the bottleneck, and how much performance would be improved if we spent some time improving that part of the process.Android 1.0akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/542Don't poll for retransmission2018-03-08T15:59:11ZakwizgranDon't poll for retransmissionOutgoing sync sessions poll the database periodically for messages that have reached their send times and can be sent or offered again. This requires a thread to wake up periodically for each open session, even when there's nothing to se...Outgoing sync sessions poll the database periodically for messages that have reached their send times and can be sent or offered again. This requires a thread to wake up periodically for each open session, even when there's nothing to send.
The sync layer should keep track of the earliest send time of any message in the DB, and either broadcast an event when the send time is reached or provide a method that blocks until the earliest send time is reached.
Related to #44.Android Beta 2akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/541Allow retransmission if it will result in faster delivery2018-09-18T17:04:01ZakwizgranAllow retransmission if it will result in faster deliveryEach time a message is sent to a contact, the message's send time is updated based on the maximum latency of the transport, and the message cannot be sent to the contact again until the send time is reached. This prevents messages from b...Each time a message is sent to a contact, the message's send time is updated based on the maximum latency of the transport, and the message cannot be sent to the contact again until the send time is reached. This prevents messages from being retransmitted unnecessarily while they're still in transit. However, if a message is in transit over a high-latency transport, it may be desirable to allow it to be retransmitted over a low-latency transport to allow faster delivery.
Instead of comparing the send time to the current time, it should be compared to the expected delivery time over the current transport. The current time plus the maximum latency of the current transport can be used as a first estimate of the expected delivery time; we can get clever with round-trip time measurements later.Mailbox PrototypeJulian DehmJulian Dehmhttps://code.briarproject.org/briar/briar/-/issues/524Check that ACRA is catching all uncaught exceptions2018-06-12T11:32:23ZakwizgranCheck that ACRA is catching all uncaught exceptionsWe've had two reports recently of crashes that don't seem to have been caught by ACRA. @ernir reported a crash in #516 where the background service disappeared (possibly killed by the OS due to resource limits) without the crash report d...We've had two reports recently of crashes that don't seem to have been caught by ACRA. @ernir reported a crash in #516 where the background service disappeared (possibly killed by the OS due to resource limits) without the crash report dialog appearing, and @grote reported that an IllegalArgumentException on a background thread caused by a blog post exceeding MAX_BODY_LENGTH caused a crash without a stacktrace.Milestone FTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/517Simple UI for Managing RSS Feeds2018-06-12T11:32:23ZTorsten GroteSimple UI for Managing RSS FeedsImplement the design from #483.Implement the design from #483.Milestone DTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/506Metadata collections2018-06-12T11:32:23ZakwizgranMetadata collectionsA key/value map of metadata can be associated with any group ID or message ID in the local DB. Some clients also need to store metadata for protocol sessions, which requires a hack to associate the session ID with a message ID where the ...A key/value map of metadata can be associated with any group ID or message ID in the local DB. Some clients also need to store metadata for protocol sessions, which requires a hack to associate the session ID with a message ID where the metadata is stored.
We can generalise the current approach by replacing the group ID or message ID with an arbitrary collection ID. However, we still want all metadata to belong to a group so it can be garbage collected if the group is removed. So the metadata structure becomes: group/collection/key/value. To associate metadata with a message, use the message ID as the collection ID. Metadata queries that currently return message IDs will return collection IDs instead.
This change will allow protocol clients to store metadata directly under the session ID. It will also allow settings to be stored as metadata rather than using a separate DB table, and the group and message metadata tables can be merged.
Sub-task of #136.https://code.briarproject.org/briar/briar/-/issues/497Implement backend for sharing blogs2018-06-12T11:32:24ZakwizgranImplement backend for sharing blogsSub-task of #406.Sub-task of #406.Milestone DTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/494Implement backend for reblogging and blog comments2018-04-16T16:24:37ZakwizgranImplement backend for reblogging and blog commentsSub-task of #437.
# Group Messages
The group descriptor is a BDF list with three elements: `name` (string), `author_name` (string) and `public_key` (raw). Posts are signed with the corresponding private key.
## 0: Post
A blog p...Sub-task of #437.
# Group Messages
The group descriptor is a BDF list with three elements: `name` (string), `author_name` (string) and `public_key` (raw). Posts are signed with the corresponding private key.
## 0: Post
A blog post.
* `type` (int) - Must be 0
* `content` (string) - The content of the blog post
* `signature` (raw) - A signature over a list with the following elements:
* `group_id` (raw) - Taken from the [message header](BSP#message-format)
* `timestamp` (int) - Taken from the [message header](BSP#message-format)
* `type` (int) - As described above
* `content` (string) - As described above
Dependencies: None
## 1: Comment
A comment on a blog post.
* `type` (int) - Must be 1
* `content` (string or null) - An optional comment added to the post
* `parent_original_id` (raw) - The ID of a post or comment in this group or another group
* `parent_id` (raw) - The ID of a post, comment, wrapped post or wrapped comment in this group, which had the ID `parent_original_id` in the group where it was originally posted
* `signature` (raw) - A signature over a list with the following elements:
* `group_id` (raw) - Taken from the [message header](BSP#message-format)
* `timestamp` (int) - Taken from the [message header](BSP#message-format)
* `type` (int) - As described above
* `content` (string or null) - As described above
* `parent_original_id` (raw) - As described above
* `parent_id` (raw) - As described above
Dependencies: `parent_id`
## 2: Wrapped Post
A post from another group that has been reposted to this group. Not shared with other subscribers unless it is a transitive dependency of a valid post or comment in this group.
* `type` (int) - Must be 2
* `post_group_descriptor` (raw) - The descriptor of the group where the post was originally posted
* `post_timestamp` (int) - Taken from the original post
* `post_content`(string) - Taken from the original post
* `post_signature` (raw) - Taken from the original post
Dependencies: None
## 3: Wrapped Comment
A comment from another group that has been reposted to this group. Not shared with other subscribers unless it is a transitive dependency of a valid post or comment in this group.
* `type` (int) - Must be 3
* `comment_group_descriptor` (raw) - The descriptor of the group where the comment was originally posted
* `comment_timestamp` (int) - Taken from the original comment
* `comment_content` (string or null) - Taken from the original comment
* `comment_parent_original_id` (raw) - Taken from the original comment
* `comment_parent_id` (raw) - Taken from the original comment
* `comment_signature` (raw) - Taken from the original comment
* `parent_id` (raw) - The ID of a post, comment, wrapped post or wrapped comment in this group, which had the ID `comment_parent_original_id` in the group where it was originally posted
Dependencies: `parent_id`
Milestone DTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/487Proof-of-concept RSS feed import with ROME on Android2018-06-12T11:32:24ZakwizgranProof-of-concept RSS feed import with ROME on AndroidThe pull request to remove the java.beans dependency from ROME has been merged, but it doesn't affect rome-fetcher as that module is deprecated. Ensure that we can build and run the code we need for a basic RSS feed fetcher on Android.The pull request to remove the java.beans dependency from ROME has been merged, but it doesn't affect rome-fetcher as that module is deprecated. Ensure that we can build and run the code we need for a basic RSS feed fetcher on Android.Milestone DTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/486Convert RSS feed entries into Briar blog posts2018-06-12T11:32:24ZakwizgranConvert RSS feed entries into Briar blog postsSub-task of #135.
First iteration:
* Use whatever content is included in the feed, don't try to fetch the full text if it's not included
* Strip HTML tagsSub-task of #135.
First iteration:
* Use whatever content is included in the feed, don't try to fetch the full text if it's not included
* Strip HTML tagsMilestone DTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/485Extract new entries from RSS feed2018-06-12T11:32:24ZakwizgranExtract new entries from RSS feedSub-task of #135.
For each registered feed, keep track of which entries have been seen. Pass any new entries down the pipeline to be converted and posted.Sub-task of #135.
For each registered feed, keep track of which entries have been seen. Pass any new entries down the pipeline to be converted and posted.Milestone DTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/484Implement background task for fetching RSS feeds2018-06-12T11:32:24ZakwizgranImplement background task for fetching RSS feedsSub-task of #135.
* Implemented in briar-core, possibly as a Service so it gets started when the app starts
* Exposes a FeedManager interface that the UI can use to register and unregister feeds
* In the first iteration, fetches fee...Sub-task of #135.
* Implemented in briar-core, possibly as a Service so it gets started when the app starts
* Exposes a FeedManager interface that the UI can use to register and unregister feeds
* In the first iteration, fetches feeds via HTTP
* In a future iteration, uses Tor's SOCKS proxyMilestone DTorsten GroteTorsten Grote