briar issueshttps://code.briarproject.org/groups/briar/-/issues2020-11-19T14:50:44Zhttps://code.briarproject.org/briar/briar/-/issues/991Opening private conversation with new contact should hide new contact notific...2020-11-19T14:50:44ZakwizgranOpening private conversation with new contact should hide new contact notificationThe new contact notification that's shown when a contact is introduced should be hidden when opening the contact's private conversation. Touching the notification should open the contact's private conversation.
If multiple contacts have...The new contact notification that's shown when a contact is introduced should be hidden when opening the contact's private conversation. Touching the notification should open the contact's private conversation.
If multiple contacts have been introduced, each contact should be removed from the notification when opening the contact's private conversation, and touching a notification for multiple new contacts should open the contact list. (This is consistent with the behaviour of the private message notification.)https://code.briarproject.org/briar/briar/-/issues/975Load group item perspective before creating the Items2020-11-19T15:06:22ZJulian DehmLoad group item perspective before creating the ItemsCurrently, the perspective/creator of a group is loaded concurrently with the items. If the items are loaded before the creator, the perspective will be displayed wrongly (race condition).
Quote from @grote
>If I remember correctly, i...Currently, the perspective/creator of a group is loaded concurrently with the items. If the items are loaded before the creator, the perspective will be displayed wrongly (race condition).
Quote from @grote
>If I remember correctly, it would be better to change things so the perspective for the messages is known before they are created and then it can be passed to the message constructor instead of dynamically changing the adapter. Since this code is shared with forums, it might not be a trivial change though.
(see !532 for the initial discussion)https://code.briarproject.org/briar/briar/-/issues/952Use external IP address in LocationUtils if available2020-11-19T15:17:31ZakwizgranUse external IP address in LocationUtils if availableIf we can discover a routable IP address from a network interface then we can look it up in Tor's GeoIP library and use that as one of the sources to determine whether Tor's likely to be blocked in our current location.If we can discover a routable IP address from a network interface then we can look it up in Tor's GeoIP library and use that as one of the sources to determine whether Tor's likely to be blocked in our current location.https://code.briarproject.org/briar/briar/-/issues/944WiFi Transport layer dead when device has been offline for long2020-11-19T15:20:50ZErnir ErlingssonWiFi Transport layer dead when device has been offline for longBriar was running for two days in flight mode but failed to connect when device internet connectivity was restored per WiFi. I failed to check other transports due to a crash ~~that I'm still investigating, it might be that Briar's stabi...Briar was running for two days in flight mode but failed to connect when device internet connectivity was restored per WiFi. I failed to check other transports due to a crash ~~that I'm still investigating, it might be that Briar's stability was compromised.~~
Edit: Unrelated crash due to an error in my save/restore branchhttps://code.briarproject.org/briar/briar/-/issues/921Contact seemed to remain online after phone was reused2020-11-19T15:25:24ZakwizgranContact seemed to remain online after phone was reusedThis issue arose in user testing when one of the devices was reused by another tester.
User A with device X and user B with device Y added each other as contacts. Then user C took over device Y and created a new account. User A continue...This issue arose in user testing when one of the devices was reused by another tester.
User A with device X and user B with device Y added each other as contacts. Then user C took over device Y and created a new account. User A continued to see user B as online.
This may have been caused by a Bluetooth channel remaining open between the devices, causing user A to think that a connection to user B was still open. Perhaps a subsequent connection between user A and user C either reused the channel or otherwise caused it to remain open rather than timing out, or perhaps the Bluetooth stack on device X simply doesn't time out connections in a reasonable time.
If any of those speculations are right, we should work out how to avoid relying on Bluetooth to time out the connection and time out after a reasonable time in the Bramble stack instead.
We should also check that Bluetooth connections are being disposed of properly when they're closed.https://code.briarproject.org/briar/briar/-/issues/834Optionally sign out when battery is low or power saving mode is enabled2021-10-27T14:09:40ZakwizgranOptionally sign out when battery is low or power saving mode is enabledListen for power manager events (ACTION_BATTERY_LOW, ACTION_POWER_SAVE_MODE_CHANGED) and [manufacturer-specific events](http://stackoverflow.com/a/25103642) and optionally sign out if the battery is low or power saving mode is enabled an...Listen for power manager events (ACTION_BATTERY_LOW, ACTION_POWER_SAVE_MODE_CHANGED) and [manufacturer-specific events](http://stackoverflow.com/a/25103642) and optionally sign out if the battery is low or power saving mode is enabled and the user's not currently interacting with Briar.https://code.briarproject.org/briar/briar/-/issues/826Online status in group memberlist2020-11-21T12:40:34ZTorsten GroteOnline status in group memberlistThe group member list shows the online status of contacts. As of MR !448, it only shows the online status of contacts, we actually share with to be consistent with the sharing information in the group's action bar.
This can be confusing...The group member list shows the online status of contacts. As of MR !448, it only shows the online status of contacts, we actually share with to be consistent with the sharing information in the group's action bar.
This can be confusing since some group members have online status and others don't.https://code.briarproject.org/briar/briar/-/issues/825Show an error message if no transports are available for adding contacts2020-11-21T12:41:36ZakwizgranShow an error message if no transports are available for adding contactshttps://code.briarproject.org/briar/briar/-/issues/819UX design for errors that don't interrupt the user's workflow2020-11-21T12:43:46ZTorsten GroteUX design for errors that don't interrupt the user's workflowThis ticket is for creating the UX design when errors occur that don't interrupt the user's workflow.
Imagine you share a forum with someone or invite two contacts to each other. These operations might fail, but since the invitation scr...This ticket is for creating the UX design when errors occur that don't interrupt the user's workflow.
Imagine you share a forum with someone or invite two contacts to each other. These operations might fail, but since the invitation screen closes anyway, it does not really interrupt your work-flow anymore. Another possible error might happen when a title of the blog or the number of online users is loaded to be shown in the action bar. There will just be the default title maybe "Blog" and the user might not even notice, but it is a bug we might want to know about. Another example is when we fail to store the fact that we already showed you the onboarding and then show it to you again.
So more general, the kinds of errors I imagine to fall in this category are:
* user actions that are not completed, but don't interrupt the workflow because it finishes at this point anyway
* loading of non-essential information
Subticket of #469.https://code.briarproject.org/briar/briar/-/issues/818UX design for errors that interrupt the user's workflow2020-11-21T12:44:25ZTorsten GroteUX design for errors that interrupt the user's workflowThis ticket is for creating the UX design for when errors occur that interrupt the user's workflow and don't have any corrective action.
For example, you open your private conversation with someone, but it just closes again (or shows an...This ticket is for creating the UX design for when errors occur that interrupt the user's workflow and don't have any corrective action.
For example, you open your private conversation with someone, but it just closes again (or shows an error message) because an error occurred while loading it. You open a private group, but when finding out whether it is dissolved an error occurs, so it stays in the disabled state by default. Or you are in a multi-step process and an error prevents you from reaching the next step like when creating a private group fails and you are not getting to the next step of inviting contacts to it.
Errors while loading blog posts, private message, forum posts, contacts, basically anything in lists falls into this category.
Subticket of #469.https://code.briarproject.org/briar/briar/-/issues/801Revealing contact relationship is not clear2020-11-21T12:52:17ZTorsten GroteRevealing contact relationship is not clearDuring testing session #788, no one understood what revealing contact relationships means although most users were rather technical and were using other apps extensively. The onboarding dialog didn't help. It was not clear who can revea...During testing session #788, no one understood what revealing contact relationships means although most users were rather technical and were using other apps extensively. The onboarding dialog didn't help. It was not clear who can reveal contacts and why the creator can not do it. It was not clear what this exactly means and why it can be done.
It took some long explanations before everybody had understood this feature. They were all open to p2p apps and appreciated the explanation. They were happy to understand how messages travel through the p2p network, but they also acknowledged that we are trying to explain features without requiring users to understand that.
Some testers doubted that it is possible to understand revealing contacts without knowing about how messages travel. They pointed out how Briar works very differently than other apps they are familiar with and that it needs some getting used to. The user familiar with Retroshare suggested to use a visual representation of the contact relationship within a group as this can help with understanding this concept and also nicely illustrate the p2p approach.
![briar-user-graph](/uploads/a7819e19bc66f94fc0c3ff50d9265eb7/briar-user-graph.png)https://code.briarproject.org/briar/briar/-/issues/786Handle whitespace consistently2022-11-18T17:24:07ZakwizgranHandle whitespace consistentlyText with leading or trailing whitespace is treated inconsistently:
* Nicknames: whitespace isn't trimmed, whitespace-only names are allowed
* Private messages: whitespace is trimmed, whitespace-only messages are allowed but become empt...Text with leading or trailing whitespace is treated inconsistently:
* Nicknames: whitespace isn't trimmed, whitespace-only names are allowed
* Private messages: whitespace is trimmed, whitespace-only messages are allowed but become empty after trimming
* Forum names: whitespace isn't trimmed, whitespace-only names are allowed
* Forum invitations: whitespace isn't trimmed, whitespace-only messages are allowed
* Forum posts: whitespace is trimmed, whitespace-only posts aren't allowed
* Private group names: whitespace isn't trimmed, whitespace-only names are allowed
* Private group invitations: whitespace isn't trimmed, whitespace-only messages are allowed
* Private group posts: whitespace is trimmed, whitespace-only posts aren't allowed
* Blog posts: whitespace is trimmed, whitespace-only posts are allowed but become empty after trimming
* Blog comments: whitespace isn't trimmed, whitespace-only comments are allowed
Let's do the following everywhere:
When entering text:
1. Trim leading and trailing whitespace
2. If the trimmed text is empty and the input is optional (for example a blog comment), pass null to the backend
3. If the trimmed text is empty and the input isn't optional (for example a blog post), don't accept the input
4. If the trimmed text is too long, don't accept the input
5. If the trimmed text isn't empty or too long, pass it to the backend
When validating messages (including author names and group names):
1. Reject null if the text isn't optional
2. Reject the text if it's empty or too long
3. Reject the text if it has leading or trailing whitespacehttps://code.briarproject.org/briar/briar/-/issues/776Merge redundant null safety annotations2020-11-21T16:19:21ZakwizgranMerge redundant null safety annotationsAfter some experience with the new null safety annotations, it seems we only want to express two conditions:
* Methods, parameters and fields are not null by default
* Methods and parameters are not null by default
Merge @MethodsNotNull...After some experience with the new null safety annotations, it seems we only want to express two conditions:
* Methods, parameters and fields are not null by default
* Methods and parameters are not null by default
Merge @MethodsNotNullByDefault with @ParametersNotNullByDefault, and remove @FieldsNotNullByDefault.https://code.briarproject.org/briar/briar/-/issues/753Listener interfaces have mixed responsibilities2021-01-20T12:34:20ZakwizgranListener interfaces have mixed responsibilitiesThe UI makes heavy use of listener interfaces that inherit from either DestroyableContext or BaseFragmentListener. These are used for various purposes:
* Callbacks from a controller to the UI (e.g. `TransportStateListener#stateUpdate()`...The UI makes heavy use of listener interfaces that inherit from either DestroyableContext or BaseFragmentListener. These are used for various purposes:
* Callbacks from a controller to the UI (e.g. `TransportStateListener#stateUpdate()`)
* Injecting dependencies into fragments (`BaseFragmentListener#getActivityComponent()`)
* Manipulating other parts of the UI (e.g. `CreateGroupListener#showSoftKeyboard()`)
* Running tasks (`DestroyableContext#runOnUiThreadUnlessDestroyed()`, `BaseFragmentListener#runOnDbThread()` (deprecated))
These different purposes would ideally be separated into different interfaces. Maybe it would clarify things if communication from controllers back to the UI used the "listener" name and communication between fragments and their activities used some other name.
Listeners are usually provided by casting an Activity or Context (passed to `ActivityLifecycleController#onActivityCreate()` or `Fragment#onAttach()`) to an arbitrary listener interface. This is a bit of a hack - it would be nice if we could provide listeners in a type-safe way, for example by injection.
Related to #752.https://code.briarproject.org/briar/briar/-/issues/751Emoji flicker when BriarRecyclerView updates itself2020-11-21T16:23:47ZakwizgranEmoji flicker when BriarRecyclerView updates itselfWhen BriarRecyclerView updates itself once per minute, emoji visibly flicker.When BriarRecyclerView updates itself once per minute, emoji visibly flicker.https://code.briarproject.org/briar/briar/-/issues/744Use global constants for View's alpha values2020-11-21T16:27:13ZErnir ErlingssonUse global constants for View's alpha valuesIn several places in the app we're decreasing the opacity of views to represent things such as disabled states. Unfortunately, we're doing this through hard-coded float values at each location. We should rather use global constants and m...In several places in the app we're decreasing the opacity of views to represent things such as disabled states. Unfortunately, we're doing this through hard-coded float values at each location. We should rather use global constants and make sure that every occurrence uses them -- this will make it easier for us to modify it in the future to fit any design pattern.https://code.briarproject.org/briar/briar/-/issues/730Remove redundant setup code from jMock tests2020-11-21T16:29:33ZakwizgranRemove redundant setup code from jMock testsIt's safe to reuse a Mockery and mocked objects across multiple tests - if unexpected or missing invocations cause a test to fail, the expectations are reset before running the next test. Setup code can therefore be moved from the indivi...It's safe to reuse a Mockery and mocked objects across multiple tests - if unexpected or missing invocations cause a test to fail, the expectations are reset before running the next test. Setup code can therefore be moved from the individual tests to the class in many cases.https://code.briarproject.org/briar/briar/-/issues/725Result handlers may not return results if the screen is rotated2020-11-21T16:36:20ZakwizgranResult handlers may not return results if the screen is rotatedThis issue came to mind while reviewing !354 - `SetupActivity#onClick()` uses the onResultUi() method of a UiResultHandler to start the next activity. If the screen's rotated before the handler returns, the original activity will be dest...This issue came to mind while reviewing !354 - `SetupActivity#onClick()` uses the onResultUi() method of a UiResultHandler to start the next activity. If the screen's rotated before the handler returns, the original activity will be destroyed, so the handler will never call onResultUi(). The outcome, as far as I can see, will be a progress wheel that spins forever.
Similar problems may exist elsewhere. Most of the time we use ResultHandlers to update the state of the current activity or fragment, and we reload everything if the activity or fragment's recreated, so it doesn't matter if results are lost during rotation. But there may be some places like this one where we depend on the result being returned.https://code.briarproject.org/briar/briar/-/issues/706Migrate crypto to libsodium2020-11-21T16:39:44ZakwizgranMigrate crypto to libsodiumUsing libsodium via JNI would give us constant-time implementations of Curve25519 and Ed25519 (see #236) and a fast implementation of Argon2 (see #170). Our crypto_secretbox implementation could be replaced, and we could use crypto_box i...Using libsodium via JNI would give us constant-time implementations of Curve25519 and Ed25519 (see #236) and a fast implementation of Argon2 (see #170). Our crypto_secretbox implementation could be replaced, and we could use crypto_box instead of ECIES for crash reports and feedback. BLAKE2s would remain in Java (libsodium only has BLAKE2b). If we replaced the Fortuna generator with libsodium's RNG, we could get rid of Bouncy Castle.
https://github.com/joshjdevl/libsodium-jnihttps://code.briarproject.org/briar/briar/-/issues/704Use constructor injection where possible2020-11-21T16:59:46ZakwizgranUse constructor injection where possibleClasses that don't require special constructors (pretty much everything except Activities, Fragments and Views) should use constructor injection rather than field injection. This allows us to make the fields final, so we don't have to wo...Classes that don't require special constructors (pretty much everything except Activities, Fragments and Views) should use constructor injection rather than field injection. This allows us to make the fields final, so we don't have to worry about whether they're been initialised or whether they should be volatile, and the class can be annotated @NotNullByDefault.