briar issueshttps://code.briarproject.org/briar/briar/-/issues2021-12-13T14:23:36Zhttps://code.briarproject.org/briar/briar/-/issues/2244Reduce bandwidth used by polling2021-12-13T14:23:36ZakwizgranReduce bandwidth used by pollingPolling for connections to contacts via Tor uses a significant amount of bandwidth. We could save bandwidth by polling unreachable contacts less often, or by polling less often (perhaps not at all) if we're confident that contacts can co...Polling for connections to contacts via Tor uses a significant amount of bandwidth. We could save bandwidth by polling unreachable contacts less often, or by polling less often (perhaps not at all) if we're confident that contacts can connect to us when they come online (ie if our hidden service is reachable).
For short-range transports, polling contacts in a batch may use less battery than polling them at contact-specific intervals. It may be possible to meet the needs of Tor and short-range transports by polling in batches, but not including unreachable contacts in every batch.https://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/2241Add marker interface to `ContactId` and `PendingContactId`2022-02-28T15:52:29ZMikolai GütschowAdd marker interface to `ContactId` and `PendingContactId`Since we are trying to show both in the same list for https://code.briarproject.org/briar/briar-desktop/-/merge_requests/51, it would be nice to have a common interface for them. It could be named `BaseContactId` for example. If you have...Since we are trying to show both in the same list for https://code.briarproject.org/briar/briar-desktop/-/merge_requests/51, it would be nice to have a common interface for them. It could be named `BaseContactId` for example. If you have no objections, we would happily add the respective code in a MR.https://code.briarproject.org/briar/briar/-/issues/2240Compression so heavy2021-12-10T10:37:42ZJoan SinglaCompression so heavySend images on briar for android is nearly unusefull because the receiver receive an image with a big quality loss.Send images on briar for android is nearly unusefull because the receiver receive an image with a big quality loss.https://code.briarproject.org/briar/briar/-/issues/2239GlideApp class removed2022-02-25T15:01:19ZNico HennrichGlideApp class removedI can't build briar anymore as the class org.briarproject.briar.android.conversation.glide.GlideApp is missing.
This class is referenced in six class (eg ImageFragment)I can't build briar anymore as the class org.briarproject.briar.android.conversation.glide.GlideApp is missing.
This class is referenced in six class (eg ImageFragment)https://code.briarproject.org/briar/briar/-/issues/2238Upgrade h22023-09-07T14:13:30ZSebastianUpgrade h2While working on https://code.briarproject.org/briar/briar-mailbox/-/merge_requests/46 we discovered some things relevant to upgrading H2 in briarWhile working on https://code.briarproject.org/briar/briar-mailbox/-/merge_requests/46 we discovered some things relevant to upgrading H2 in briarhttps://code.briarproject.org/briar/briar/-/issues/2237Pending contact list doesn't show "No internet connection" if list contains f...2021-12-01T10:43:02ZakwizgranPending contact list doesn't show "No internet connection" if list contains failed pending contactsIf the pending contact list contains a mixture of failed and not-failed pending contacts, the "No internet connection" snackbar isn't shown when the device is offline. If the failed pending contacts are removed, leaving only not-failed o...If the pending contact list contains a mixture of failed and not-failed pending contacts, the "No internet connection" snackbar isn't shown when the device is offline. If the failed pending contacts are removed, leaving only not-failed ones, the snackbar appears.https://code.briarproject.org/briar/briar/-/issues/2236Contact list doesn't scroll to top after adding contact2021-11-30T12:19:21ZakwizgranContact list doesn't scroll to top after adding contactA user reported that the contact list doesn't scroll to the top after adding a contact, so the new contact isn't visible. This makes it unclear whether the contact was added or not.
Similarly, the list doesn't scroll to the top after re...A user reported that the contact list doesn't scroll to the top after adding a contact, so the new contact isn't visible. This makes it unclear whether the contact was added or not.
Similarly, the list doesn't scroll to the top after returning from a private conversation. If messages have been sent or received in the conversation, moving it to the top of the list, then it may no longer be visible when returning to the contact list.https://code.briarproject.org/briar/briar/-/issues/2235"Contact deleted" toast is not shown2021-11-30T12:16:54Zakwizgran"Contact deleted" toast is not shownA user reported that the "contact deleted" toast was not shown after deleting a contact. (The pending contacts snackbar was visible, in case that's relevant.)A user reported that the "contact deleted" toast was not shown after deleting a contact. (The pending contacts snackbar was visible, in case that's relevant.)https://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/2233Method for deleting a file from a mailbox2022-03-25T17:18:28ZakwizgranMethod for deleting a file from a mailboxDepends on briar-mailbox#3, briar-mailbox#53.Depends on briar-mailbox#3, briar-mailbox#53.Mailbox: File management APITorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/2232Method for downloading a file from a mailbox2022-03-25T17:18:28ZakwizgranMethod for downloading a file from a mailboxDepends on briar-mailbox#3, briar-mailbox#52.Depends on briar-mailbox#3, briar-mailbox#52.Mailbox: File management APITorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/2231Method for uploading a file to a mailbox2022-03-25T16:03:18ZakwizgranMethod for uploading a file to a mailboxDepends on briar-mailbox#3, briar-mailbox#54.Depends on briar-mailbox#3, briar-mailbox#54.Mailbox: File management APITorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/2230Add DB methods for tracking pending uploads2022-03-30T14:29:01ZakwizgranAdd DB methods for tracking pending uploadsAdd database methods for storing the contact ID and filename of pending mailbox uploads. It should be possible to query by contact ID (for use when a mailbox becomes reachable and we want to retry failed uploads) and to delete by contact...Add database methods for storing the contact ID and filename of pending mailbox uploads. It should be possible to query by contact ID (for use when a mailbox becomes reachable and we want to retry failed uploads) and to delete by contact ID and filename (for use when an upload succeeds).Mailbox: Manage mailbox connectionsTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/2229Mailbox client superclass2022-06-20T11:20:55ZakwizgranMailbox client superclassMailbox clients for communicating with our own mailbox and contacts' mailboxes are managed by a singleton mailbox client manager (#2228).
We'll need different client implementations for our own mailbox (#2290) and contacts' mailboxes (#...Mailbox clients for communicating with our own mailbox and contacts' mailboxes are managed by a singleton mailbox client manager (#2228).
We'll need different client implementations for our own mailbox (#2290) and contacts' mailboxes (#2289), but there will be a shared interface and some shared code. This ticket covers the code shared between the client for our own mailbox and the client for a contact's mailbox.
Interface:
* The manager can create and destroy clients
* The manager can assign/deassign contacts for upload or download
* The client's upload and download workers can request connectivity checks
Implementation:
* At any given time the client may have multiple upload workers and/or a single download worker
* The client has a connectivity check method, which takes an observer as an argument
* The client stores the time of the latest successful connectivity check, a reference to the current connectivity check task, if any, and a list of observers waiting for the result of a connectivity check
When the client is destroyed:
* If a connectivity check task is running:
* Cancel the connectivity check task
* Destroy the upload workers, if any
* Destroy the download worker, if any
When the connectivity check method is called:
* Compare the current time to the time of the latest successful connectivity check
* If a connectivity check has recently succeeded:
* Notify the observer
* Else if a connectivity check task is running:
* Add the observer to the list of waiting observers
* Else:
* Add the observer to the list of waiting observers
* Start a connectivity check task
When a connectivity check task succeeds:
* Update the time of the latest successful connectivity check
* Notify any waiting observers
* Clear the list of waiting observersMailbox: Manage mailbox connectionsakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/2228Mailbox client manager2022-08-16T14:20:43ZakwizgranMailbox client manager* Create a singleton mailbox client manager
* This component manages a set of mailbox clients (#2229): one client for each mailbox we know about
* The manager creates the clients when we come online and destroys them when we go offline
*...* Create a singleton mailbox client manager
* This component manages a set of mailbox clients (#2229): one client for each mailbox we know about
* The manager creates the clients when we come online and destroys them when we go offline
* The manager is responsible for assigning contacts to mailboxes for upload and/or download - so each client has a set of contacts assigned for upload and a (possibly different) set of contacts assigned for download
* These assignments can change based on pairing/unpairing a mailbox, learning which API versions our own mailbox supports, a contact being added/removed, or receiving new mailbox properties from a contact
* The assignments don't change based on connecting to a contact or disconnecting from a contact
* A contact's mailbox is "usable" if it supports an API version that we and the contact can both use, according to our hardcoded client-supported versions and the latest server-supported and client-supported versions received from the contact
* Our own mailbox is "usable" by a contact if it supports an API version that we and the contact can both use, according to our hardcoded client-supported versions, the latest server-supported versions fetched from our own mailbox, and the latest client-supported versions received from the contact
* If we have a mailbox, we always have a client for it regardless of whether our hardcoded client-supported versions are compatible with the latest server-supported versions fetched from the mailbox
* If a contact has a mailbox, we only have a client for it if it's usable
When we come online:
* For each contact:
* If the contact has a usable mailbox:
* Create a client for the contact's mailbox
* Assign the contact to the contact's mailbox for upload
* If we don't have a mailbox that's usable by the contact:
* Assign the contact to the contact's mailbox for download
* If we have our own mailbox:
* Create a client for our own mailbox
* For each contact:
* If our own mailbox is usable by the contact:
* Assign the contact to our own mailbox for download
* If the contact doesn't have a usable mailbox:
* Assign the contact to our own mailbox for upload
When we go offline:
* Destroy all clients
When we pair a mailbox:
* If we're online:
* Create a client for our own mailbox
* For each contact:
* If the contact has a usable mailbox:
* If our own mailbox is usable by the contact:
* Reassign the contact from the contact's mailbox to our own mailbox for download
* (The contact remains assigned to the contact's mailbox for upload)
* Else, if our own mailbox is usable by the contact:
* Assign the contact to our own mailbox for upload and download
When we unpair a mailbox:
* If we're online:
* For each contact:
* If the contact has a usable mailbox:
* If the contact is assigned to our own mailbox for download:
* Reassign the contact from our own mailbox to the contact's mailbox for download
* (The contact is already assigned to the contact's mailbox for upload)
* Destroy the client for our own mailbox
When a contact is added:
* Assumption: the contact has no mailbox properties yet, as the event informing us of the contact's first mailbox update is always delivered after the event informing us that the contact was added
* Wait until we receive the contact's first mailbox update before deciding how to assign the contact for upload and download
When a contact is removed:
* If we're online:
* If we have a client for the contact's mailbox:
* Destroy the client for the contact's mailbox
* If the contact is assigned to our own mailbox for download:
* Deassign the contact from our own mailbox for download
* If the contact is assigned to our own mailbox for upload:
* Deassign the contact from our own mailbox for upload
When we receive a mailbox update from a contact:
* If we're online:
* If the contact didn't previously have a usable mailbox and now has one:
* Create a client for the contact's mailbox
* If we have a mailbox that's usable by the contact:
* Reassign the contact from our own mailbox to the contact's mailbox for upload
* (The contact remains assigned to our own mailbox for download)
* Else:
* Assign the contact to the contact's mailbox for upload and download
* Else if the contact previously had a usable mailbox and no longer has one:
* If we have a mailbox that's usable by the contact:
* Reassign the contact from the contact's mailbox to our own mailbox for upload
* (The contact remains assigned to our own mailbox for download)
* Destroy the client for the contact's mailbox
* Else if the contact previously had a usable mailbox and now has a different mailbox that's also usable:
* Destroy the client for the contact's mailbox
* Create a new client for the contact's mailbox
* Assign the contact to the contact's mailbox for upload
* If we don't have a mailbox that's usable by the contact:
* Assign the contact to the contact's mailbox for downloadMailbox: Manage mailbox connectionsakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/2227some RSS feeds are not detected2022-02-28T22:03:08ZJeremie Larivieresome RSS feeds are not detectedBriar gives an error when importing Some feeds, specifically several on Substack, e.g. https://edwardsnowden.substack.com/ or https://cryptobeat.substack.com/.
Substack seems to have /feed , /feed.xml , /feed.rss , and none of those wo...Briar gives an error when importing Some feeds, specifically several on Substack, e.g. https://edwardsnowden.substack.com/ or https://cryptobeat.substack.com/.
Substack seems to have /feed , /feed.xml , /feed.rss , and none of those work for me in Briar. Substack's support said I should reach out to Briar since the substack feeds work in other readers they tried.
I haven't had an error on other feeds I've tried, it imports both RSS & Atom from Tails' blog (https://tails.boum.org/news/index.en.rss or https://tails.boum.org/news/index.en.atom)
It also works with Signal & FlowCrypt's blogs (https://signal.org/blog/rss.xml and https://flowcrypt.com/blog/feed.xml).https://code.briarproject.org/briar/briar/-/issues/2226Error handling for mailbox uploads2022-04-19T16:11:45ZakwizgranError handling for mailbox uploadsWhen communicating via mailboxes, the max latency and thus the retransmission interval are 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...When communicating via mailboxes, the max latency and thus the retransmission interval are 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 shutdown, app crash or device crash) occurs while we're writing messages and acks to a file, we need to ensure that those messages and acks can be sent again after recovering from the error.
We can do this by generating a unique ID for the sync session and recording the IDs of any messages sent or acked in that session. This state can be deleted when the session completes successfully. At the next startup, if we find this session state in the DB we know that the session didn't complete successfully, so we mark the messages and acks as unsent.
We also need to handle errors that occur after the file has been created but before it's been uploaded. We can do this by storing the contact ID and filename in the DB before starting the session and removing them when the upload completes successfully (#2230). Next time we come online, if we find any upload state in the DB we know that the corresponding uploads didn't complete successfully, so we queue the files for upload. We should use the DB for this, rather storing the files in a separate upload directory per contact, to avoid leaking metadata to the filesystem about which uploads are destined for which contacts.
We should store the contact ID and filename before starting the sync session, so that there's no gap where the DB doesn't contain a record of the incomplete session/upload. If a crash happens during the session we may end up marking the messages and acks in the session as unsent as well as queueing the (possibly incomplete) file for upload. This is acceptable - the receiver should be able to handle the (possibly incomplete) file and another file containing the same messages and acks. Similarly, if the upload completes successfully but a crash happens before we remove the contact ID and filename from the DB, it's acceptable to upload the file again at the next startup, as the receiver should be able to handle the duplicate file.
It's still possible for the file to be lost after a successful upload, but losses beyond that point are handled by different mechanisms (#2191, #2192, #2225).
Depends on #2230.Mailbox: Manage mailbox connectionsakwizgranakwizgran2022-01-03https://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.Mailbox