briar issueshttps://code.briarproject.org/groups/briar/-/issues2022-11-29T14:08:07Zhttps://code.briarproject.org/briar/briar/-/issues/2314Usability testing for mailbox connection issues2022-11-29T14:08:07ZakwizgranUsability testing for mailbox connection issuesTest that users understand Briar's mailbox status screen (#2172) and can use it to check whether the mailbox is reachable. Test that users understand the UX that warns about the mailbox being repeatedly unreachable (#2175), and that they...Test that users understand Briar's mailbox status screen (#2172) and can use it to check whether the mailbox is reachable. Test that users understand the UX that warns about the mailbox being repeatedly unreachable (#2175), and that they can use the troubleshooting wizard to resolve issues (#2309).Mailbox: Usability testinghttps://code.briarproject.org/briar/briar/-/issues/2311Remind user to wipe mailbox if it's unreachable when unpairing2022-05-02T16:06:29ZakwizgranRemind user to wipe mailbox if it's unreachable when unpairingIf we fail to tell the mailbox to wipe itself when unpairing, remind the user that they should wipe the mailbox next time they have access to it.If we fail to tell the mailbox to wipe itself when unpairing, remind the user that they should wipe the mailbox next time they have access to it.Mailbox: UnpairingTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar-mailbox/-/issues/105Limit the size of uploaded files2022-07-13T11:13:19ZakwizgranLimit the size of uploaded filesThe mailbox shouldn't allow clients to upload files larger than 1 MiB.The mailbox shouldn't allow clients to upload files larger than 1 MiB.Mailbox: File management APITorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/2309Troubleshooting wizard for own mailbox being unreachable2022-05-18T17:02:05ZakwizgranTroubleshooting wizard for own mailbox being unreachableDesign and implement a troubleshooting wizard to guide the user through the steps of diagnosing why their own mailbox is unreachable and fixing the problem.
The wizard will be reachable from the mailbox status page (#2172) when automati...Design and implement a troubleshooting wizard to guide the user through the steps of diagnosing why their own mailbox is unreachable and fixing the problem.
The wizard will be reachable from the mailbox status page (#2172) when automatic reachability checks repeatedly fail, or when the user triggers a manual reachability check which fails.
The UI for warning the user that their mailbox is unreachable (#2175) will guide the user to the status page where they'll be able to use the wizard.Mailbox: Status UI for Briar appTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar-desktop/-/issues/340Detect when LAN IP address changes2022-04-18T09:39:50ZakwizgranDetect when LAN IP address changesThis already works on Android, but how to do it on the desktop is an open question.This already works on Android, but how to do it on the desktop is an open question.https://code.briarproject.org/briar/briar/-/issues/2302Update contacts about change in mailbox versions that our mailbox (server) su...2022-08-16T13:49:46ZDaniel LublinUpdate contacts about change in mailbox versions that our mailbox (server) supports
When we connect to the Mailbox, we should get the fresh list of mailbox api versions that it supports. Then check it against the latest mailbox properties update sent to each contact, and send a new update if the serverSupports doesn't ...
When we connect to the Mailbox, we should get the fresh list of mailbox api versions that it supports. Then check it against the latest mailbox properties update sent to each contact, and send a new update if the serverSupports doesn't match.
Depends on https://code.briarproject.org/briar/briar/-/issues/2299 https://code.briarproject.org/briar/briar/-/issues/2261 https://code.briarproject.org/briar/briar/-/issues/2290Mailbox: Sync mailbox propertiesakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/2301Update contacts about change in mailbox versions that client supports2022-05-19T12:17:40ZDaniel LublinUpdate contacts about change in mailbox versions that client supportsOn startup we should compare the mailbox versions that we support against the latest mailbox properties update sent to each contact. For each contact which doesn't match, we need to send them an update with the new clientSupports.
Depen...On startup we should compare the mailbox versions that we support against the latest mailbox properties update sent to each contact. For each contact which doesn't match, we need to send them an update with the new clientSupports.
Depends on https://code.briarproject.org/briar/briar/-/issues/2261Mailbox: Sync mailbox propertiesDaniel LublinDaniel Lublinhttps://code.briarproject.org/briar/briar/-/issues/2300Show more information about startup failures2022-04-08T12:33:12ZakwizgranShow more information about startup failuresRecently we've had several reports of corrupt databases (StartResult#DB_ERROR). Because these errors prevent the app from starting, we can't use crash reports or user feedback to learn about the cause.
We should expose more information ...Recently we've had several reports of corrupt databases (StartResult#DB_ERROR). Because these errors prevent the app from starting, we can't use crash reports or user feedback to learn about the cause.
We should expose more information about startup failures in the UI. This will involve returning the information from LifecycleManager#startService() and then attaching it to the intent that launches StartupFailureActivity. StartupFailureActivity should allow the user to copy the information so they can send it to us.Android 1.4https://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/2298Fetch and store mailbox's supported API versions when pairing mailbox2022-05-16T13:59:54ZakwizgranFetch and store mailbox's supported API versions when pairing mailboxDepends on briar-mailbox#104.Depends on briar-mailbox#104.Mailbox: PairingDaniel LublinDaniel Lublinhttps://code.briarproject.org/briar/briar-mailbox/-/issues/104Include supported API versions in pairing response2022-07-13T11:14:30ZakwizgranInclude supported API versions in pairing responseUpdate the pairing endpoint to return the API versions supported by the mailbox, as a list of (major, minor) pairs.Update the pairing endpoint to return the API versions supported by the mailbox, as a list of (major, minor) pairs.Mailbox: PairingSebastianSebastianhttps://code.briarproject.org/briar/briar-mailbox/-/issues/103API endpoint for getting the API versions supported by the mailbox2022-07-13T11:14:54ZakwizgranAPI endpoint for getting the API versions supported by the mailboxThe endpoint should return a list of (major, minor) pairs.The endpoint should return a list of (major, minor) pairs.MailboxSebastianSebastianhttps://code.briarproject.org/briar/briar/-/issues/2297Adapt status screen when Briar is not connected to Tor2022-11-23T11:48:47ZTorsten GroteAdapt status screen when Briar is not connected to TorWe should track the Briar device's connectivity and show an appropriate status maybe similar to the screen that we show when we couldn't reach the mailbox for some time.
Related to #2175We should track the Briar device's connectivity and show an appropriate status maybe similar to the screen that we show when we couldn't reach the mailbox for some time.
Related to #2175Mailbox: Status UI for Briar appTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/2296Defer marking messages as sent/acked until file is uploaded2022-05-16T14:00:06ZakwizgranDefer marking messages as sent/acked until file is uploadedWhen sending data via a mailbox, we should defer marking messages as sent/acked until the file containing the encrypted data has been successfully uploaded to the mailbox.
This complicates the sync layer a bit, but it means we don't hav...When sending data via a mailbox, we should defer marking messages as sent/acked until the file containing the encrypted data has been successfully uploaded to the mailbox.
This complicates the sync layer a bit, but it means we don't have to keep persistent records of sent/acked messages in case of a crash (#2226), or of files awaiting upload in case of a crash or a connectivity loss (#2230), so the design is simpler overall.
When the sync layer is writing messages and acks for a mailbox session, instead of recording the sent/acked message IDs in the DB it should record them via a deferred send handler. This handler will be provided by the upload worker that will subsequently upload the file (#2291). If the upload is successful, the worker will then use the IDs recorded by the handler to mark the messages as sent/acked in the DB.
This approach relies on the fact that there will be one upload worker per contact, and thus messages that have been sent/acked but not yet marked as such in the DB will not be sent/acked concurrently in another mailbox session. (They may be sent/acked concurrently in another session via a low-latency transport, but this is what we want to happen if a low-latency connection becomes available during a mailbox upload.)
This ticket replaces #2226 and #2230, which unfortunately have already been implemented.Mailbox: Manage mailbox connectionsakwizgranakwizgranhttps://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/dont-kill-me-lib/-/issues/1Backport Huawei power management fix2022-04-29T14:38:06ZTorsten GroteBackport Huawei power management fixhttps://code.briarproject.org/briar/briar/-/merge_requests/1602https://code.briarproject.org/briar/briar/-/merge_requests/1602https://code.briarproject.org/briar/briar/-/issues/2294Mailbox worker for updating our own mailbox's contact list2022-08-12T12:44:41ZakwizgranMailbox worker for updating our own mailbox's contact listThe mailbox client for our own mailbox (#2290) has a worker for updating the mailbox's contact list. The worker is started when the client is created and destroyed when the client is destroyed.
The worker runs in parallel with the uploa...The mailbox client for our own mailbox (#2290) has a worker for updating the mailbox's contact list. The worker is started when the client is created and destroyed when the client is destroyed.
The worker runs in parallel with the upload and download workers. If a task belonging to an upload or download worker tries to access the inbox or outbox of a contact that hasn't been added to the mailbox's contact list, the task will fail and retry until the mailbox's contact list is brought up to date. If a task belonging to an upload or download worker tries to access the inbox or outbox of a contact that's been removed from the mailbox's contact list, the task will fail and retry until the contact is deassigned from the client, causing the task to be cancelled.
The worker keeps a reference to its current API task, if any, so the task can be cancelled when the worker is destroyed.
The worker's lifecycle is:
1. Check connectivity
2. Fetch and store the mailbox's supported API versions (#2299, #2302)
3. Reconcile the mailbox's contact list with the local contact list (#2182, #2183, #2187)
3. Wait for the local contact list to change
The worker can be in the following states:
* Waiting for connectivity check
* Fetching API versions
* Updating contact list
* Waiting for changes
When the worker is created:
* Set the current state to "waiting for connectivity check"
* Call the client's connectivity check method
When the worker is destroyed:
* Set the current state to "destroyed"
* Cancel the current API task, if any
When a connectivity check succeeds:
* If the current state is "waiting for connectivity check":
* Set the current state to "updating contact list"
* Start a fetch-api-versions task
When a fetch-api-versions task succeeds:
* If the current state is "fetching API versions":
* Store the mailbox's supported API versions
* Start a get-contact-list task
When a get-contact-list task succeeds:
* If the current state is "updating contact list":
* Load the local contact list
* Compare the remote contact list to the local contact list
* Load the mailbox properties for any contacts that are in the local list but not the remote list
* If any contacts need to be added or deleted:
* Start an add-contact or delete-contact task
* Else:
* Set the current state to "waiting for changes"
When an add-contact or delete-contact task succeeds:
* If the current state is "updating contact list":
* If any more contacts need to be added or deleted:
* Start an add-contact or delete-contact task
* Else:
* Start a get-contact-list task
When an event indicates that a contact has been added or removed:
* If the current state is "waiting for changes":
* Set the current state to "updating contact list"
* Start a get-contact-list taskMailbox: Manage mailbox connectionsakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/2293Mailbox download worker for our own mailbox2022-08-05T13:40:22ZakwizgranMailbox download worker for our own mailboxThe mailbox client for our own mailbox (#2290) has a single download worker that's shared between all contacts assigned to the mailbox for download. The worker is started when the first contact is assigned for download and destroyed when...The mailbox client for our own mailbox (#2290) has a single download worker that's shared between all contacts assigned to the mailbox for download. The worker is started when the first contact is assigned for download and destroyed when the last contact is deassigned for download or the client is destroyed.
The worker keeps a reference to its current API task, if any, so the task can be cancelled when the worker is destroyed.
The worker's lifecycle is:
1. Check connectivity
2. Download and delete all files from all contacts' outboxes
3. Wait until our hidden service has been reachable for at least the overlap duration
4. Download and delete all files from all contacts' outboxes again, in case any arrived during the overlap period
Downloading and deleting files is more complex for this worker than for the download worker for a contact's mailbox (#2292), firstly because this worker needs to download files from multiple outboxes, and secondly because it needs to ensure fairness between contacts, so that a malicious contact can't deny service to other contacts by flooding its own outbox with files.
The worker ensures fairness in two ways:
1. To ensure that every contact receives service even if some contacts have flooded their own outboxes, the worker lists the outboxes that contain files, lists the files in each of those outboxes, then downloads from the outboxes in round-robin order.
2. To ensure that every contact receives service even if they upload files to their outboxes after the initial check, and if some contacts had already flooded their own outboxes at the time of the initial check, the worker restarts the round-robin after downloading a certain number of files: it lists the outboxes that contain files, lists the files in each of those outboxes, then downloads from the outboxes in round-robin order.
The worker can be in the following states:
* Waiting for connectivity check
* First download
* Waiting for hidden service
* Second download
* Destroyed
When the worker is created:
* Set the current state to "waiting for connectivity check"
* Call the client's connectivity check method
When the worker is destroyed:
* Set the current state to "destroyed"
* Cancel the current API task, if any
When a connectivity check succeeds:
* If the current state is "waiting for connectivity check":
* Set the current state to "first download"
* Start a find-outboxes-with-available-files task (#2170)
When a find-outboxes-with-available-files task succeeds:
* If the current state is "first download" or "second download":
* If there are any outboxes with available files:
* Start a list-outbox task for the first outbox with available files
* Else if the current state is "first download":
* Set the current state to "waiting for hidden service"
When a list-outbox tasks succeeds:
* If the current state is "first download" or "second download":
* If there are files in the outbox:
* Sort the files by timestamp
* Add the file list to the round-robin queue
* If there are more outboxes with available files:
* Start a list-outbox task for the next outbox with available files
* Else if there are any files in the round-robin queue:
* Trim the round-robin queue to ensure fairness (see item 2 above)
* Start a download-file task for the first file in the round-robin queue (#2232)
* Else if the current state is "first download":
* Set the current state to "waiting for hidden service"
* (Note: It's surprising if we reach this branch, and should probably be logged. The find-outboxes-with-available-files task found some outboxes, but after listing those outboxes we didn't find any files)
When a download-file task succeeds:
* Pass the local file's path to the mailbox plugin to get a transport connection reader
* Decorate the transport connection reader to handle disposal
* Pass the decorated transport connection reader to the connection manager
* Data will be read from the local file asynchronously
* If the current state is "first download" or "second download":
* Start a delete-file task for the current file (#2233)
When the transport connection reader is disposed of:
* Delete the local file
When a delete-file task succeeds or tolerably fails:
* If the current state is "first download" or "second download":
* If there are more files in the round-robin queue:
* Start a download-file task for the next file
* Else:
* Start a find-outboxes-with-available-files task
When an event indicates that the hidden service has been reachable for at least the overlap duration:
* If the current state is "waiting for hidden service":
* Set the current state to "second download"
* Start a find-outboxes-with-available-files taskMailbox: Manage mailbox connectionsakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/2292Mailbox download worker for a contact's mailbox2022-08-05T13:38:01ZakwizgranMailbox download worker for a contact's mailboxWhen a contact is assigned to a contact's mailbox for download, the mailbox client (#2289) creates a download worker. The worker is destroyed when the contact is unassigned for download or the client is destroyed.
The worker keeps a ref...When a contact is assigned to a contact's mailbox for download, the mailbox client (#2289) creates a download worker. The worker is destroyed when the contact is unassigned for download or the client is destroyed.
The worker keeps a reference to its current API task, if any, so the task can be cancelled when the worker is destroyed.
The worker's lifecycle is:
1. Check connectivity
2. Download and delete all files from the inbox
3. Wait until our hidden service has been reachable for at least the overlap duration
4. Download and delete all files from the inbox again, in case any arrived during the overlap period
The worker can be in the following states:
* Waiting for connectivity check
* First download
* Waiting for hidden service
* Second download
* Destroyed
When the worker is created:
* Set the current state to "waiting for connectivity check"
* Call the client's connectivity check method
When the worker is destroyed:
* Set the current state to "destroyed"
* Cancel the current API task, if any
When a connectivity check succeeds:
* If the current state is "waiting for connectivity check":
* Set the current state to "first download"
* Start a list-inbox task
When a list-inbox tasks succeeds:
* If the current state is "first download" or "second download":
* If there are files in the inbox:
* Sort the files by timestamp
* Start a download-file task for the first file (#2232)
* Else if the current state is "first download":
* Set the current state to "waiting for hidden service"
When a download-file task succeeds:
* Pass the local file's path to the mailbox plugin to get a transport connection reader
* Decorate the transport connection reader to handle disposal
* Pass the decorated transport connection reader to the connection manager
* Data will be read from the local file asynchronously
* If the current state is "first download" or "second download":
* Start a delete-file task for the current file (#2233)
When the transport connection reader is disposed of:
* Delete the local file
When a delete-file task succeeds or tolerably fails:
* If the current state is "first download" or "second download":
* If there are more files to download:
* Start a download-file task for the next file
* Else:
* Start a list-inbox task
When an event indicates that the hidden service has been reachable for at least the overlap duration:
* If the current state is "waiting for hidden service":
* Set the current state to "second download"
* Start a list-inbox taskMailbox: Manage mailbox connectionsakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/2291Mailbox upload worker2022-08-05T14:19:56ZakwizgranMailbox upload workerThe upload worker implementation is shared between the client for our own mailbox (#2290) and the client for a contact's mailbox (#2289). The worker's lifecycle is managed by the mailbox client, which in turn is managed by the mailbox cl...The upload worker implementation is shared between the client for our own mailbox (#2290) and the client for a contact's mailbox (#2289). The worker's lifecycle is managed by the mailbox client, which in turn is managed by the mailbox client manager (#2228).
Each upload worker is associated with a contact that has been assigned to a mailbox for upload. When a contact is reassigned to a different mailbox for upload, the old worker is destroyed and a new worker is created.
The worker can be in the following states:
* Checking for data to send
* Waiting for data to send
* Waiting for connectivity check
* Writing and uploading
* Destroyed
When the worker is created:
* Set the current state to "checking for data to send"
* Check for data to send
When the worker is destroyed:
* Set the current state to "destroyed"
* Cancel the current upload task, if any
To check for data to send:
* Load the time when data will next be ready to send to the contact
* If data is ready to send now:
* Set the current state to "waiting for connectivity check"
* Call the client's connectivity check method
* Else:
* Set the current state to "waiting for data to send"
* Schedule a wakeup task for the time when data will next be ready to send
When an event indicates that new data may be ready to send:
* If the current state is "waiting for data to send":
* Cancel the wakeup task
* Set the current state to "checking for data to send"
* Check for data to upload
When a wakeup task runs:
* If the current state is "waiting for data to send":
* Set the current state to "checking for data to send"
* Check for data to upload
When a connectivity check succeeds:
* If the current state is "waiting for connectivity check":
* Set the current state to "writing and uploading"
* Write and upload a file
To write and upload a file:
* Create a temporary file in the upload directory
* Pass the file's path to the mailbox plugin to get a transport connection writer
* Decorate the transport connection writer to handle disposal
* Create a deferred send handler
* Pass the decorated transport connection writer and the deferred send handler to the connection manager
* Data will be written to the file asynchronously
* The IDs of any sent/acked messages will be recorded by the deferred send handler
When the transport connection writer is disposed of:
* If the write succeeded:
* Start an upload task to upload the file to the mailbox (#2231)
* Else:
* Delete the file
* Set the current state to "checking for data to send"
* Check for data to send
When an upload task succeeds:
* Retrieve the sent/acked message IDs from the deferred send handler
* Mark the messages as sent/acked
* Delete the file
* Set the current state to "checking for data to send"
* Check for data to send
When an upload task is cancelled:
* Delete the fileMailbox: Manage mailbox connectionsakwizgranakwizgran