briar issueshttps://code.briarproject.org/briar/briar/-/issues2023-06-19T14:01:29Zhttps://code.briarproject.org/briar/briar/-/issues/1011Offline message delivery (mailbox)2023-06-19T14:01:29ZakwizgranOffline message delivery (mailbox)Two testers asked for the ability for messages to be delivered while the recipient is offline. "Some of my global contacts are rarely online with me."Two testers asked for the ability for messages to be delivered while the recipient is offline. "Some of my global contacts are rarely online with me."Mailbox2022-10-31https://code.briarproject.org/briar/briar/-/issues/2343End-to-end integration tests for communication via mailbox2023-01-19T13:05:12ZakwizgranEnd-to-end integration tests for communication via mailboxWrite end-to-end integration tests in which two Bramble components, representing a mailbox owner and a contact, communicate via a mailbox running on localhost.
Depends on #2228.Write end-to-end integration tests in which two Bramble components, representing a mailbox owner and a contact, communicate via a mailbox running on localhost.
Depends on #2228.MailboxSebastianSebastianhttps://code.briarproject.org/briar/briar/-/issues/2320FormatException when loading mailbox API version metadata2022-06-01T11:39:08ZakwizgranFormatException when loading mailbox API version metadataMailboxIvanaIvanahttps://code.briarproject.org/briar/briar/-/issues/2299Method for fetching mailbox's supported API versions2022-05-18T12:19:07ZakwizgranMethod for fetching mailbox's supported API versionsDepends on briar-mailbox#103.Depends on briar-mailbox#103.MailboxDaniel LublinDaniel Lublinhttps://code.briarproject.org/briar/briar/-/issues/2295Let MailboxPropertyManager broadcast event when contact's mailbox props are u...2022-03-31T09:24:23ZDaniel LublinLet MailboxPropertyManager broadcast event when contact's mailbox props are updatedOn incoming mailbox properties update, MailboxPropertyManagerImpl#incomingMessage should broadcast an event that a contact's mailbox props were updated.
It is the Mailbox client manager that will consume this event: https://code.briarpr...On incoming mailbox properties update, MailboxPropertyManagerImpl#incomingMessage should broadcast an event that a contact's mailbox props were updated.
It is the Mailbox client manager that will consume this event: https://code.briarproject.org/briar/briar/-/issues/2228MailboxDaniel LublinDaniel Lublinhttps://code.briarproject.org/briar/briar/-/issues/2265Replace ETA with max latency in retransmission logic2022-03-29T13:12:39ZakwizgranReplace ETA with max latency in retransmission logicThe sync protocol allows a message to be retransmitted if either the message's send time (also called expiry time in the database code) has been reached, or if the message's ETA via the currently available transport would be earlier than...The sync protocol allows a message to be retransmitted if either the message's send time (also called expiry time in the database code) has been reached, or if the message's ETA via the currently available transport would be earlier than the ETA of the previous copy. The ETA is based on the max latency of the transport.
This second (ETA) condition is met when the previous copy was sent via a higher-latency transport and a lower-latency transport is now available. But this logic has a weird edge case: immediately after sending a message via a higher-latency transport, the message can be sent via a lower-latency transport, as intended. But as the ETA of the first copy approaches, the message stops being sendable via the lower-latency transport.
This edge case is unlikely to matter when the lower latency is a tiny fraction of the higher latency (eg 30 seconds for Tor vs 28 days for removable drives). But it may become important when the lower latency is a significant fraction of the higher latency (eg 14 days for mailboxes vs 28 days for removable drives).
To remove the edge case we should store the max latency of the transport rather than the ETA, and allow the message to be retransmitted if either the send time has been reached (as now), or if the max latency of the currently available transport is less than the max latency of the transport used for the previous copy. This will require a DB migration.MailboxDaniel LublinDaniel Lublinhttps://code.briarproject.org/briar/briar/-/issues/2251Show a warning on Android 4 that Briar will expire2022-01-18T15:03:58ZakwizgranShow a warning on Android 4 that Briar will expireShow a snackbar on Android 4, similar to the existing expiry snackbar for debug builds, warning the user that the app will expire on a certain date and they will need to upgrade to a newer device and create a new account.
If the explana...Show a snackbar on Android 4, similar to the existing expiry snackbar for debug builds, warning the user that the app will expire on a certain date and they will need to upgrade to a newer device and create a new account.
If the explanation is too long for a snackbar we may need to break it out into a separate onboarding dialog that's opened by tapping the snackbar.
The snackbar should be shown starting from a hardcoded activation date ~ 6 months after this ticket's released. The expiry date should be ~ 12 months after this ticket's released.
Subtask of #2221.MailboxDaniel LublinDaniel Lublin2022-01-17https://code.briarproject.org/briar/briar/-/issues/2250Refuse to start app on Android 4 beyond expiry date2022-01-18T15:03:45ZakwizgranRefuse to start app on Android 4 beyond expiry dateWhen the expiry date for Android 4 has been reached the app should refuse to start. This can use a similar mechanism to the existing ExpiredActivity for debug builds.
We might want to provide a button that deletes the user's account, if...When the expiry date for Android 4 has been reached the app should refuse to start. This can use a similar mechanism to the existing ExpiredActivity for debug builds.
We might want to provide a button that deletes the user's account, if that's easy to achieve, or just let the user know that their account will be deleted when they uninstall the app.
Subtask of #2221.MailboxDaniel LublinDaniel Lublin2022-01-17https://code.briarproject.org/briar/briar/-/issues/2243Tests for OkHttp client calls2022-02-25T14:58:20ZakwizgranTests for OkHttp client callsCreate a basic unit or integration test for testing an OkHttp client call against a fake API endpoint provided by the test.
This will be the basis for testing methods that wrap OkHttp calls (eg #2183).Create a basic unit or integration test for testing an OkHttp client call against a fake API endpoint provided by the test.
This will be the basis for testing methods that wrap OkHttp calls (eg #2183).MailboxTorsten GroteTorsten Grote2022-01-17https://code.briarproject.org/briar/briar/-/issues/2242Migrate OkHttp to bramble-core2022-02-25T14:59:07ZakwizgranMigrate OkHttp to bramble-coreMailboxTorsten GroteTorsten Grote2022-01-03https://code.briarproject.org/briar/briar/-/issues/2234Abstract task for calling an API endpoint2022-06-17T13:34:16ZakwizgranAbstract task for calling an API endpointCreate an abstract task for calling an API endpoint. The task should block until the API call succeeds or permanently fails. Temporary failures should be retried automatically with backoff, and it should be possible to cancel the task be...Create an abstract task for calling an API endpoint. The task should block until the API call succeeds or permanently fails. Temporary failures should be retried automatically with backoff, and it should be possible to cancel the task between tries.Mailboxakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/2225Error handling for mailbox downloads2021-12-10T14:45:35ZakwizgranError handling for mailbox downloadsWhen communicating via mailboxes, the max latency and thus the retransmission interval are very long, so we need to be careful about any circumstances that could cause messages to be lost.
On the receiver side, if an error (such as an I...When communicating via mailboxes, the max latency and thus the retransmission interval are very long, so we need to be careful about any circumstances that could cause messages to be lost.
On the receiver side, if an error (such as an IO error, app shutdown, app crash or device crash) occurs while we're reading messages from a file, we need to ensure that the file can be read again after recovering from the error. Reading the file twice isn't possible with the current protocol stack because the pseudo-random tag at the start of the file is recognised on the first read and can't be recognised again.
To fix this we should divide the process of recognising a tag into two steps. The first step looks up the tag and returns the keys needed for authenticating and decrypting the stream header. The second step marks the tag as recognised and updates the reordering window.
When processing a file downloaded from a mailbox, we should defer the second step until the file has been completely processed.Mailboxhttps://code.briarproject.org/briar/briar/-/issues/2221Retire support for Android 42023-06-19T14:03:17ZakwizgranRetire support for Android 4We'll eventually need to drop support for Android 4 in order to be able to upgrade OkHttp (#2156). I don't think we should just raise our minSdkVersion and leave Android 4 users running an out-of-date version of Briar indefinitely. Inste...We'll eventually need to drop support for Android 4 in order to be able to upgrade OkHttp (#2156). I don't think we should just raise our minSdkVersion and leave Android 4 users running an out-of-date version of Briar indefinitely. Instead, we should set an expiry date and warn users that the app will stop working at that date, like we do with debug builds.
We should define a retirement period that ends at the expiry date, and release the following changes before the start of the retirement period, allowing enough time for most users to upgrade before the period starts:
* At the start of the retirement period, show a warning on Android 4 that Briar will stop working at the expiry date
* Refuse to start the app on Android 4 beyond the expiry date
The changes can be based on the existing code for expiring debug builds.
When the retirement period ends we can raise our min API level to 21 and upgrade OkHttp (and perhaps the emoji library, which also requires API 21 for the latest version, unless we've already resolved #2212 by switching to AppCompat for emoji).
If we release the changes above by the end of 2021, allow six months for users to upgrade before the retirement period starts, and allow another six months for the retirement period, then we can drop support for Android 4 at the end of 2022. (We can do everything faster than that if necessary, but I don't see any urgency.)
*Update:*
With !1577 and !1578 merged to master, the warning will show up on Android 4 on 2022-07-31. Briar will refuse to start on Android 4 on 2023-01-31.MailboxTorsten GroteTorsten Grote2023-01-31https://code.briarproject.org/briar/briar/-/issues/2156Upgrade OkHttp to 3.14.x2023-06-19T14:02:33ZakwizgranUpgrade OkHttp to 3.14.xhttps://square.github.io/okhttp/changelog_3x/#version-3130
OkHttp 3.12.x will receive critical bug fixes until the end of 2021. Newer versions drop support for Android 4, so when we upgrade we'll either need to drop support for Android ...https://square.github.io/okhttp/changelog_3x/#version-3130
OkHttp 3.12.x will receive critical bug fixes until the end of 2021. Newer versions drop support for Android 4, so when we upgrade we'll either need to drop support for Android 4 or restrict features that use HTTP (RSS feeds, mailbox) to Android 5+.
According to Google Play, 0.5% of devices running Briar use Android 4.
Depends on #2221.MailboxTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1811Update Bramble protocol stack to support syncing via mailbox2022-08-17T10:09:50ZakwizgranUpdate Bramble protocol stack to support syncing via mailboxWhen communicating via mailboxes, the max latency and thus the retransmission interval are very long, so we need to be careful about any circumstances that could cause messages to be lost.
On the sender side, if an error (such as an IO ...When communicating via mailboxes, the max latency and thus the retransmission interval are very long, so we need to be careful about any circumstances that could cause messages to be lost.
On the sender side, if an error (such as an IO error, app crash or device crash) occurs while we're writing messages to a file, we need to ensure that those messages can be sent again after recovering from the error. Ideally this should apply to acks too.
On the receiver side, if an error occurs while we're reading messages from a file, we need to ensure that the file can be read again after recovering from the error.Mailbox2022-10-31https://code.briarproject.org/briar/briar/-/issues/1808Download data from mailbox2022-08-17T10:10:55ZakwizgranDownload data from mailboxWrite backend code to download a file from the user's own mailbox or a contact's mailbox into a temporary directory, try to read a simplex stream from the local file, and delete the file from the mailbox and the temporary directory.
Dep...Write backend code to download a file from the user's own mailbox or a contact's mailbox into a temporary directory, try to read a simplex stream from the local file, and delete the file from the mailbox and the temporary directory.
Depends on #1804.Mailbox2022-10-31https://code.briarproject.org/briar/briar/-/issues/1807Upload data to mailbox2022-08-17T10:10:33ZakwizgranUpload data to mailboxWrite backend code to create a temporary file, write a simplex stream to the file, and upload the file to the user's own mailbox or a contact's mailbox.
Depends on #1804.Write backend code to create a temporary file, write a simplex stream to the file, and upload the file to the user's own mailbox or a contact's mailbox.
Depends on #1804.Mailbox2022-10-31