briar issueshttps://code.briarproject.org/groups/briar/-/issues2020-12-10T16:59:05Zhttps://code.briarproject.org/briar/briar/-/issues/1660Collapse the feedback categories and remember choices2020-12-10T16:59:05ZGhost UserCollapse the feedback categories and remember choicesYou can sent the feedbacks in the app. The problem you can disable the sending of data for some categories. But I always have to scroll down for each category. Please make it better e.g. add an arrow button if users want to see what deta...You can sent the feedbacks in the app. The problem you can disable the sending of data for some categories. But I always have to scroll down for each category. Please make it better e.g. add an arrow button if users want to see what details are being sent. Then click on the arrow button.
I think it would be very good if the last setting remembers itself and is not hidden by default. I know some users who find it so much more intimate.
Tested with Briar 1.2.4 versionhttps://code.briarproject.org/briar/briar/-/issues/1858Sending feedback/crash reports times out with many contacts2020-12-10T15:28:58ZTorsten GroteSending feedback/crash reports times out with many contactsWhen sending feedback through the app or a crash report after the app starts, often fails with a `SocketTimeoutException: Read timed out` when there's lots of contacts (~100 here).
It might be that TorPlugin doesn't work as expected wh...When sending feedback through the app or a crash report after the app starts, often fails with a `SocketTimeoutException: Read timed out` when there's lots of contacts (~100 here).
It might be that TorPlugin doesn't work as expected when there's that many circuits being built all the time.https://code.briarproject.org/briar/briar/-/issues/1857Statistics screen2020-12-09T17:01:45ZakwizgranStatistics screenA user asked for a statistics screen showing how many messages are waiting to be sent, and when messages have been successfully sent and received.
Possibly related to #26.A user asked for a statistics screen showing how many messages are waiting to be sent, and when messages have been successfully sent and received.
Possibly related to #26.https://code.briarproject.org/briar/briar/-/issues/1447Core API for observing a message graph2020-12-08T12:17:23ZakwizgranCore API for observing a message graphThe core API exposes methods for getting a snapshot of the message graph in a group, such as `DatabaseComponent#getMessageIds()` and `DatabaseComponent#getDependencies()`, and events for learning about changes to the message graph, such ...The core API exposes methods for getting a snapshot of the message graph in a group, such as `DatabaseComponent#getMessageIds()` and `DatabaseComponent#getDependencies()`, and events for learning about changes to the message graph, such as `MessageAddedEvent` and `MessageStateChangedEvent` at the sync layer, or `PrivateMessageReceivedEvent` at the client layer.
The UI uses a combination of asynchronous DB queries and events to maintain a view of the message graph. Using the data attached to events to update the UI is more efficient than triggering a DB query for every event, but it causes a lot of complexity in the UI code because updates may happen concurrently with asynchronous loads (see #705).
All interactions between the UI and the DB are funnelled through the single-threaded DatabaseExecutor, mainly to ensure that queries return their results to the UI in the same order as the queries were started. The database allows read-only transactions to run concurrently, but queries running on the DatabaseExecutor can't take advantage of this because the executor is single-threaded.
If we could provide a better API for observing a message graph then we might be able to simplify the UI code and perhaps even improve DB performance by allowing more queries to run concurrently.
The new API should allow an observer to register an interest in a group's message graph and receive an initial snapshot of the graph, followed by an ordered series of updates when the graph changes. An observer registered from the UI will need to process the observations on the UI thread. As long as the core delivers the observations in order it should be easy to move them onto the UI thread in the same order.
We also need a way to register multiple observers that are ordered with respect to each other, so that we can create UI components that represent multiple groups, such as a conversation containing private messages, invitations, etc.
To ensure ordering, the DB will need to register any changes made by a transaction before releasing the DB lock. Events attached to transactions aren't currently suitable for communicating ordered changes because they're broadcast after releasing the DB lock, so two transactions that commit their changes in the order A, B may broadcast their events in the order B, A. But communicating changes to other components while holding the DB lock would have the potential to cause deadlock.
It might be possible to modify the event broadcasting logic so that events are registered before releasing the lock and broadcast afterwards, ensuring the broadcast order is consistent with the commit order. Alternatively we could create a separate mechanism for registering and communicating ordered changes.https://code.briarproject.org/briar/briar/-/issues/1846Refactor image compression code for reuse outside messaging client2020-12-07T11:49:19ZakwizgranRefactor image compression code for reuse outside messaging clientFactor out AttachmentCreationTask#compressImage() so it can be reused when storing the user's profile picture.
Subtask of #214.Factor out AttachmentCreationTask#compressImage() so it can be reused when storing the user's profile picture.
Subtask of #214.Profile picturesSebastianSebastian2021-01-31https://code.briarproject.org/briar/briar/-/issues/1838Show a bomb icon on messages with self-destruct timers2020-12-03T14:02:14ZakwizgranShow a bomb icon on messages with self-destruct timersSubtask of #804Subtask of #804Self-destructing messagesTorsten GroteTorsten Grote2021-01-31https://code.briarproject.org/briar/briar/-/issues/1852A blog comment should have a higher timestamp than the post/comment it replie...2020-12-02T12:27:25ZakwizgranA blog comment should have a higher timestamp than the post/comment it replies toWhen devices have inaccurate clocks, a blog comment can have a lower timestamp than the post/comment it replies to. We should fake the timestamp in this situation to preserve causal order, like we do when replying to forum posts.When devices have inaccurate clocks, a blog comment can have a lower timestamp than the post/comment it replies to. We should fake the timestamp in this situation to preserve causal order, like we do when replying to forum posts.https://code.briarproject.org/briar/briar-manual/-/issues/5Prepare manual for translation2020-12-01T14:00:23ZCleopatraPrepare manual for translationCleopatraCleopatrahttps://code.briarproject.org/briar/website/-/issues/27Improve footer2020-12-01T13:33:10ZCleopatraImprove footerCan we add links to the following pages to the footer?
* Newsletter subscribe form
* News:
- Social media links
- Blog
- Press
* Get involved:
- Donate
- Contribute
- Jobs
...Can we add links to the following pages to the footer?
* Newsletter subscribe form
* News:
- Social media links
- Blog
- Press
* Get involved:
- Donate
- Contribute
- Jobs
* Legal:
- Copyright
- Privacy
- Code of Conduct
- License
* Support:
- FAQs
- Documentation
- ContactCleopatraCleopatrahttps://code.briarproject.org/briar/briar/-/issues/1831Update private group sharing client to include a self-destruct timer in each ...2020-11-30T12:45:14ZakwizgranUpdate private group sharing client to include a self-destruct timer in each messageSubtask of #804Subtask of #804Self-destructing messagesakwizgranakwizgran2021-01-31https://code.briarproject.org/briar/briar/-/issues/1830Update blog and forum sharing clients to include a self-destruct timer in eac...2020-11-30T12:45:14ZakwizgranUpdate blog and forum sharing clients to include a self-destruct timer in each messageSubtask of #804Subtask of #804Self-destructing messagesakwizgranakwizgran2021-01-31https://code.briarproject.org/briar/briar/-/issues/1829Update introduction client to include a self-destruct timer in each message2020-11-30T12:45:13ZakwizgranUpdate introduction client to include a self-destruct timer in each messageSubtask of #804Subtask of #804Self-destructing messagesakwizgranakwizgran2021-01-31https://code.briarproject.org/briar/briar/-/issues/1828Update messaging client to include a self-destruct timer in each message2020-11-30T12:45:13ZakwizgranUpdate messaging client to include a self-destruct timer in each messageSubtask of #804Subtask of #804Self-destructing messagesakwizgranakwizgran2021-01-31https://code.briarproject.org/briar/briar/-/issues/1844Add core method for loading a profile picture2020-11-30T12:31:04ZakwizgranAdd core method for loading a profile pictureAdd a core method for loading a profile picture as an InputStream, give the message ID and content type. This will be similar to MessagingManager#getAttachment(), so consider whether that method and the Attachment and AttachmentHeader cl...Add a core method for loading a profile picture as an InputStream, give the message ID and content type. This will be similar to MessagingManager#getAttachment(), so consider whether that method and the Attachment and AttachmentHeader classes should be factored out.
Subtask of #214.Profile picturesTorsten GroteTorsten Grote2021-01-31https://code.briarproject.org/briar/briar/-/issues/1843Create sync client to exchange profile pictures with contacts2020-11-30T12:31:03ZakwizgranCreate sync client to exchange profile pictures with contactsThis client will sync single-block messages initially, pending large message support.
Subtask of #214.This client will sync single-block messages initially, pending large message support.
Subtask of #214.Profile picturesTorsten GroteTorsten Grote2021-01-31https://code.briarproject.org/briar/briar/-/issues/728Don't change list indices during validation2020-11-23T11:39:37ZakwizgranDon't change list indices during validationSome validation hooks pop the message type off the list representing the message body before validating the remaining items. This is due to poorly written specs that didn't include the message type in the list. The list should be left un...Some validation hooks pop the message type off the list representing the message body before validating the remaining items. This is due to poorly written specs that didn't include the message type in the list. The list should be left unmodified for easier comparison with the corrected spec.https://code.briarproject.org/briar/briar/-/issues/841Settings: Check-marks blink2020-11-23T10:57:36ZErnir ErlingssonSettings: Check-marks blinkThis bug is only visible on larger screens where a check mark is visible in the settings screen without scrolling.
1. Make sure you've previously unchecked that top check-mark (private group notifications)and that it's visible on the se...This bug is only visible on larger screens where a check mark is visible in the settings screen without scrolling.
1. Make sure you've previously unchecked that top check-mark (private group notifications)and that it's visible on the settings screen without scrolling.
2. open the settings from another window, notice that the check-mark starts as being selected and blinks away in an inelegant fashion.https://code.briarproject.org/briar/briar/-/issues/6Message delays are confusing for users2020-11-21T20:37:12ZakwizgranMessage delays are confusing for usersFeedback from user testing:
Case 1: "From one of the participants of our test:
They had bluetooth and WiFi transports available (3 parties in close proximity). It seemed messages were being sent via mobile data as opposed to bluetooth....Feedback from user testing:
Case 1: "From one of the participants of our test:
They had bluetooth and WiFi transports available (3 parties in close proximity). It seemed messages were being sent via mobile data as opposed to bluetooth. This resulted in sometimes significant delays being seen in sending/receiving messages. With ancedotal measurement these delays were seen between 2-3 minutes and 9-10 minutes.
The users expected bluetooth to be used (as they were all physically near each other). These delays did not match how people were thinking bluetooth would be "instantaneous" communications.
It did not affect things too much but confused people.
Can we clarify how messages are sent received when there are multiple transports available?"
Case 2: "UserA was waiting outside UserB's house. UserA sent UserB a message and said there was approx a 2 minute delay, using mobile data."
Case 3: "I've been at a meeting today. Have checked Briar this morning and twice during the afternoon but not been signed in at length. I've just received all the messages from today at 22:01ish. Some of which had occured before I signed in earlier so I should have received them then. I imagine that maybe I wasn't signed in long enough to receive the data package. As a Whatsapp user id expect to sign in and within a minute have received all the updates from other people. So the response time for thread updates in one issue."https://code.briarproject.org/briar/briar/-/issues/12Timeout while adding a contact2020-11-21T20:35:27ZakwizgranTimeout while adding a contactSeveral users reported timeouts while adding contacts. The problem seemed to be more severe in larger groups. One user experienced a long series of timeouts before successfully adding a contact.
If this problem is caused in some cases b...Several users reported timeouts while adding contacts. The problem seemed to be more severe in larger groups. One user experienced a long series of timeouts before successfully adding a contact.
If this problem is caused in some cases by congestion at the Bluetooth MAC layer, we may be able to mitigate it by keeping a cache of discovered devices and trying to connect to them before performing discovery. If a group of users are adding each other as contacts, the first discovery by each user should put most of the other users' devices in the cache.
If this problem is caused in some cases by poorly performing Bluetooth drivers or hardware, we may not be able to work around it at the application level.
This could be caused by the limit of eight devices (one master and seven slaves) in a Bluetooth piconet. If so, closing any open Bluetooth connections before attempting a new connection may help.https://code.briarproject.org/briar/briar/-/issues/14Sony LiveWare pops up when first connecting via Bluetooth2020-11-21T20:34:24ZakwizgranSony LiveWare pops up when first connecting via BluetoothThe LiveWare Manager app bundled with the Sony Xperia tipo pops up when first connecting to a new device via Bluetooth while adding a contact. It asks which app should be started when the device is connected.
This doesn't happen every t...The LiveWare Manager app bundled with the Sony Xperia tipo pops up when first connecting to a new device via Bluetooth while adding a contact. It asks which app should be started when the device is connected.
This doesn't happen every time - it may depend on whether the connection is incoming or outgoing, or there may be a cache of known devices that's cleared when the phone is restarted or reset.
![Screenshot_2014-10-06-13-12-40](/uploads/b94df454ee369fd23adb2544d37ae3b7/Screenshot_2014-10-06-13-12-40.png)