briar issueshttps://code.briarproject.org/briar/briar/-/issues2019-06-03T14:59:09Zhttps://code.briarproject.org/briar/briar/-/issues/1556Add support for handshake keys to KeyManager2019-06-03T14:59:09ZakwizgranAdd support for handshake keys to KeyManagerPart of #1232.Part of #1232.Android 1.2akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1554Allow pending contacts to be removed any time2019-05-24T14:50:04ZTorsten GroteAllow pending contacts to be removed any timeCurrently, we only allow the user to remove pending contacts when adding them remotely failed. However, the user might want to remove them even earlier, because they changed their mind about adding this contact for example.Currently, we only allow the user to remove pending contacts when adding them remotely failed. However, the user might want to remove them even earlier, because they changed their mind about adding this contact for example.Android 1.2Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1538Generate and store handshake key pair at startup if necessary2019-05-16T13:02:40ZakwizgranGenerate and store handshake key pair at startup if necessarySubtask of #1232.Subtask of #1232.Android 1.2akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1537Implement contact manager methods for pending contacts2019-05-13T09:04:51ZakwizgranImplement contact manager methods for pending contactsSubtask of #1232.Subtask of #1232.Android 1.2akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1501Show new contacts at the top of the contact list2019-03-22T16:54:17ZTorsten GroteShow new contacts at the top of the contact listCurrently, new contacts get added to the bottom of the list. They should be at the top for better visibility.Currently, new contacts get added to the bottom of the list. They should be at the top for better visibility.Android 1.2Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1497Check whether ongoing notification's priority and importance need to be incre...2019-02-21T12:41:39ZakwizgranCheck whether ongoing notification's priority and importance need to be increasedThis blog post describes some "guidelines" for a foreground service's ongoing notification:
https://android-developers.googleblog.com/2018/12/effective-foreground-services-on-android_11.html
> There are some guidelines around creating ...This blog post describes some "guidelines" for a foreground service's ongoing notification:
https://android-developers.googleblog.com/2018/12/effective-foreground-services-on-android_11.html
> There are some guidelines around creating and managing foreground services. For all API levels, a persistent notification with at least PRIORITY_LOW must be shown while the service is created. When targeting API 26+ you will also need to set the notification channel to at least IMPORTANCE_LOW.
Our ongoing notification uses PRIORITY_MIN and the channel uses IMPORTANCE_NONE. Find out whether this affects how the system treats our foreground service, especially on API 26+.
Related to #1146. Subtask of #1260.Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1496Check whether we're affected by implicit broadcast restrictions on Android 8+2019-02-21T10:32:35ZakwizgranCheck whether we're affected by implicit broadcast restrictions on Android 8+Apps targetting Android 8+ don't receive certain implicit broadcasts. Check whether we're affected.
https://developer.android.com/about/versions/oreo/background
Subtask of #1260.Apps targetting Android 8+ don't receive certain implicit broadcasts. Check whether we're affected.
https://developer.android.com/about/versions/oreo/background
Subtask of #1260.Android 1.1Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1477Implement UX for finding out whether contacts support image attachments2019-02-21T10:34:38ZakwizgranImplement UX for finding out whether contacts support image attachmentsImplement the design from #1476 for finding out whether each contact supports image attachments.
Subtask of #1438.Implement the design from #1476 for finding out whether each contact supports image attachments.
Subtask of #1438.Android 1.3Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1476Design UX for finding out whether contacts support image attachments2018-12-17T18:14:27ZakwizgranDesign UX for finding out whether contacts support image attachmentsWhen the user upgrades to a version of Briar that supports image attachments, it may not be possible to send images to a given contact until the contact has also upgraded to a suitable version.
We need to let the user know whether it's ...When the user upgrades to a version of Briar that supports image attachments, it may not be possible to send images to a given contact until the contact has also upgraded to a suitable version.
We need to let the user know whether it's possible to send images to each contact, and if not, what needs to change before it will be possible, and how the user will know when it's changed.
Subtask of #1241.Android 1.3Elio Qoshielio@ura.designElio Qoshielio@ura.designhttps://code.briarproject.org/briar/briar/-/issues/1475Resolve issues with image attachment transitions2019-03-19T10:43:04ZTorsten GroteResolve issues with image attachment transitions* [x] Use a counter as the transition name in `AttachmentItem`.
* [x] Tapping partly covered images makes them pop up from under the cover which looks glitchy
* [ ] Under mysterious circumstances messages can overlap each other (or leave...* [x] Use a counter as the transition name in `AttachmentItem`.
* [x] Tapping partly covered images makes them pop up from under the cover which looks glitchy
* [ ] Under mysterious circumstances messages can overlap each other (or leave gaps) after a return transition to the conversation
* [x] On Moto G 4G (API 22), the exit transition still uses sliding
* [x] Fix shared element exit transition when the list position is lost (activity was stopped or made into fullscreen)
* [ ] ~~Change shared element of return transition when fullscreen view was swiped to another image when returning~~
* [x] Return transition lands slightly below thumbnail when status bar is hidden
Subtask of #1237.
![device-2018-11-28-175203](/uploads/62e4bbd7bc0af62196bc04c3d8433337/device-2018-11-28-175203.png)
![device-2018-11-28-175149](/uploads/e9f3124a919ca57370ece56e894f3ad6/device-2018-11-28-175149.png)Android 1.3Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1473Implement UX for displaying multiple image attachments2018-12-18T18:21:59ZTorsten GroteImplement UX for displaying multiple image attachmentsSubtask of #1237.Subtask of #1237.Android 1.3Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1468Restrict size of image attachments2021-06-28T08:08:18ZTorsten GroteRestrict size of image attachmentsWe can not process images of arbitrary size, because the device may lack the memory to load the entire image into it or because the maximum texture size is smaller than the image.
* [x] don't read entire images in memory
* [x] scale ful...We can not process images of arbitrary size, because the device may lack the memory to load the entire image into it or because the maximum texture size is smaller than the image.
* [x] don't read entire images in memory
* [x] scale full screen images down to screen size to avoid exceeding max texture size
* [x] add tests for [MarkEnforcingInputStream](https://github.com/bumptech/glide/blob/ad33b8d503024c8a3a6a3da60ce28c4d7732ae58/library/src/main/java/com/bumptech/glide/util/MarkEnforcingInputStream.java)
* [x] tests for our own code that handles the various image types and edge cases
* [x] limit our supported mime types to image/gif, image/jpeg and image/png
* [x] limit the size of images that can be sent
Subtask of #1237.Android 1.3Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1467Improve Conversation Scrolling Behaviour2019-06-17T10:10:29ZTorsten GroteImprove Conversation Scrolling BehaviourCurrently, we scroll down after loading the list of messages (after each activity start). We also scroll down when loading a message text or image asynchronously.
This is problematic, because the user can't scroll up right after a large...Currently, we scroll down after loading the list of messages (after each activity start). We also scroll down when loading a message text or image asynchronously.
This is problematic, because the user can't scroll up right after a large conversation is displayed and because when looking at older photos, the user forcibly gets scrolled to the end of the conversation and needs to find where she was.
Subtask of #1242Android 1.3Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1452Websocket Authentication2018-11-27T10:00:33ZTorsten GroteWebsocket AuthenticationDespite many (older) claims in the internet that you can establish websocket connections with basic auth, this doesn't seem to be true for javascript libraries running in a recent browser. I managed to do it in Python and assumed it will...Despite many (older) claims in the internet that you can establish websocket connections with basic auth, this doesn't seem to be true for javascript libraries running in a recent browser. I managed to do it in Python and assumed it will just work on browsers as well, but it seems that isn't the case. At least I haven't been able to make this work. The only thing we can send in the upgrade request from a browser is a list of protocols. In absence of a standardized authentication mechanism, there's people using this already to pass auth tokens. I confirmed that we can access this header on the server side and check if there's an auth token in it.
If we don't want that hacky (but easy) solution, I am afraid we need to get into the business of tracking each session's authentication state and require them to send a first message with the token before we start sending stuff to it. Maybe even terminate sessions that haven't authenticated after a timeout.Headless MVPTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1438Implement UX for sending image attachments2020-11-16T10:11:30ZTorsten GroteImplement UX for sending image attachmentsWhen the message field is empty, there's an image icon to attach an image:
![Image_Attachment_Preselection](/uploads/cfaa2500f2d39f3b4e9c540d8ce46b88/Image_Attachment_Preselection.png)
Clicking it opens the system file selector:
![Ima...When the message field is empty, there's an image icon to attach an image:
![Image_Attachment_Preselection](/uploads/cfaa2500f2d39f3b4e9c540d8ce46b88/Image_Attachment_Preselection.png)
Clicking it opens the system file selector:
![Image_Attachment_Selection__System_](/uploads/97ad63158569fd22d7dc35b28453e6e4/Image_Attachment_Selection__System_.png)
If chosen image is shown as a preview, with an option to cancel the operation and to add an image caption:
![Confirmation](/uploads/621ca864593e0670f654ebdc832fbf48/Confirmation.png)
A seascape image shows a black/grey or color picked from the image on the sides:
![Confirmation_Tall_Image](/uploads/9ca88cffecbed1ee167835ba5efdd167/Confirmation_Tall_Image.png)
Subtask of #1237.Android 1.3Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1434Implement backend for sending and receiving image attachments2019-11-12T13:45:59ZTorsten GroteImplement backend for sending and receiving image attachments### Receiving Image Attachments
Private message headers will include a list of attachments, and there will be a `MessagingManager` method for loading an attachment, which will include the attachment data as a `ByteBuffer`, later to be c...### Receiving Image Attachments
Private message headers will include a list of attachments, and there will be a `MessagingManager` method for loading an attachment, which will include the attachment data as a `ByteBuffer`, later to be converted to an `InputStream` if we find that loading images into ByteBuffers won't scale.
This implies that private message headers (in the sense of headers belonging to the private messaging client) will no longer correspond to the root class `PrivateMessageHeader` (from which all one-to-one headers currently inherit). The root class may need to be renamed, and some refactoring of the code that handles that hierarchy will be needed.
### Sending Image Attachments
*TODO*: MessagingManager API for creating local messages with optional attachmentsAndroid 1.3Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1432Headless integration tests2020-11-18T17:04:10ZTorsten GroteHeadless integration testsWe should add some integration tests for the REST API endpoints to catch breakage.We should add some integration tests for the REST API endpoints to catch breakage.Headless MVPhttps://code.briarproject.org/briar/briar/-/issues/1386App locks after signing out2018-09-20T11:06:10ZTorsten GroteApp locks after signing outThe app inactivity timeout even kicks in after signing out.
Steps to reproduce:
* activate app lock in settings
* set timeout to 1 minute
* sign out
* wait for one minute
* observe the new locked notification that you can only remove by...The app inactivity timeout even kicks in after signing out.
Steps to reproduce:
* activate app lock in settings
* set timeout to 1 minute
* sign out
* wait for one minute
* observe the new locked notification that you can only remove by signing in againAndroid 1.1Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1358New Design and UX for Message Bubbles2018-08-20T19:47:36ZElio Qoshielio@ura.designNew Design and UX for Message BubblesWhile working on the Dark Theme with @grote we discovered that the message bubble colors required changes made to PNG drawables, split into 9 pieces (for dark, light, incoming, outgoing and system notices). This makes it quite rough to w...While working on the Dark Theme with @grote we discovered that the message bubble colors required changes made to PNG drawables, split into 9 pieces (for dark, light, incoming, outgoing and system notices). This makes it quite rough to work with and is time consuming when it comes to updating changes. Also, the current design is an old message bubble pattern and one can see from Facebook or Telegram that a more rounded approach might be more suitable:
![image](/uploads/59dd7e30bf3126a0e36e9fdbb6e91c9b/image.png)Android 1.1Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1341AccountManager: Refactor authentication and account management code2018-08-20T19:47:46ZTorsten GroteAccountManager: Refactor authentication and account management codeRefactor the authentication and account management code into an `AccountManager` component in the core. At the moment the logic's spread across various parts of the UI.
It might be nice, for example, if we had a single method that would...Refactor the authentication and account management code into an `AccountManager` component in the core. At the moment the logic's spread across various parts of the UI.
It might be nice, for example, if we had a single method that would return an enum for the account state (no account, creating account, signing in, signed in, signing out, signed out), which we could then extend with new states (locked, unlocking).
Sub-ticket of #1247Android 1.1akwizgranakwizgran