briar issueshttps://code.briarproject.org/groups/briar/-/issues2023-08-28T16:08:02Zhttps://code.briarproject.org/briar/public-mesh-research/-/issues/16Initial investigations: Google Nearby2023-08-28T16:08:02ZakwizgranInitial investigations: Google NearbyInvestigate the performance of the (closed source) Google Nearby libraries to see whether they perform better on problematic devices than the other options we've identified.
https://developers.google.com/nearby/Investigate the performance of the (closed source) Google Nearby libraries to see whether they perform better on problematic devices than the other options we've identified.
https://developers.google.com/nearby/Public mesh researchhttps://code.briarproject.org/briar/briar-desktop/-/issues/418When selecting forum post at the bottom, it gets hidden by reply box2022-10-18T12:33:57ZTorsten GroteWhen selecting forum post at the bottom, it gets hidden by reply boxHiding the selected forum post isn't ideal. Maybe we can find a solution here like scrolling the up in this case to keep the item visible.Hiding the selected forum post isn't ideal. Maybe we can find a solution here like scrolling the up in this case to keep the item visible.https://code.briarproject.org/briar/briar-desktop/-/issues/417Enforce custom overloading of IconButton everywhere to support tooltips2022-10-18T12:12:05ZMikolai GütschowEnforce custom overloading of IconButton everywhere to support tooltipsThe following discussion from !250 should be addressed:
- [ ] @ialokim started a [discussion](https://code.briarproject.org/briar/briar-desktop/-/merge_requests/250#note_71894): (+2 comments)
> Please always use our own overloadin...The following discussion from !250 should be addressed:
- [ ] @ialokim started a [discussion](https://code.briarproject.org/briar/briar-desktop/-/merge_requests/250#note_71894): (+2 comments)
> Please always use our own overloading of `IconButton` which enables tooltips on desktop. Another rule we should probably write down somewhere or enforce via linting?https://code.briarproject.org/briar/briar/-/issues/2371Adding remote contact on API 19 crashes the app.2022-10-18T16:52:29ZFlyingP1g FlyingP1gAdding remote contact on API 19 crashes the app.I was adding a remote contact with virtual device (Nexus 5x API 19), it crashed without even giving briar crash fragment. (Tested multiple times)
Adding a remote contact with virtual device (Pixel 4a API 31) works ok.
I was using master ...I was adding a remote contact with virtual device (Nexus 5x API 19), it crashed without even giving briar crash fragment. (Tested multiple times)
Adding a remote contact with virtual device (Pixel 4a API 31) works ok.
I was using master branch and the latest comit was this 718d95f3d5426f8bbb65b8c8664874bb4f6ac53d
Steps to reproduce:
1) Add contact at distance
2) adb shell input text 'briar link'
3) Go to the next screen
4) give nickname and press add contact (Note: sometimes briar doesn't crash instantly, but later, I was never able to add a contact.)
5) Briar should crash
Last lines in Logcat:
```
2022-10-16 14:25:12.140 2745-2745/org.briarproject.briar.android.debug W/dalvikvm: VFY: unable to resolve virtual method 2963: Landroid/widget/Button;.setAutoSizeTextTypeWithDefaults (I)V
2022-10-16 14:25:12.140 2745-2745/org.briarproject.briar.android.debug D/dalvikvm: VFY: replacing opcode 0x6f at 0x0004
2022-10-16 14:25:12.140 2745-2745/org.briarproject.briar.android.debug I/BaseActivity: Resuming StartupActivity
2022-10-16 14:25:12.180 2745-2745/org.briarproject.briar.android.debug D/: HostConnection::get() New Host Connection established 0xb8e34bc0, tid 2745
2022-10-16 14:25:12.180 2745-2745/org.briarproject.briar.android.debug D/EGL_emulation: eglCreateContext: 0xb8e33a00: maj 3 min 1 rcv 4
2022-10-16 14:25:12.220 2745-2745/org.briarproject.briar.android.debug D/EGL_emulation: eglMakeCurrent: 0xb8e33a00: ver 3 1
2022-10-16 14:25:12.220 2745-2745/org.briarproject.briar.android.debug E/eglCodecCommon: glUtilsParamSize: unknow param 0x000082da
2022-10-16 14:25:12.220 2745-2745/org.briarproject.briar.android.debug E/eglCodecCommon: glUtilsParamSize: unknow param 0x00008cdf
2022-10-16 14:25:12.220 2745-2745/org.briarproject.briar.android.debug E/eglCodecCommon: glUtilsParamSize: unknow param 0x00008824
2022-10-16 14:25:12.220 2745-2745/org.briarproject.briar.android.debug E/EGL_emulation: tid 2745: eglSurfaceAttrib(1199): error 0x3009 (EGL_BAD_MATCH)
2022-10-16 14:25:12.220 2745-2745/org.briarproject.briar.android.debug W/HardwareRenderer: Backbuffer cannot be preserved
2022-10-16 14:25:12.220 2745-2745/org.briarproject.briar.android.debug D/OpenGLRenderer: Enabling debug mode 0
2022-10-16 14:25:12.250 2745-2745/org.briarproject.briar.android.debug I/dalvikvm: Could not find method android.view.View.setTooltipText, referenced from method androidx.appcompat.widget.TooltipCompat.setTooltipText
2022-10-16 14:25:12.250 2745-2745/org.briarproject.briar.android.debug W/dalvikvm: VFY: unable to resolve virtual method 2302: Landroid/view/View;.setTooltipText (Ljava/lang/CharSequence;)V
2022-10-16 14:25:12.250 2745-2745/org.briarproject.briar.android.debug D/dalvikvm: VFY: replacing opcode 0x6e at 0x0006
2022-10-16 14:25:12.270 2745-2745/org.briarproject.briar.android.debug I/BaseActivity: Stopping NavDrawerActivity
```https://code.briarproject.org/briar/briar-desktop/-/issues/414Visual bugs with Burmese (my)2022-10-13T12:48:23ZMikolai GütschowVisual bugs with Burmese (my)While testing for !253 we found the following problems with the Burmese script:
- the "change password" button text appears to be cropped
![grafik](/uploads/329ee179312c4eea5a0abd0988da7c7b/grafik.png)
compared to the string in the re...While testing for !253 we found the following problems with the Burmese script:
- the "change password" button text appears to be cropped
![grafik](/uploads/329ee179312c4eea5a0abd0988da7c7b/grafik.png)
compared to the string in the resource file:
![grafik](/uploads/7d284e3d101a44a1cd09435a84ea0580/grafik.png)
- "Pending contact selected" text is not centered if it doesn't fit into one line:
![grafik](/uploads/f9a9758b0c842df1da896bd685fb7e97/grafik.png)
in both cases, the character "း" is involved
---
Most probably an upstream issue, we should find a minimal reproducing example and report it to Compose for Desktop.https://code.briarproject.org/briar/briar-desktop/-/issues/413Take care about languages that dropped below translation threshold2023-02-01T13:44:08ZSebastianTake care about languages that dropped below translation thresholdSome languages have dropped below our threshold for inclusion of currently 50%. The languages affected are Dutch (nl), Korean (ko) and Hebrew (he). They're all around 45% at the moment. If we decided to take them out of the next release ...Some languages have dropped below our threshold for inclusion of currently 50%. The languages affected are Dutch (nl), Korean (ko) and Hebrew (he). They're all around 45% at the moment. If we decided to take them out of the next release we need to remove them from the UI too and take care of the situation of a removed language and see to it that an app set to a removed language behaves properly (doesn't crash etc).Desktop 1.0.0https://code.briarproject.org/briar/briar-desktop/-/issues/410Publish Briar Desktop on Ubuntu/Debian PPA2022-10-05T15:38:51ZMikolai GütschowPublish Briar Desktop on Ubuntu/Debian PPAas discussed today, since #261 still seems quite far from being resolvedas discussed today, since #261 still seems quite far from being resolvedhttps://code.briarproject.org/briar/briar-mailbox/-/issues/164AS cannot resolve version variables in build.gradle2023-08-28T16:00:11ZSebastianAS cannot resolve version variables in build.gradleAfter moving the version variables to the external file at `gradle/variables.gradle` so that they can be reused on briar for the integration tests, it seems while Gradle has no problem using those variables at that location, AS has a pro...After moving the version variables to the external file at `gradle/variables.gradle` so that they can be reused on briar for the integration tests, it seems while Gradle has no problem using those variables at that location, AS has a problem understanding where those variables are defined. As a result Ctrl-clicking the variables does not navigate us to their source and also the version checks that AS usually performs and displays warnings about possible library upgrades does not work. Both are suboptimal I think. I have not found any report for this or upstream issue yet.https://code.briarproject.org/briar/briar-desktop/-/issues/401Permalinks for nightly builds in README are 4042022-09-30T12:41:19ZMikolai GütschowPermalinks for nightly builds in README are 404although the nightly pipelines [do run](https://code.briarproject.org/briar/briar-desktop/-/pipelines/12265) and we use the [permalinks as documented](https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#access-the-latest-job-artif...although the nightly pipelines [do run](https://code.briarproject.org/briar/briar-desktop/-/pipelines/12265) and we use the [permalinks as documented](https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#access-the-latest-job-artifacts-by-url)https://code.briarproject.org/briar/briar-desktop/-/issues/398Find mechanism for checking translations for missing variables or too many va...2023-05-08T14:14:43ZSebastianFind mechanism for checking translations for missing variables or too many variablesIt is possible that some translations contain:
* too many variables, e.g. "Some test {0} some more text {1}" while {1} will never be supplied
* too few variables, e.g. "Some test {0}" while two arguments will be supplied
Both situation ...It is possible that some translations contain:
* too many variables, e.g. "Some test {0} some more text {1}" while {1} will never be supplied
* too few variables, e.g. "Some test {0}" while two arguments will be supplied
Both situation don't cause an error, just a wrongly formatted string at the moment.
I think it would be nice if we could run some static analysis on our strings to check for this.
Maybe there's something like this in the Transifex online tools, not sure.https://code.briarproject.org/briar/briar-desktop/-/issues/397Enforce Twitter Jetpack Compose Rules using ktlint2023-02-02T22:38:06ZMikolai GütschowEnforce Twitter Jetpack Compose Rules using ktlintfound by @grote: https://twitter.github.io/compose-rules/found by @grote: https://twitter.github.io/compose-rules/https://code.briarproject.org/briar/briar-desktop/-/issues/395Prohibit i18n functions outside of Composable layer2022-09-28T11:41:18ZMikolai GütschowProhibit i18n functions outside of Composable layerFrom !240:
- [ ] @ialokim started a [discussion](https://code.briarproject.org/briar/briar-desktop/-/merge_requests/240#note_71107): (+7 comments)
> The problem with using those `i18n` calls outside of the Compose-world is that th...From !240:
- [ ] @ialokim started a [discussion](https://code.briarproject.org/briar/briar-desktop/-/merge_requests/240#note_71107): (+7 comments)
> The problem with using those `i18n` calls outside of the Compose-world is that they probably won't be re-created when the language is changed (this triggers a recomposition of the whole window, but ViewModels and thus Items will be re-used). Now that I'm seeing this, it should probably be a rule not to use `i18n` methods outside of Composables.
>
> ----
> Perhaps we could force the usage of `i18n` functions only inside composables by actually marking those as `@Composable` as well? :thinking:https://code.briarproject.org/briar/briar-desktop/-/issues/394Reconsider usage of `GlobalScope`2023-03-13T22:15:02ZMikolai GütschowReconsider usage of `GlobalScope`The following discussion from !240 should be addressed:
- [ ] @ialokim started a [discussion](https://code.briarproject.org/briar/briar-desktop/-/merge_requests/240#note_70890): (+3 comments)
> Which delicate API do you use here?
...The following discussion from !240 should be addressed:
- [ ] @ialokim started a [discussion](https://code.briarproject.org/briar/briar-desktop/-/merge_requests/240#note_70890): (+3 comments)
> Which delicate API do you use here?
>
> ----
> `GlobalScope.launch {}` which seems to be ok to use here, but if you have another idea like an injected app-wide scope, please let me know.https://code.briarproject.org/briar/briar-desktop/-/issues/393Use `rememberSaveable` wherever appropriate for Android2022-09-23T11:46:27ZMikolai GütschowUse `rememberSaveable` wherever appropriate for AndroidQuoting from !240:
- [ ] @ialokim started a [discussion](https://code.briarproject.org/briar/briar-desktop/-/merge_requests/240#note_70876): (+4 comments)
> We have always used `remember` instead of `rememberSaveable`. I know that...Quoting from !240:
- [ ] @ialokim started a [discussion](https://code.briarproject.org/briar/briar-desktop/-/merge_requests/240#note_70876): (+4 comments)
> We have always used `remember` instead of `rememberSaveable`. I know that this is needed on Android for, e.g., configuration changes. Are you aware of any consequences on Desktop though?
>
> ----
>
> No, don't know how this works on desktop. However, I'd argue best to use `rememberSaveable` everywhere where we'd want it in Android, to a) practice using it and recognizing when it is needed and b) to allow us one day to unify the UI codebases of both projects in an easier fashion.https://code.briarproject.org/briar/briar/-/issues/2365DesktopLifecycleModule extends LifecycleModule which probably doesn't work2022-09-21T19:16:45ZSebastianDesktopLifecycleModule extends LifecycleModule which probably doesn't workSee [this discussion](https://code.briarproject.org/briar/briar/-/merge_requests/1699#note_71081) on IoModule and TestIoModule which had a similar problem.See [this discussion](https://code.briarproject.org/briar/briar/-/merge_requests/1699#note_71081) on IoModule and TestIoModule which had a similar problem.https://code.briarproject.org/briar/briar-desktop/-/issues/390Image compressor unable to compress file to 32kb2022-12-09T08:26:46ZSebastianImage compressor unable to compress file to 32kbI found an image for which our ImageCompressor implementation fails to compress it to the required file size:
https://unsplash.com/photos/EHcIO_3DbOg
This is the log:
```
Exception in thread "Thread-13" java.io.IOException
at o...I found an image for which our ImageCompressor implementation fails to compress it to the required file size:
https://unsplash.com/photos/EHcIO_3DbOg
This is the log:
```
Exception in thread "Thread-13" java.io.IOException
at org.briarproject.briar.desktop.attachment.media.ImageCompressorImpl.compressImage(ImageCompressorImpl.kt:86)
at org.briarproject.briar.desktop.conversation.ConversationViewModel$sendMessage$1.invoke(ConversationViewModel.kt:180)
at org.briarproject.briar.desktop.conversation.ConversationViewModel$sendMessage$1.invoke(ConversationViewModel.kt:175)
at kotlin.concurrent.ThreadsKt$thread$thread$1.run(Thread.kt:30)
```
[ImageCompressorImpl.kt:86](https://code.briarproject.org/briar/briar-desktop/-/blob/main/briar-desktop/src/main/kotlin/org/briarproject/briar/desktop/attachment/media/ImageCompressorImpl.kt#L86)
We have this there:
```kotlin
for (quality in 100 downTo 1 step 10) {
val jpgWriter = ImageIO.getImageWritersByFormatName("jpg").next()
jpgWriter.output = ImageIO.createImageOutputStream(out)
val jpgWriteParam = jpgWriter.defaultWriteParam
jpgWriteParam.compressionMode = ImageWriteParam.MODE_EXPLICIT
jpgWriteParam.compressionQuality = quality / 100f
val outputImage = IIOImage(scaled, null, null)
jpgWriter.write(null, outputImage, jpgWriteParam)
jpgWriter.dispose()
if (out.size() <= MAX_IMAGE_SIZE) {
LOG.i { "Compressed image to ${out.size()} bytes, quality $quality" }
return ByteArrayInputStream(out.toByteArray())
}
out.reset()
}
throw IOException()
```
I have not yet debugged this, but I'm wondering what the lowest quality is that we actually try. We start with 100 but do we reach 1 or 10 as the last value? Edit: I just checked. We never reach 1 but the lowest value we try is 10. I guess we probably should change this to try quality 1 and in doubt even reduce image dimensions if even that does not suffice.
This is the full image:
![imran-hecimovic-EHcIO_3DbOg-unsplash](/uploads/800f92fcdac18eb25a9e43417961d99a/imran-hecimovic-EHcIO_3DbOg-unsplash.jpg)https://code.briarproject.org/briar/public-mesh-research/-/issues/15Initial investigations: wifi client2023-08-28T16:08:02ZakwizgranInitial investigations: wifi clientInvestigate our options for connecting to a wifi hotspot (which could be a WFD legacy mode hotspot) as a wifi client, rather than by using the WFD API.
The APIs available for connecting to wifi networks have changed a lot over the years...Investigate our options for connecting to a wifi hotspot (which could be a WFD legacy mode hotspot) as a wifi client, rather than by using the WFD API.
The APIs available for connecting to wifi networks have changed a lot over the years, so we'll need to test on a lot of different API versions.
Questions:
* Can we scan for available networks? How often? What permissions are needed? Can we access the SSIDs of the networks?
* Can we request a connection to a network that's not currently in range? If so, do we connect automatically when the network comes in range? What if the client's screen is off? Is the connection kept if the network doesn't have internet access?
* If two or more devices are providing hotspots with the same SSID and password, can a client roam from one to the other?
* If a client has previously connected to a hotspot and accepted the dialog that warns about no internet access, is the dialog shown again when reconnecting to the same hotspot? Is it shown again when connecting to a different device's hotspot that uses the same SSID and password?
Subtask of #1. Related to #5.Public mesh researchakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/2364Do we need a revocation mechanism or remote-destruction? Is it helpful?2022-09-15T09:20:43ZThomasDo we need a revocation mechanism or remote-destruction? Is it helpful?Hi!
I found this ancient thread:https://sourceforge.net/p/briar/mailman/briar-devel/thread/4F33A780.8050705%40gmx.com/#msg28809772
>(Starting a new thread for this because the old thread was getting frayed.)
>
>On 09/02/12 03:14, awgh wr...Hi!
I found this ancient thread:https://sourceforge.net/p/briar/mailman/briar-devel/thread/4F33A780.8050705%40gmx.com/#msg28809772
>(Starting a new thread for this because the old thread was getting frayed.)
>
>On 09/02/12 03:14, awgh wrote:
>> - Cert revocations are signed with the cert they're revoking. If that
>> cert isn't in the local table, this is one string compare. Not much of
>> a DoS.
>
>Cool, I think we have the beginnings of a design here. Thanks Ben!
>
>1. Each user creates a personal keypair (this is separate from any
>pseudonyms she may create).
>
>2. The user creates a revocation certificate and signs it with the
>private key.
>
>3. The user applies a secret sharing algorithm to the revocation
>certificate. She chooses a few trusted friends and sends each friend a
>SAVE_SHARE message, which contains a share of the revocation certificate
>and the ID of the key.
>
>4. The user creates a KEY_ID message containing the ID of the key and
>sends it to any contacts who didn't receive shares.
>
>5. If a friend thinks the user's key has been compromised, she creates a
>REVOKE_SHARE message containing her share of the certificate and the ID
>of the key. She stores the message and sends it to all her contacts.
>
>6. If a user receives a REVOKE_SHARE message and recognises the ID, she
>stores the message and forwards it to all her contacts.
>
>7. If a user receives enough shares to reconstruct the revocation
>certificate, she considers the key revoked. She creates a REVOKE_CERT
>message containing the certificate, stores the message and sends it to
>all her contacts.
>
>8. If a user receives a REVOKE_CERT message and recognises the ID, she
>considers the key revoked, stores the message and forwards it to all her
>contacts.
>
>Does this look like a reasonable start?
>
>Cheers,
>Michael
I know that a lot has changed since then. But do we need a revocation mechanism in Briar now?
It also made me think: Is a remote-identity-destruction-mechanism helpful? (If the phone gets into the wrong hands and the phone can still access another contact some way - that contacts can together derive a revocation-key which tells the phone to delete the Briar-Identity?) Or is that remote-mechanism more in the scope of a panic-button-app?https://code.briarproject.org/briar/briar-spec/-/issues/16Not documented: What if BSP-Content > max length of frame data2022-09-15T09:05:44ZThomasNot documented: What if BSP-Content > max length of frame dataHi!
I already got that info through debugging, but I didn't find in the doc what happend when BSP-Data is bigger than the content of a BTP-Frame is allowed to be - that is is just sliced and the next frame starts directly with the conten...Hi!
I already got that info through debugging, but I didn't find in the doc what happend when BSP-Data is bigger than the content of a BTP-Frame is allowed to be - that is is just sliced and the next frame starts directly with the content without having a header.https://code.briarproject.org/briar/briar-spec/-/issues/15clarify things around contact initiation2022-09-15T08:49:39ZThomasclarify things around contact initiationHi!
It it not really clear for me when reading the Specs when BHP is used. Basically it is only used currently in the Endpoint created in.
I would add clarification to BHP, BRP and also generally tackle BHP+BRP in https://code.briarproje...Hi!
It it not really clear for me when reading the Specs when BHP is used. Basically it is only used currently in the Endpoint created in.
I would add clarification to BHP, BRP and also generally tackle BHP+BRP in https://code.briarproject.org/briar/briar/-/wikis/A-Quick-Overview-of-the-Protocol-Stack .
The Key Agreement Protocol (https://chat.briarproject.org/briar/pl/rzro8mqxx7fz9x3cfmaejrkkbr ) is also currently never mentioned or specified.