briar issueshttps://code.briarproject.org/briar/briar/-/issues2020-11-21T12:44:25Zhttps://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.https://code.briarproject.org/briar/briar/-/issues/702Improve encapsulation of ViewHolder classes2020-11-21T17:01:14ZakwizgranImprove encapsulation of ViewHolder classesEach BriarAdapter subclass has its own subclass of RecyclerView.ViewHolder. Some of these ViewHolder classes have public fields. Improve the encapsulation of these classes, either by adding accessor methods or by moving the code that acc...Each BriarAdapter subclass has its own subclass of RecyclerView.ViewHolder. Some of these ViewHolder classes have public fields. Improve the encapsulation of these classes, either by adding accessor methods or by moving the code that accesses the fields into the respective classes.https://code.briarproject.org/briar/briar/-/issues/691Password warnings are clipped2020-11-21T17:02:17ZakwizgranPassword warnings are clippedOn the Samsung Galaxy Ace 2 (Android 4.1.2, 480x800 screen) the warning messages shown during setup when the password is too weak or the passwords don't match are clipped at the right edge.
![device-2016-10-04-171244](/uploads/202d61695...On the Samsung Galaxy Ace 2 (Android 4.1.2, 480x800 screen) the warning messages shown during setup when the password is too weak or the passwords don't match are clipped at the right edge.
![device-2016-10-04-171244](/uploads/202d6169564994fbf6d28c022aa60fc8/device-2016-10-04-171244.png)
![device-2016-10-04-171311](/uploads/15c8896672c1ec2134529ed2b74278b6/device-2016-10-04-171311.png)https://code.briarproject.org/briar/briar/-/issues/689Line breaks entered in blog posts aren't displayed2022-11-23T14:44:51ZakwizgranLine breaks entered in blog posts aren't displayedWhen writing a blog post, I can use the enter key to create line breaks that are shown in the composition window. But they aren't shown when the blog post appears in the feed (presumably because it's rendered as HTML).When writing a blog post, I can use the enter key to create line breaks that are shown in the composition window. But they aren't shown when the blog post appears in the feed (presumably because it's rendered as HTML).https://code.briarproject.org/briar/briar/-/issues/640Detect blogs that are no longer receiving updates2020-11-21T17:05:02ZakwizgranDetect blogs that are no longer receiving updatesIt's possible for a blog subscriber to be cut off from the blog's author due to upstream subscribers unsubscribing or leaving the network. We could use some combination of keepalive messages from the author and an adaptive timeout at the...It's possible for a blog subscriber to be cut off from the blog's author due to upstream subscribers unsubscribing or leaving the network. We could use some combination of keepalive messages from the author and an adaptive timeout at the subscriber to detect this and mark the blog as inactive or unreachable.
If we use keepalives, the interval between keepalives should adapt to the average interval between posts. If we use a timeout at the subscriber based on the arrival times of updates, TCP's running estimates of round-trip time and round-trip time variance might be a good place to start.
Depending on the mechanism used, this might also be applicable to other kinds of group.https://code.briarproject.org/briar/briar/-/issues/626Add a sign out button to the ongoing notification2020-11-21T17:07:01ZErnir ErlingssonAdd a sign out button to the ongoing notificationOne test user took the drastic action of turning his mobile device off and on in order to completely close Briar. The user didn't realise that the logout button in-app would have that affect and remove the static notification.
Suggested...One test user took the drastic action of turning his mobile device off and on in order to completely close Briar. The user didn't realise that the logout button in-app would have that affect and remove the static notification.
Suggested solution: We add a logout button to the static notification, which causes Briar to close completely and removes the static notificationhttps://code.briarproject.org/briar/briar/-/issues/606Improve Fragment handling2020-11-21T17:17:05ZTorsten GroteImprove Fragment handlingThe `BriarFragmentActivity` is working around the fragment backstack instead of with it. Sometimes fragments are added to the stack and sometimes not. Fragments are *always* created from scratch even if there might already be an instance...The `BriarFragmentActivity` is working around the fragment backstack instead of with it. Sometimes fragments are added to the stack and sometimes not. Fragments are *always* created from scratch even if there might already be an instance on the backstack that could be re-used.https://code.briarproject.org/briar/briar/-/issues/604Provide hooks for mitigating flooding attacks at client layer2020-11-21T17:21:36ZakwizgranProvide hooks for mitigating flooding attacks at client layerMessage flooding attacks can be mitigated to some extent at the sync layer (#511), but the client may be in a better position to make decisions such as rate limiting. The sync API should allow clients to express these decisions, for exam...Message flooding attacks can be mitigated to some extent at the sync layer (#511), but the client may be in a better position to make decisions such as rate limiting. The sync API should allow clients to express these decisions, for example by limiting the rate at which messages are delivered to the client, shared with contacts, or both.https://code.briarproject.org/briar/briar/-/issues/577Annotate fields and methods that should only be accessed from certain threads2020-11-21T17:35:02ZakwizgranAnnotate fields and methods that should only be accessed from certain threadsCreate @UiThread and @DbThread annotations for fields and methods (just for documentation purposes at this stage). Maybe also @Blocking and @NonBlocking for methods.Create @UiThread and @DbThread annotations for fields and methods (just for documentation purposes at this stage). Maybe also @Blocking and @NonBlocking for methods.https://code.briarproject.org/briar/briar/-/issues/547Throw AssertionError instead of RuntimeException2020-11-21T17:41:53ZakwizgranThrow AssertionError instead of RuntimeExceptionMany places in the code rethrow checked exceptions as runtime exceptions if the checked exception should never happen. Throw AssertionError instead, to make the behaviour more self-documenting.Many places in the code rethrow checked exceptions as runtime exceptions if the checked exception should never happen. Throw AssertionError instead, to make the behaviour more self-documenting.