briar issueshttps://code.briarproject.org/groups/briar/-/issues2022-03-31T09:24:23Zhttps://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-mailbox/-/issues/99Improve successful linking screen2022-04-20T13:52:24ZSebastianImprove successful linking screenThat screen is currently a stub that still lacks the illustration and full text to be shown there.That screen is currently a stub that still lacks the illustration and full text to be shown there.Mailbox: PairingSebastianSebastianhttps://code.briarproject.org/briar/briar-mailbox/-/issues/98Map lifecycle / tor plugin states to translatable and useful strings shown in...2022-04-20T13:52:33ZSebastianMap lifecycle / tor plugin states to translatable and useful strings shown in StartupFragmentMailbox: PairingSebastianSebastianhttps://code.briarproject.org/briar/briar-mailbox/-/issues/97Design UI - fix bugs found during implementation2022-07-13T11:10:06ZSebastianDesign UI - fix bugs found during implementationMailboxhttps://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 connectionsakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/2290Mailbox client for our own mailbox2022-08-12T12:44:40ZakwizgranMailbox client for our own mailboxMailbox clients for communicating with our own mailbox and contacts' mailboxes are managed by a singleton mailbox client manager (#2228).
This ticket covers the client for communicating with our own mailbox. Some code will be shared wit...Mailbox clients for communicating with our own mailbox and contacts' mailboxes are managed by a singleton mailbox client manager (#2228).
This ticket covers the client for communicating with our own mailbox. Some code will be shared with the client for communicating with a contact's mailbox (#2289). The shared code is covered by #2229.
The client's connectivity check will use #2170.
* At any given time the client has zero or more contacts assigned for upload and zero or more contacts assigned for download
* Each contact assigned for upload has its own upload worker
* The client has a single download worker that's shared by all contacts assigned for download
* The client also has a single contact list worker
When the client is created:
* Create and start the contact list worker (#2294)
When the client is destroyed:
* Do all the stuff the superclass does when it's destroyed
* Destroy the contact list worker
When a contact is assigned for upload:
* Create and start the contact's upload worker (#2291)
When a contact is deassigned for upload:
* Destroy the contact's upload worker
When a contact is assigned for download:
* If this is the only contact assigned for download:
* Create and start the shared download worker (#2293)
When a contact is deassigned for download:
* If there are no more contacts assigned for download:
* Destroy the shared download workerMailbox: Manage mailbox connectionsakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/2289Mailbox client for a contact's mailbox2022-07-13T11:07:36ZakwizgranMailbox client for a contact's mailboxMailbox clients for communicating with our own mailbox and contacts' mailboxes are managed by a singleton mailbox client manager (#2228).
This ticket covers the client for communicating with a contact's mailbox. Some code will be shared...Mailbox clients for communicating with our own mailbox and contacts' mailboxes are managed by a singleton mailbox client manager (#2228).
This ticket covers the client for communicating with a contact's mailbox. Some code will be shared with the client for communicating with our own mailbox (#2290). The shared code is covered by #2229.
The client's connectivity check will use #2186.
* The client always has one contact assigned for upload
* At any given time the client may have one contact assigned for download, depending on whether we have our own mailbox
When the client is created:
* Create and start the upload worker (#2291)
When a contact is assigned for download:
* Create and start the download worker (#2292)
When a contact is deassigned for download:
* Destroy the download workerMailbox: Manage mailbox connectionshttps://code.briarproject.org/briar/briar-mailbox/-/issues/96Replace hardcoded strings in layouts2022-05-16T14:01:09ZSebastianReplace hardcoded strings in layoutsMailboxSebastianSebastianhttps://code.briarproject.org/briar/briar-mailbox/-/issues/94Add illustrations to onboarding screens2022-04-20T13:51:38ZSebastianAdd illustrations to onboarding screensMailbox: PairingSebastianSebastianhttps://code.briarproject.org/briar/briar-mailbox/-/issues/93NetworkOnMainThreadException in MailboxService#onDestroy()2022-06-06T13:52:17ZTorsten GroteNetworkOnMainThreadException in MailboxService#onDestroy()```ruby
W/o.b.m.c.l.LifecycleManagerImpl: [main] Error while stopping service AndroidTorPlugin
android.os.NetworkOnMainThreadException: null
at android.os.StrictMode$AndroidBlockGuardPolicy.onNetwork(StrictMode.java:1668)
...```ruby
W/o.b.m.c.l.LifecycleManagerImpl: [main] Error while stopping service AndroidTorPlugin
android.os.NetworkOnMainThreadException: null
at android.os.StrictMode$AndroidBlockGuardPolicy.onNetwork(StrictMode.java:1668)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:116)
at java.net.SocketOutputStream.write(SocketOutputStream.java:161)
at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)
at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
at net.freehaven.tor.control.TorControlConnection.sendAndWaitForResponse(TorControlConnection.java:192)
at net.freehaven.tor.control.TorControlConnection.setConf(TorControlConnection.java:394)
at net.freehaven.tor.control.TorControlConnection.setConf(TorControlConnection.java:348)
at org.briarproject.mailbox.core.tor.TorPlugin.stopService(TorPlugin.java:455)
at org.briarproject.mailbox.core.tor.AndroidTorPlugin.stopService(AndroidTorPlugin.java:115)
at org.briarproject.mailbox.core.lifecycle.LifecycleManagerImpl$stopAllServices$1.invoke(LifecycleManagerImpl.kt:203)
at org.briarproject.mailbox.core.lifecycle.LifecycleManagerImpl$stopAllServices$1.invoke(LifecycleManagerImpl.kt:202)
at org.briarproject.mailbox.core.lifecycle.LifecycleManagerImpl.run(LifecycleManagerImpl.kt:263)
at org.briarproject.mailbox.core.lifecycle.LifecycleManagerImpl.stopAllServices(LifecycleManagerImpl.kt:202)
at org.briarproject.mailbox.core.lifecycle.LifecycleManagerImpl.stopServices(LifecycleManagerImpl.kt:173)
at org.briarproject.mailbox.android.MailboxService.onDestroy(MailboxService.kt:140)
```Mailbox: Manage app lifecycleSebastianSebastianhttps://code.briarproject.org/briar/briar-mailbox/-/issues/92Dialog scrim color on dark theme2022-12-02T15:30:48ZSebastianDialog scrim color on dark themeDialogs as a scrim to the background to emphasize the modal trait of dialogs. That scrim is a half-transparent black on the light theme. See below for the effect that has, greying out the activity in the background. I believe for a dark ...Dialogs as a scrim to the background to emphasize the modal trait of dialogs. That scrim is a half-transparent black on the light theme. See below for the effect that has, greying out the activity in the background. I believe for a dark theme that scrim should be a transparent white (because a tranparent black doesn't have the same effect on a black background):
![scrim](/uploads/695ff2fd58b9acc66809ab12f16808fb/scrim.png)
We had the same thing with the desktop dialogs and we solved it like described above there, here's what it looks like then:
![scrim](/uploads/51242f52309013ad1ebab10c5bbb1e41/scrim.png)
Back then @ialokim found the description on the Material guide: https://code.briarproject.org/briar/briar-desktop/-/merge_requests/105#note_60781
I have to say the guide is unfortunately not 100% clear, as often, so it's not clear whether that is an example or the spec. Also it doesn't give examples for dark theme.MailboxSebastianSebastianhttps://code.briarproject.org/briar/briar-mailbox/-/issues/91Mailbox stores Tor state in different directory from app state2022-03-30T12:50:26ZakwizgranMailbox stores Tor state in different directory from app stateOn Debian, the mailbox stores its Tor state in `~/.config/.briar-mailbox` and the rest of the app state in `~/.local/share/briar-mailbox`. It would probably be better to keep the Tor state in a subdirectory of the app state so we can del...On Debian, the mailbox stores its Tor state in `~/.config/.briar-mailbox` and the rest of the app state in `~/.local/share/briar-mailbox`. It would probably be better to keep the Tor state in a subdirectory of the app state so we can delete the whole account more easily.MailboxDaniel LublinDaniel Lublinhttps://code.briarproject.org/briar/briar/-/issues/2269Use full camera preview when scanning QR codes2022-06-30T10:05:14ZakwizgranUse full camera preview when scanning QR codesThe QR code scanner only uses the upper half of the camera preview, as this is the only part that's visible when adding contacts in person. However, when pairing a mailbox the whole preview is visible, so the QR code may fail to scan if ...The QR code scanner only uses the upper half of the camera preview, as this is the only part that's visible when adding contacts in person. However, when pairing a mailbox the whole preview is visible, so the QR code may fail to scan if positioned in the middle of the preview.
We should either add a flag to control whether the whole preview is used, or (if testing on bad device combinations allows this), use the whole preview in both cases.
An example of a bad device combination is the Huawei Ascend Y330 showing the QR code and the Moto E3 scanning it.Mailbox: PairingDaniel LublinDaniel Lublinhttps://code.briarproject.org/briar/briar-mailbox/-/issues/90Wait for hidden service to be reachable before showing QR code2022-05-02T13:37:48ZakwizgranWait for hidden service to be reachable before showing QR codeMailbox: PairingTorsten GroteTorsten Grotehttps://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-mailbox/-/issues/87Don't autostart mailbox when user had actively stopped it before2022-07-13T11:11:47ZTorsten GroteDon't autostart mailbox when user had actively stopped it beforeThe Stopped state can be saved in shared preferences on the Android side. When the app opens and find it was stopped, we don't start the mailbox automatically, but show its state as stopped.The Stopped state can be saved in shared preferences on the Android side. When the app opens and find it was stopped, we don't start the mailbox automatically, but show its state as stopped.Mailbox: Manage app lifecycleSebastianSebastianhttps://code.briarproject.org/briar/briar-mailbox/-/issues/86Show a different notification when mailbox needs linking2022-07-13T11:14:11ZTorsten GroteShow a different notification when mailbox needs linkingWe auto-start the mailbox on boot and start the lifecycle. The foreground service notification should say something like "Please finish mailbox setup" instead of mailbox running.We auto-start the mailbox on boot and start the lifecycle. The foreground service notification should say something like "Please finish mailbox setup" instead of mailbox running.Mailbox: Manage app lifecycleSebastianSebastian