briar issueshttps://code.briarproject.org/briar/briar/-/issues2021-04-13T11:49:41Zhttps://code.briarproject.org/briar/briar/-/issues/1837Conversation settings screen2021-04-13T11:49:41ZakwizgranConversation settings screenAdd a per-conversation settings screen, accessible via the conversation screen's menu.
The screen will initially have one setting: a switch that enables or disables self-destructing messages, with an explanation of the timer duration an...Add a per-conversation settings screen, accessible via the conversation screen's menu.
The screen will initially have one setting: a switch that enables or disables self-destructing messages, with an explanation of the timer duration and the fact that changes made by the contact will be followed automatically.
Subtask of #804Self-destructing messagesSebastianSebastian2021-01-31https://code.briarproject.org/briar/briar/-/issues/1836Automatically decline incoming private group invitations when they self-destruct2021-03-11T12:26:10ZakwizgranAutomatically decline incoming private group invitations when they self-destructWhen an incoming private group invitation self-destructs without being answered, automatically decline the request. This may require a protocol update (coordinated with #1831) to flag the decline as an automatic response that shouldn't b...When an incoming private group invitation self-destructs without being answered, automatically decline the request. This may require a protocol update (coordinated with #1831) to flag the decline as an automatic response that shouldn't be shown in the UI.
Subtask of #804Self-destructing messagesIvanaIvana2021-01-31https://code.briarproject.org/briar/briar/-/issues/1835Automatically decline incoming blog/forum invitations when they self-destruct2021-07-06T09:56:40ZakwizgranAutomatically decline incoming blog/forum invitations when they self-destructWhen an incoming blog/forum invitation self-destructs without being answered, automatically decline the invitation. This may require a protocol update (coordinated with #1830) to flag the decline as an automatic response that shouldn't b...When an incoming blog/forum invitation self-destructs without being answered, automatically decline the invitation. This may require a protocol update (coordinated with #1830) to flag the decline as an automatic response that shouldn't be shown in the UI.
Subtask of #804Self-destructing messagesIvanaIvana2021-01-31https://code.briarproject.org/briar/briar/-/issues/1834Automatically decline incoming introduction requests when they self-destruct2021-05-05T16:17:22ZakwizgranAutomatically decline incoming introduction requests when they self-destructWhen an incoming introduction request self-destructs without being answered, automatically decline the request. This may require a protocol update (coordinated with #1829) to flag the decline as an automatic response that shouldn't be sh...When an incoming introduction request self-destructs without being answered, automatically decline the request. This may require a protocol update (coordinated with #1829) to flag the decline as an automatic response that shouldn't be shown in the UI.
Subtask of #804
Test instructions:
* Use three devices, users A, B and C
* Enable self-destructing messages in the conversations A-B and A-C
* Let A introduce contacts B and C
* Expect invitation messages to arrive at B and C about the invitation
* Expect the invitation messages to have a auto-delete timers
* Let those timers expire. Expect that to trigger an automatic decline of the invitation, i.e. on all three devices it is visible that the introduction failed (due to the expired response)
* Expect all messages from that interaction to destroy after each message's timer expires
* Let A introduce B and C again. Expect this *not* to fail due to an introduction that is already going on (because none should be going on any longer)
* Let B and C accept the introduction
* Expect the introduction to work
* Confirm that B and C have each other in the contact list
* Expect all messages involved in the transaction to have auto-delete timers
* Let those timers expire and expect all those messages to disappearSelf-destructing messagesIvanaIvana2021-01-31https://code.briarproject.org/briar/briar/-/issues/1833Delete messages when their self-destruct timers expire2021-03-11T12:25:31ZakwizgranDelete messages when their self-destruct timers expireCreate a component that tracks pending self-destruct timers and deletes messages when their self-destruct timers expire.
Conversation clients will register messages for deletion during delivery. The new component will be responsible for...Create a component that tracks pending self-destruct timers and deletes messages when their self-destruct timers expire.
Conversation clients will register messages for deletion during delivery. The new component will be responsible for calling back into the client when a message is due to be deleted. This will allow the client to take any necessary steps before deletion, such as declining an open introduction.
Subtask of #804Self-destructing messagesIvanaIvana2021-01-31https://code.briarproject.org/briar/briar/-/issues/1832Store self-destruct timer duration2020-12-16T12:58:10ZakwizgranStore self-destruct timer durationFor each contact, store the local timer duration for self-destructing messages and the time when it was updated. When a message is received from the contact with a different timer duration and higher timestamp, update the local timer dur...For each contact, store the local timer duration for self-destructing messages and the time when it was updated. When a message is received from the contact with a different timer duration and higher timestamp, update the local timer duration. There should also be methods for setting the duration manually and querying the duration when sending a message.
Subtask of #804Self-destructing messagesakwizgranakwizgran2021-01-31https://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/1207Update content rating in Play Store when image support is added2021-07-06T10:06:40ZakwizgranUpdate content rating in Play Store when image support is addedProfile picturesakwizgranakwizgran2021-01-31https://code.briarproject.org/briar/briar/-/issues/804Self-destruct timer for messages2021-07-06T09:57:26ZTorsten GroteSelf-destruct timer for messagesDuring testing session #788 and during the first Briar presentation at Cryptorave, users asked if we support a self-destruct timer for messages like Signal introduced recently and like it is also supported by Telegram.
The user seemed t...During testing session #788 and during the first Briar presentation at Cryptorave, users asked if we support a self-destruct timer for messages like Signal introduced recently and like it is also supported by Telegram.
The user seemed to see less need for the feature after it was explained that this feature does not help against adversaries who also receive that message, because they can always retain it despite the self-destruct timer. Most users might not know that and get a false sense of security from such a feature. However, testers still found it nice to be able to let messages delete automatically in case they are forced to enter their password or somebody gets hold of their phone unlocked.Self-destructing messages2021-01-31https://code.briarproject.org/briar/briar/-/issues/214User Avatars2021-05-05T16:17:22ZTorsten GroteUser AvatarsFollowing support for Identicons in #120, we want to give users the possibility to use their own avatar to be recognized by their peers.
We should bear in mind the potential for impersonation, especially in forums, where users will see ...Following support for Identicons in #120, we want to give users the possibility to use their own avatar to be recognized by their peers.
We should bear in mind the potential for impersonation, especially in forums, where users will see posts from known and unknown identities mixed together. Anyone can create a throwaway identity with the same nickname (and avatar, if we allow them) as another user, which is different from what people are used to in centralised systems.
One possibility would be to show avatars *only* for known/verified identities and use identicons for unknown identities and those users who did not specify an avatar.
Unverified contacts should be distinguished from verified contacts in some way. They could use different identicons or have a little badge on their image indicating the trust-level similar to the little green briar icons we use at the moment.Profile picturesIvanaIvana2021-01-31https://code.briarproject.org/briar/briar/-/issues/2151Simple UI for Connect via Bluetooth feature2021-08-31T13:11:42ZTorsten GroteSimple UI for Connect via Bluetooth featureThe current UI prototype only uses Toasts to communicate progress to the user.
We should give this a dedicated screen which explains what the feature does and then shows progress information to the user.The current UI prototype only uses Toasts to communicate progress to the user.
We should give this a dedicated screen which explains what the feature does and then shows progress information to the user.Adapt to changes in the Android platformTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/2043Scrolling not happening automatically for own blog posts2021-07-06T10:01:09ZIvanaScrolling not happening automatically for own blog postsDescription:
Scrolling doesn't happen automatically for own blog posts - in portrait orientation
Steps to reproduce:
1. Create enough blog or reblog posts to have more than one full screen of them on a device
2. Then create one more ...Description:
Scrolling doesn't happen automatically for own blog posts - in portrait orientation
Steps to reproduce:
1. Create enough blog or reblog posts to have more than one full screen of them on a device
2. Then create one more new blog post
Expected results:
1. On own device, wn blog post should appear on top of the page.
Actual result:
1. The new blog post does not appear on top of the screen before manually scrolling to it, or before tapping the blue 'Scroll' word on the message that briefly shows on the bottom of the screen
![device-2021-05-17-132727](/uploads/c005cc532d63069bc98a3ef874ce4be4/device-2021-05-17-132727.mp4)Adapt to changes in the Android platformIvanaIvana2021-04-30https://code.briarproject.org/briar/briar/-/issues/2032Crash while trying to connect via bluetooth2021-07-06T10:00:56ZIvanaCrash while trying to connect via bluetoothSteps to reproduce:
Master: 2021-05-06 13:14 GitHash: 9dff8bd
Devices: HTC One M9 and Nokia 3.1
Device Settings: wifi= OFF on both devices. BT = ON on both devices.
App access to location and camera = ON on both devices
- Add a neaby ...Steps to reproduce:
Master: 2021-05-06 13:14 GitHash: 9dff8bd
Devices: HTC One M9 and Nokia 3.1
Device Settings: wifi= OFF on both devices. BT = ON on both devices.
App access to location and camera = ON on both devices
- Add a neaby contact on each device.
- Scan the QR code when prompted and verify that contacts are added OK on both devices and that they show status 'online'
- Go to device settings and switch the bluetooth setting OFF on each device
- This will result in the two 'nearby' contacts showing as being offline
- Now go to the menu for the contact added in step 1, and select Connect via Bluetooth - on each device
- Tap 'start' on both devices at the same time (as much as that is possible)
- Tap 'allow' to allow the device visibility to other BT devices during 120 seconds
Expected results:
- the BT setting on the device is turned on during this process
- the process concludes successfully
- user is given messages that the connection via BT was successful
- the contact show online and can send each other messages via BT
Actual results:
- The process starts off OK, and users get messages 'connecting via bluetooth', and then both devices crash before the process is completed.
- The BT setting on the device is switched on during the process - despite the crash
The two Android Studio logifles from the two crashes:
[crash_while_connecting_via_BT_10052021.txt](/uploads/c5535c39691cdb3eced22497eab14c67/crash_while_connecting_via_BT_10052021.txt)[crash2_while_connecting_via_BT_10052021.txt](/uploads/b608db975758dbd673beb6ac6fcb1ff2/crash2_while_connecting_via_BT_10052021.txt)
Crash report sent from Nokia 3.1 for both crashesAdapt to changes in the Android platformIvanaIvana2021-04-30https://code.briarproject.org/briar/briar/-/issues/2027Pause polling when doing Connect-via-BT to specific contact2021-07-06T10:02:37ZDaniel LublinPause polling when doing Connect-via-BT to specific contactShould increase likelyhood of successful connection.Should increase likelyhood of successful connection.Adapt to changes in the Android platformDaniel LublinDaniel Lublin2021-04-30https://code.briarproject.org/briar/briar/-/issues/2009Give instructions during setup for protecting app from Xiaomi/Redmi power man...2021-07-06T10:02:52ZakwizgranGive instructions during setup for protecting app from Xiaomi/Redmi power managementWhile working on #1743 I found that the [Snooze app](https://code.briarproject.org/akwizgran/snooze) was killed when running overnight on the Redmi Note 7. [Locking the app to the recent apps list](https://code.briarproject.org/briar/bri...While working on #1743 I found that the [Snooze app](https://code.briarproject.org/akwizgran/snooze) was killed when running overnight on the Redmi Note 7. [Locking the app to the recent apps list](https://code.briarproject.org/briar/briar/-/issues/1743#note_49341) prevented this from happening. We should recommend this during account setup, as we do for Huawei's protected apps and app launch settings.
(The user can also [change the app's background setting to "No restrictions"](https://code.briarproject.org/briar/briar/-/issues/1743#note_49269), which is recommended in various places but didn't help in the case of the Snooze app.)Adapt to changes in the Android platformIvanaIvana2021-04-30https://code.briarproject.org/briar/briar/-/issues/2005Connect Via Bluetooth shows error even if connection succeeds2021-07-06T10:00:49ZTorsten GroteConnect Via Bluetooth shows error even if connection succeedsIt can happen that we tell the user that no connection could be made even if it could be made.
It might help to show the error toast only after some delay.It can happen that we tell the user that no connection could be made even if it could be made.
It might help to show the error toast only after some delay.Adapt to changes in the Android platformIvanaIvana2021-04-30https://code.briarproject.org/briar/briar/-/issues/2002Android 11 PIxel2 - 'Ask every time' - workflow user asked for permission in...2021-07-06T10:03:06ZIvanaAndroid 11 PIxel2 - 'Ask every time' - workflow user asked for permission in popup after they just selected 'ask every time' on deviceScenario: When user is taken to the pages Briar app settings on their device - they decide to grant Briar permission to access the camera and location by selecting 'Ask every time'. They then navigate back to Briar and are given the dial...Scenario: When user is taken to the pages Briar app settings on their device - they decide to grant Briar permission to access the camera and location by selecting 'Ask every time'. They then navigate back to Briar and are given the dialog/popup again with the same question to giv Briar permissions to access their location and camera again - They have just done that, so they shoudln't be asked it again.
Steps to reproduce:
Preconditions: Briar's access to location and camera are denied.
1. Start a new process of creating a nearby contact
2. Tap continue.
3. Popup asks the user to grant Briar permissions to access the camera and location.
4. User denies both.
5. User gets this message: you have denied access to the camera but adding contacts requires using the camera. Please consider granting access. User taps OK.
6. User is then taken to the Briar app settings to grant the Briar access to their camera.
7. User selects the 'Ask every time' option.
8. User navigates back to Briar by tapping the back button.
9. Briar create nearby contacts info screen shows, and user tap Continue
10. A popup comes up and asks the user to grant Briar access to their camera.
Expected results:
- The popup should nto be asking the user to grant permissions after their have just done so.
Actual result:
- A popup comes up and asks the user to grant Briar access to their camera.
- After granting the camera access once more, the user can continue and create the nearby contact OKAdapt to changes in the Android platform2021-04-30