briar issueshttps://code.briarproject.org/briar/briar/-/issues2020-11-15T18:26:32Zhttps://code.briarproject.org/briar/briar/-/issues/1568Test the effects of dormant mode when operating as a Tor client2020-11-15T18:26:32ZakwizgranTest the effects of dormant mode when operating as a Tor clientTest whether a Briar peer that's not running a hidden service or holding a wake lock can operate as a Tor client (i.e. connect to contacts' hidden services and fetch RSS feeds), and whether this is affected by Tor's dormant mode.Test whether a Briar peer that's not running a hidden service or holding a wake lock can operate as a Tor client (i.e. connect to contacts' hidden services and fetch RSS feeds), and whether this is affected by Tor's dormant mode.https://code.briarproject.org/briar/briar/-/issues/1569Connection manager could fail to close connection2020-11-15T18:24:37ZakwizgranConnection manager could fail to close connectionWhen the connection manager disposes of the incoming side of a duplex connection, it interrupts the outgoing sync session (if any) so the outgoing session can finish cleanly. If this happens before the outgoing session is created, it won...When the connection manager disposes of the incoming side of a duplex connection, it interrupts the outgoing sync session (if any) so the outgoing session can finish cleanly. If this happens before the outgoing session is created, it won't be interrupted.
If the incoming side of the connection is being disposed of because of an exception then the transport connection will be closed, so the outgoing session should eventually catch an exception when it tries to write to the connection. But if the incoming side of the connection is being disposed of because the end of the stream was reached then the transport connection will be left half-open, so the outgoing session could keep running indefinitely. This might also happen in the case of an exception if there's nothing to send and the transport doesn't require keepalives, which is the case for Bluetooth.
This could result in a dangling connection that's only usable in one direction. As far as I can tell it won't prevent a new connection from being made, or cause issues like !921, because the registration and unregistration of duplex connections is based on the lifetime of the incoming session, not the outgoing session.
The opposite can also happen: if the connection manager disposes of the outgoing side of the connection before the incoming session is created, the incoming session won't be interrupted. This can only happen if an exception has been thrown (in which case the transport connection will be closed, which *should* cause the incoming session to catch an exception eventually), or if the outgoing session has finished cleanly, which only happens if it's interrupted due to the incoming side of the connection being disposed of. So the only possible cause of a bug like !921 in this case would be if closing the connection didn't cause the incoming session to catch an exception (flaky Bluetooth stacks, I'm looking at you).
Labelling this as a bug because it's unintended behaviour, although it's not clear if we need to fix it.https://code.briarproject.org/briar/briar/-/issues/1574Consider separating the package structures for bramble-java and bramble-core2020-11-15T18:21:38ZiwakehConsider separating the package structures for bramble-java and bramble-coreConsider using a separate package for ```bramble-java``` (e.g. ```org.briarproject.bramble.java.*```)
Currently, ```bramble-java``` provides the same packages as ```bramble-core```.
Some ```bramble-java``` classes extend package-private...Consider using a separate package for ```bramble-java``` (e.g. ```org.briarproject.bramble.java.*```)
Currently, ```bramble-java``` provides the same packages as ```bramble-core```.
Some ```bramble-java``` classes extend package-private classes from ```bramble-core``` (mostly in bluetooth). Hmm ....
When briar is going to use java >= 9 and provides modules this needs to be addressed anyway.
(I believe briar should be around for many, many new java versions to come ;-)https://code.briarproject.org/briar/briar/-/issues/1578Improve structure of Briar Headless API documentation2021-03-22T10:52:52ZNicoImprove structure of Briar Headless API documentationCurrently, the documentation for the API is directly written into [its readme file](https://code.briarproject.org/briar/briar/blob/release-1.1.7/briar-headless/README.md). That's fine for the beginning, [I was even able to build a first ...Currently, the documentation for the API is directly written into [its readme file](https://code.briarproject.org/briar/briar/blob/release-1.1.7/briar-headless/README.md). That's fine for the beginning, [I was even able to build a first prototype with it](https://nico.dorfbrunnen.eu/posts/2019/briar-first-demo/).
However, I suggest to improve the structure of the documentation by moving it into a separate repository. My suggestion was to create a Hugo page with a docs theme (or some other static site generator) at docs.briarproject.org.
@grote's response to this was (loosely translated by me): "Best to make the documentation directly into the code with swagger"
My response to this now: OK, we can do this, but I don't know how much sense it makes to put a lot of basic explanations into code. E.g. all the valuable information collected in https://code.briarproject.org/briar/briar/issues/1577.
**Update:** I agree with Torsten that it's best to generate the documentation from code. That's what I do with [`briar_wrapper`](https://code.briarproject.org/briar/python-briar-wrapper), too, at https://wrapper.docs.briarproject.org/ and the API's docs can be hosted at https://api.docs.briarproject.org/, imho.CleopatraCleopatrahttps://code.briarproject.org/briar/briar/-/issues/1581Add pending contact via ENTER or IME action2020-11-15T18:20:32ZTorsten GroteAdd pending contact via ENTER or IME actionWhen entering the nickname for a pending contact pressing enter or the Go IME action in the soft keyboard should be equivalent to pressing the button.When entering the nickname for a pending contact pressing enter or the Go IME action in the soft keyboard should be equivalent to pressing the button.https://code.briarproject.org/briar/briar/-/issues/1582Pending contact snackbar and add contact FAB are sometimes displaced2022-04-19T11:29:51ZakwizgranPending contact snackbar and add contact FAB are sometimes displacedThe pending contact snackbar sometimes appears in the wrong place, with a blank space below it and overlapping the FAB. After the snackbar is hidden, the FAB doesn't always return to the right position.
![device-2019-06-07-162517](/uplo...The pending contact snackbar sometimes appears in the wrong place, with a blank space below it and overlapping the FAB. After the snackbar is hidden, the FAB doesn't always return to the right position.
![device-2019-06-07-162517](/uploads/9109a6a1d3e0fbeccdb1e25d1c5796b7/device-2019-06-07-162517.png)
![device-2019-06-07-162537](/uploads/01cc37afca368254ff312281f3f8d992/device-2019-06-07-162537.png)
I've seen the first problem on the Huawei Ascend Y330 (Android 4.2.2) and the Vivo Y11 (Android 4.4.4). I've seen the second problem on those phones and also the Honor 8A (Android 9).https://code.briarproject.org/briar/briar/-/issues/1588New setting: Time window / Interval in which Briar goes online2022-01-04T16:11:37ZmicressorNew setting: Time window / Interval in which Briar goes onlineI want a way to set Briar so that the app connects at an interval of X for Y minutes to synchronize messages.
As a second possibility, a period where Briar connects to synchronize messages. For example between X and Y o'clock every day....I want a way to set Briar so that the app connects at an interval of X for Y minutes to synchronize messages.
As a second possibility, a period where Briar connects to synchronize messages. For example between X and Y o'clock every day.
The idea behind it is to make online time more effective due to the high battery consumption. Two users could agree to configure their Briar Apps between X and Y to go online and synchronize messages.https://code.briarproject.org/briar/briar/-/issues/1589Use consistent scroll behaviour across the app2021-12-21T23:12:35ZakwizgranUse consistent scroll behaviour across the appFollowing the discussion on #713 and other tickets listed below, let's use consistent scroll behaviour across the app.
Related to #713, #872, #1073, #1192, #1200, #1361, #1337, #1467, #1493.Following the discussion on #713 and other tickets listed below, let's use consistent scroll behaviour across the app.
Related to #713, #872, #1073, #1192, #1200, #1361, #1337, #1467, #1493.https://code.briarproject.org/briar/briar/-/issues/1595Add blocks table to database2022-06-15T12:02:17ZakwizgranAdd blocks table to databaseSubtask of #1240Subtask of #1240Multi-block messagesakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1596Make migrations idempotent where possible2020-11-15T18:14:12ZakwizgranMake migrations idempotent where possibleThe database migrations use data definition commands (`ALTER TABLE`, etc) that H2 commits automatically as soon as they're executed, even though we execute the commands within a transaction. If a crash happens during a migration, the DB ...The database migrations use data definition commands (`ALTER TABLE`, etc) that H2 commits automatically as soon as they're executed, even though we execute the commands within a transaction. If a crash happens during a migration, the DB may be left in a state where the migration has been partially applied. If the data definition commands aren't idempotent then subsequent attempts to apply the migration will fail, making it impossible to complete the migration and open the DB.
Where possible we should use data definition commands that are idempotent. For example, `DELETE COLUMN` should be `DELETE COLUMN IF EXISTS`, `CREATE COLUMN` should be `CREATE COLUMN IF NOT EXISTS`, etc.https://code.briarproject.org/briar/briar/-/issues/1600AttachmentRetrieverIntegrationTest fails on emulator2020-11-15T18:13:33ZakwizgranAttachmentRetrieverIntegrationTest fails on emulatorSeveral tests in AttachmentRetrieverIntegrationTest fail on the API 21 emulator. It looks like some of them failed in the original commit of the test (it was called AttachmentControllerTest at the time) and others have been broken by sub...Several tests in AttachmentRetrieverIntegrationTest fail on the API 21 emulator. It looks like some of them failed in the original commit of the test (it was called AttachmentControllerTest at the time) and others have been broken by subsequent changes.
The failures from the original commit all seem to involve the same issue: the file extension being `jpeg` rather than `jpg`. I guess the platform's behaviour probably changed some time between API 21 and now, and it doesn't seem likely to cause problems beyond the test failure.
```
org.junit.ComparisonFailure: expected:<jp[]g> but was:<jp[e]g>
at org.briarproject.briar.android.conversation.AttachmentControllerTest.testSmallJpegImageHealsWrongMimeType(AttachmentControllerTest.java:125)
...
org.junit.ComparisonFailure: expected:<jp[]g> but was:<jp[e]g>
at org.briarproject.briar.android.conversation.AttachmentControllerTest.testHighError(AttachmentControllerTest.java:317)
...
org.junit.ComparisonFailure: expected:<jp[]g> but was:<jp[e]g>
at org.briarproject.briar.android.conversation.AttachmentControllerTest.testWideError(AttachmentControllerTest.java:332)
...
org.junit.ComparisonFailure: expected:<jp[]g> but was:<jp[e]g>
at org.briarproject.briar.android.conversation.AttachmentControllerTest.testNoSizeJpeg(AttachmentControllerTest.java:71)
...
org.junit.ComparisonFailure: expected:<jp[]g> but was:<jp[e]g>
at org.briarproject.briar.android.conversation.AttachmentControllerTest.testSmallJpegImage(AttachmentControllerTest.java:109)
...
org.junit.ComparisonFailure: expected:<jp[]g> but was:<jp[e]g>
at org.briarproject.briar.android.conversation.AttachmentControllerTest.testBigJpegImage(AttachmentControllerTest.java:141)
...
org.junit.ComparisonFailure: expected:<jp[]g> but was:<jp[e]g>
at org.briarproject.briar.android.conversation.AttachmentControllerTest.testLottaPixels(AttachmentControllerTest.java:203)
```
The failures on current master involve content types as well as file extensions.
```
org.junit.ComparisonFailure: expected:<image/[gif]> but was:<image/[jpeg]>
at org.briarproject.briar.android.attachment.AttachmentRetrieverIntegrationTest.testGimpCrash(AttachmentRetrieverIntegrationTest.java:156)
...
org.junit.ComparisonFailure: expected:<image/[gif]> but was:<image/[jpeg]>
at org.briarproject.briar.android.attachment.AttachmentRetrieverIntegrationTest.testUberGif(AttachmentRetrieverIntegrationTest.java:111)
...
org.junit.ComparisonFailure: expected:<image/[pn]g> but was:<image/[jpe]g>
at org.briarproject.briar.android.attachment.AttachmentRetrieverIntegrationTest.testImageIoCrash(AttachmentRetrieverIntegrationTest.java:141)
...
org.junit.ComparisonFailure: expected:<image/[gif]> but was:<image/[jpeg]>
at org.briarproject.briar.android.attachment.AttachmentRetrieverIntegrationTest.testOptiPngAfl(AttachmentRetrieverIntegrationTest.java:171)
...
org.junit.ComparisonFailure: expected:<jp[]g> but was:<jp[e]g>
at org.briarproject.briar.android.attachment.AttachmentRetrieverIntegrationTest.testHighError(AttachmentRetrieverIntegrationTest.java:241)
...
org.junit.ComparisonFailure: expected:<jp[]g> but was:<jp[e]g>
at org.briarproject.briar.android.attachment.AttachmentRetrieverIntegrationTest.testWideError(AttachmentRetrieverIntegrationTest.java:256)
...
org.junit.ComparisonFailure: expected:<jp[]g> but was:<jp[e]g>
at org.briarproject.briar.android.attachment.AttachmentRetrieverIntegrationTest.testSmallJpegImage(AttachmentRetrieverIntegrationTest.java:65)
...
org.junit.ComparisonFailure: expected:<jp[]g> but was:<jp[e]g>
at org.briarproject.briar.android.attachment.AttachmentRetrieverIntegrationTest.testBigJpegImage(AttachmentRetrieverIntegrationTest.java:81)
...
org.junit.ComparisonFailure: expected:<jp[]g> but was:<jp[e]g>
at org.briarproject.briar.android.attachment.AttachmentRetrieverIntegrationTest.testLottaPixels(AttachmentRetrieverIntegrationTest.java:127)
```https://code.briarproject.org/briar/briar/-/issues/1601Delete block rows for deleted messages2022-06-15T12:02:17ZakwizgranDelete block rows for deleted messagesAs well as deleting the content of blocks when we delete a message, it would be nice if we could delete the rows from the blocks table.
Subtask of #1239.As well as deleting the content of blocks when we delete a message, it would be nice if we could delete the rows from the blocks table.
Subtask of #1239.Multi-block messageshttps://code.briarproject.org/briar/briar/-/issues/1602Add block status table to database2022-06-15T12:02:16ZakwizgranAdd block status table to databaseFor multi-block messages we need to track the sync status of individual blocks as well as whole messages.
Subtask of #1240.For multi-block messages we need to track the sync status of individual blocks as well as whole messages.
Subtask of #1240.Multi-block messagesakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1608Can't scan QR code in low light2020-11-15T18:09:33ZakwizgranCan't scan QR code in low lightSome phones can't scan QR codes from screens in low light because the camera automatically adjusts the exposure, making the other phone's screen a white blur. I've seen this before on older phones but assumed it was a dying problem. But ...Some phones can't scan QR codes from screens in low light because the camera automatically adjusts the exposure, making the other phone's screen a white blur. I've seen this before on older phones but assumed it was a dying problem. But the problem also exists on the Honor 8A (Android 9), making it impossible to add contacts between the Honor 8A and the Ascend Y330 in low light. (The Y330's low res screen contributes to the problem; the Honor 8A can scan the Nexus 5's screen in the same lighting conditions, for example.)
We should see whether auto exposure can be disabled, and whether this helps.https://code.briarproject.org/briar/briar/-/issues/1613Briar dependency error (Android studio)2020-11-15T18:07:51ZjomocuBriar dependency error (Android studio)Hi, I'm trying to edit and compile briar.
I have imported the project, but it shows the following error.
**ERROR: No dependency for integrity assertion 'cglib:cglib:3.2.0:cglib-3.2.0.jar:adb13bab79712ad6bdf1bd59f2a3918018a8016e722e8a357...Hi, I'm trying to edit and compile briar.
I have imported the project, but it shows the following error.
**ERROR: No dependency for integrity assertion 'cglib:cglib:3.2.0:cglib-3.2.0.jar:adb13bab79712ad6bdf1bd59f2a3918018a8016e722e8a357065afb9e6690861'**
What am I doing wrong?
Thanks greetingshttps://code.briarproject.org/briar/briar/-/issues/1615Upgrade process like apt and use torrents2020-11-15T18:06:51ZPratiwirUpgrade process like apt and use torrentsI would like to suggest doing a more modular upgrade process the same way that is used in termux where apt is used to fetch code. Thus Briar could be upgraded piecewise using a cut down version of apt.
I also propose using torrents soft...I would like to suggest doing a more modular upgrade process the same way that is used in termux where apt is used to fetch code. Thus Briar could be upgraded piecewise using a cut down version of apt.
I also propose using torrents software within Briar, as an additional way to fetch and verify any upgrade files, so that play store could become superfluous once the initial install is made. The torrents component could be activated as needed and used to voluntarily help distribute system files to other users.
I am suggesting this because other apps have this problem of constantly having to uograde. To do this anonymously needs f-droid or yalp store over tor, but the downloads are slow and have a high failure rate, needing to keep restart the download when secure communications apps are being fetched.
It is imho key to have anonymous downloads and easy software distribution not subject to packet injection and blocking.https://code.briarproject.org/briar/briar/-/issues/1617the headless module should reject its own link2020-10-31T12:52:12Ziwakehthe headless module should reject its own linkbriar headless should reject adding a pending contact when it receives its own link.briar headless should reject adding a pending contact when it receives its own link.https://code.briarproject.org/briar/briar/-/issues/1619New chat category: Emergency forum.2020-11-15T18:05:14ZVladislavNew chat category: Emergency forum.What for?
In emergency situation, to be able to write message in emergency forum, that can be seen by anybody in this group, even if not in your contact list. With possibility to block user (if spammer).
Works only in WiFi-Direct, Bluet...What for?
In emergency situation, to be able to write message in emergency forum, that can be seen by anybody in this group, even if not in your contact list. With possibility to block user (if spammer).
Works only in WiFi-Direct, Bluetooth.https://code.briarproject.org/briar/briar/-/issues/1620SuperNotCalledException when sharing link2020-11-15T18:04:01ZakwizgranSuperNotCalledException when sharing link* Android version: 4.0.4
* Briar version 1.1.9 (b1dfd86)
* Phone model: x86 emulator
Steps to reproduce:
* Open remote contact screen
* Tap share button
* Close the app chooser by tapping outside of the chooser or pressing back
Stackt...* Android version: 4.0.4
* Briar version 1.1.9 (b1dfd86)
* Phone model: x86 emulator
Steps to reproduce:
* Open remote contact screen
* Tap share button
* Close the app chooser by tapping outside of the chooser or pressing back
Stacktrace:
```
android.app.SuperNotCalledException: Activity {android/com.android.internal.app.ChooserActivity} did not call through to super.onStop()
at android.app.Activity.performStop(Activity.java:4606)
at android.app.ActivityThread.performDestroyActivity(ActivityThread.java:3071)
at android.app.ActivityThread.handleDestroyActivity(ActivityThread.java:3130)
at android.app.ActivityThread.access$1200(ActivityThread.java:123)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1180)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:4424)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551)
at dalvik.system.NativeStart.main(Native Method)
```
This looks like a bug in the platform's ChooserActivity so I'm not adding it to the milestone.https://code.briarproject.org/briar/briar/-/issues/1622Import Twitter feeds as RSS via Nitter2020-11-15T18:01:12ZakwizgranImport Twitter feeds as RSS via NitterNitter is a privacy-oriented Twitter frontend that proxies client requests to twitter.com. It allows Twitter feeds to be accessed via RSS. We could use this to import Twitter feeds (read-only) as Briar blogs.Nitter is a privacy-oriented Twitter frontend that proxies client requests to twitter.com. It allows Twitter feeds to be accessed via RSS. We could use this to import Twitter feeds (read-only) as Briar blogs.