briar issueshttps://code.briarproject.org/groups/briar/-/issues2023-05-16T16:11:21Zhttps://code.briarproject.org/briar/onionwrapper/-/issues/10Calling start() moves state to CONNECTING2023-05-16T16:11:21ZTorsten GroteCalling start() moves state to CONNECTINGThe expected behavior is to go from `STARTING_STOPPING` to `DISABLED` it seems, which does seem a bit weird from an external library user perspective to be honest.The expected behavior is to go from `STARTING_STOPPING` to `DISABLED` it seems, which does seem a bit weird from an external library user perspective to be honest.akwizgranakwizgranhttps://code.briarproject.org/briar/tor-reproducer/-/issues/14Optimize build time for macOS binaries2023-07-13T11:02:08ZSebastianOptimize build time for macOS binariesWith our current approach of building the tor binaries for macOS using the [tor-browser-build](https://gitlab.torproject.org/tpo/applications/tor-browser-build/) setup, the build takes rather long (~ 3.5 hours).
The cause of this is tha...With our current approach of building the tor binaries for macOS using the [tor-browser-build](https://gitlab.torproject.org/tpo/applications/tor-browser-build/) setup, the build takes rather long (~ 3.5 hours).
The cause of this is that the build does build lots of tools from source itself such as `cmake` and `clang` to name the building blocks that take up roughly 73% of the build time. Here's a full list of things it builds with the timestamps giving indication of how long it takes. The difference from the item to its predecessor is the time it takes to build, e.g. `cmake` takes 7 minutes in this instance (which is quicker than the actual CI hardware because the machine that was used here has better hardware):
```
drwxr-xr-x 2 z z 4,0K May 2 09:00 mmdebstrap
drwx------ 2 z z 4,0K May 2 09:01 mmdebstrap-image
drwxr-xr-x 2 z z 4,0K May 2 09:01 container-image
drwx------ 2 z z 4,0K May 2 09:08 cmake
drwxr-xr-x 2 z z 4,0K May 2 09:10 llvm-project
drwx------ 2 z z 4,0K May 2 09:12 ninja
drwx------ 2 z z 4,0K May 2 10:17 clang
drwx------ 2 z z 4,0K May 2 10:23 libtapi
drwx------ 2 z z 4,0K May 2 10:25 cctools
drwx------ 2 z z 4,0K May 2 10:31 macosx-toolchain
drwx------ 2 z z 4,0K May 2 10:34 openssl
drwx------ 2 z z 4,0K May 2 10:35 libevent
drwx------ 2 z z 4,0K May 2 10:38 tor
```
A solution could be to let the build just not build some of those and instead use Debian snapshot repos to get deterministic versions of cmake, clang etc. during build.
On an upstream ticket, it was suggested, that it's possible to disable the use of containers when building tor, which would result in the requirement of installing in the docker container all the dependencies needed for the build. (see https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40819#note_2899611)
Although this comment was given to solve a problem with docker in docker, I had the impression it also might help to reduce the build time. However it looks like `clang`, the most important building block (>66% of build time), is not among the tools that are then expected to be installed on the CI machine, it's still built from source.
I expect meddling with the tor build system to be a bit tricky even though it looks quite well structured. But I bet there is a way to make the build just use `clang` and `cmake` from the system instead of building it from source itself.
The same upstream ticket had a suggestion about reducing build times, too (see https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40819#note_2899637):
> If you are able to keep the `out` directory accross builds, then it should not rebuild the dependencies.
I don't think though, that this is helpful for us. Well we could build those bits as part of the docker image, but as this runs as part of our pipeline as well, we won't gain much in total, only for reproducing locally maybe.https://code.briarproject.org/briar/onionwrapper/-/issues/9Add method for getting Country name to location utils2023-05-12T14:58:38ZTorsten GroteAdd method for getting Country name to location utils```kotlin
val currentCountry: String
get() = Locale.getAvailableLocales().find { locale ->
locale.country.equals(currentCountry, ignoreCase = true)
}?.displayCountry ?: currentCountry
``````kotlin
val currentCountry: String
get() = Locale.getAvailableLocales().find { locale ->
locale.country.equals(currentCountry, ignoreCase = true)
}?.displayCountry ?: currentCountry
```Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar-desktop/-/issues/520Include date in logs instead of just the time of day2023-05-08T14:12:24ZSebastianInclude date in logs instead of just the time of dayA user reported that it's difficult to make sense of logs if the date is missing. I can see the point.A user reported that it's difficult to make sense of logs if the date is missing. I can see the point.SebastianSebastianhttps://code.briarproject.org/briar/briar-desktop/-/issues/519Noticing missing string resource: alternative to silent log?2023-05-08T14:14:43ZMikolai GütschowNoticing missing string resource: alternative to silent log?When a key is used in one of our `i18n*` functions, for which no string exists neither in the translation nor in the English resource file, we currently just print a message to the log and return an empty string. Maybe it might be better...When a key is used in one of our `i18n*` functions, for which no string exists neither in the translation nor in the English resource file, we currently just print a message to the log and return an empty string. Maybe it might be better to either hard-crash the program (following Briar's crash-early strategy) or have some other way of making sure at compile time all strings are actually present (and no keys are misspelled).https://code.briarproject.org/briar/onionwrapper/-/issues/8Reset bridges if enabling bridges with empty list2023-05-12T16:52:30ZTorsten GroteReset bridges if enabling bridges with empty list`enableBridges()` to call `resetConf("Bridge")` if bridge list is empty.`enableBridges()` to call `resetConf("Bridge")` if bridge list is empty.Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/onionwrapper/-/issues/7Include AndroidLocationUtils in onionwrapper-android2023-05-10T17:24:41ZTorsten GroteInclude AndroidLocationUtils in onionwrapper-androidThe location is needed for the API, so we might as well include a tool to get it.The location is needed for the API, so we might as well include a tool to get it.Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/onionwrapper/-/issues/6Unintuitive API: TorWrapper#start() doesn't actually start, unless enableNetw...2023-05-10T17:24:32ZTorsten GroteUnintuitive API: TorWrapper#start() doesn't actually start, unless enableNetwork() get calledYou call `TorWrapper#start()` and expect things to work. There's some JavaDoc somewhere that enableNetwork() is needed, but not really easy to find.You call `TorWrapper#start()` and expect things to work. There's some JavaDoc somewhere that enableNetwork() is needed, but not really easy to find.https://code.briarproject.org/briar/onionwrapper/-/issues/5Expose location of obfs4Executable for use with Moat2023-05-10T17:24:23ZTorsten GroteExpose location of obfs4Executable for use with MoatOur moat library needs a obfs4Executable to work with. Currently, there's no way to get this.Our moat library needs a obfs4Executable to work with. Currently, there's no way to get this.https://code.briarproject.org/briar/onionwrapper/-/issues/4TorState distinguish stopping from stopped2023-05-16T16:11:21ZTorsten GroteTorState distinguish stopping from stoppedThis may be needed to not start a new instance of TorWrapper, before the old one has stopped.
The wrapper already has code that waits for the tor process to exit, so hopefully we can use that to distinguish stopping from stopped.This may be needed to not start a new instance of TorWrapper, before the old one has stopped.
The wrapper already has code that waits for the tor process to exit, so hopefully we can use that to distinguish stopping from stopped.akwizgranakwizgranhttps://code.briarproject.org/briar/onionwrapper/-/issues/3TorState distinguish stopping/stopped from starting2023-05-16T16:11:21ZTorsten GroteTorState distinguish stopping/stopped from startingCurrently, in state terms those are the same while they are really different in practice.Currently, in state terms those are the same while they are really different in practice.akwizgranakwizgranhttps://code.briarproject.org/briar/onionwrapper/-/issues/2Package private implementation hard to use2023-05-10T17:25:59ZTorsten GrotePackage private implementation hard to use`AndroidWakeLockManagerImpl` and `CircumventionProviderImpl` are both package-private, so they require some hoops to jump through to be used.
we could add a factory method for that, perhaps?
A public factory for `AndroidWakeLockManage...`AndroidWakeLockManagerImpl` and `CircumventionProviderImpl` are both package-private, so they require some hoops to jump through to be used.
we could add a factory method for that, perhaps?
A public factory for `AndroidWakeLockManager`, maybe with two methods, one allows passing in your own `ScheduledExecutorService`, the other provides a default one?Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/onionwrapper/-/issues/1`android` isn't pulling in `core` as transitive dependency2023-05-10T17:25:53ZTorsten Grote`android` isn't pulling in `core` as transitive dependencylooks like org.briarproject:onionwrapper-android is not pulling in core as a transitive dependency.
without core:
```
error: InjectProcessingStep was unable to process 'org.briarproject.onionwrapper.TorWrapper' because 'org.briarproject...looks like org.briarproject:onionwrapper-android is not pulling in core as a transitive dependency.
without core:
```
error: InjectProcessingStep was unable to process 'org.briarproject.onionwrapper.TorWrapper' because 'org.briarproject.onionwrapper.TorWrapper' could not be resolved.
```
Maybe this is `api` vs. `implementation` in gradle dependency terms?Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/2430Icons are missing from our F-Droid repo2023-04-28T17:31:20ZakwizgranIcons are missing from our F-Droid repoOur F-Droid repo doesn't appear to have up-to-date icons for Briar or Mailbox. The newest icons for Briar are for the long-obsolete 1.1.6 release.Our F-Droid repo doesn't appear to have up-to-date icons for Briar or Mailbox. The newest icons for Briar are for the long-obsolete 1.1.6 release.https://code.briarproject.org/briar/briar-desktop/-/issues/517Cannot write to /dev/urandom on macOS2023-04-19T14:32:15ZSebastianCannot write to /dev/urandom on macOSGetting this stacktrace on the log:
```
16:25:45.465 [main] INFO o.b.b.crypto.CryptoComponentImpl - Default SecureRandom: SUN NativePRNG
16:25:45.467 [main] WARN o.b.b.s.UnixSecureRandomProvider - java.io.IOException: Operation not pe...Getting this stacktrace on the log:
```
16:25:45.465 [main] INFO o.b.b.crypto.CryptoComponentImpl - Default SecureRandom: SUN NativePRNG
16:25:45.467 [main] WARN o.b.b.s.UnixSecureRandomProvider - java.io.IOException: Operation not permitted
java.io.IOException: Operation not permitted
at java.base/java.io.FileOutputStream.writeBytes(Native Method)
at java.base/java.io.FileOutputStream.write(FileOutputStream.java:349)
at java.base/java.io.DataOutputStream.writeLong(DataOutputStream.java:230)
at org.briarproject.bramble.system.AbstractSecureRandomProvider.writeToEntropyPool(AbstractSecureRandomProvider.java:24)
at org.briarproject.bramble.system.UnixSecureRandomProvider.writeSeed(UnixSecureRandomProvider.java:49)
at org.briarproject.bramble.system.UnixSecureRandomProvider.getProvider(UnixSecureRandomProvider.java:41)
at org.briarproject.bramble.crypto.CryptoComponentImpl.<init>(CryptoComponentImpl.java:85)
at org.briarproject.bramble.crypto.CryptoModule.provideCryptoComponent(CryptoModule.java:32)
at org.briarproject.bramble.crypto.CryptoModule_ProvideCryptoComponentFactory.provideCryptoComponent(CryptoModule_ProvideCryptoComponentFactory.java:48)
at org.briarproject.bramble.crypto.CryptoModule_ProvideCryptoComponentFactory.get(CryptoModule_ProvideCryptoComponentFactory.java:37)
at org.briarproject.bramble.crypto.CryptoModule_ProvideCryptoComponentFactory.get(CryptoModule_ProvideCryptoComponentFactory.java:13)
at dagger.internal.DoubleCheck.get(DoubleCheck.java:47)
at org.briarproject.bramble.sync.MessageFactoryImpl_Factory.get(MessageFactoryImpl_Factory.java:27)
at org.briarproject.bramble.sync.MessageFactoryImpl_Factory.get(MessageFactoryImpl_Factory.java:11)
at org.briarproject.bramble.sync.SyncModule_ProvideMessageFactoryFactory.get(SyncModule_ProvideMessageFactoryFactory.java:32)
at org.briarproject.bramble.sync.SyncModule_ProvideMessageFactoryFactory.get(SyncModule_ProvideMessageFactoryFactory.java:12)
at org.briarproject.bramble.db.DatabaseModule_ProvideDatabaseFactory.get(DatabaseModule_ProvideDatabaseFactory.java:42)
at org.briarproject.bramble.db.DatabaseModule_ProvideDatabaseFactory.get(DatabaseModule_ProvideDatabaseFactory.java:15)
at dagger.internal.DoubleCheck.get(DoubleCheck.java:47)
at org.briarproject.bramble.db.DatabaseModule_ProvideDatabaseComponentFactory.get(DatabaseModule_ProvideDatabaseComponentFactory.java:46)
at org.briarproject.bramble.db.DatabaseModule_ProvideDatabaseComponentFactory.get(DatabaseModule_ProvideDatabaseComponentFactory.java:16)
at dagger.internal.DoubleCheck.get(DoubleCheck.java:47)
at org.briarproject.bramble.lifecycle.LifecycleManagerImpl_Factory.get(LifecycleManagerImpl_Factory.java:36)
at org.briarproject.bramble.lifecycle.LifecycleManagerImpl_Factory.get(LifecycleManagerImpl_Factory.java:13)
at org.briarproject.bramble.lifecycle.LifecycleModule_ProvideLifecycleManagerFactory.get(LifecycleModule_ProvideLifecycleManagerFactory.java:32)
at org.briarproject.bramble.lifecycle.LifecycleModule_ProvideLifecycleManagerFactory.get(LifecycleModule_ProvideLifecycleManagerFactory.java:12)
at dagger.internal.DoubleCheck.get(DoubleCheck.java:47)
at org.briarproject.bramble.cleanup.CleanupModule_ProvideCleanupManagerFactory.get(CleanupModule_ProvideCleanupManagerFactory.java:41)
at org.briarproject.bramble.cleanup.CleanupModule_ProvideCleanupManagerFactory.get(CleanupModule_ProvideCleanupManagerFactory.java:14)
at dagger.internal.DoubleCheck.get(DoubleCheck.java:47)
at org.briarproject.briar.desktop.DaggerBriarDesktopTestApp.injectEagerSingletons(DaggerBriarDesktopTestApp.java:1943)
at org.briarproject.briar.desktop.DaggerBriarDesktopTestApp.inject(DaggerBriarDesktopTestApp.java:1751)
at org.briarproject.bramble.BrambleCoreEagerSingletons$Helper.injectEagerSingletons(BrambleCoreEagerSingletons.java:51)
at org.briarproject.briar.desktop.RunWithTemporaryAccount.run(RunWithTemporaryAccount.kt:77)
at org.briarproject.briar.desktop.TestDeterministicConversationsKt.main(TestDeterministicConversations.kt:25)
at org.briarproject.briar.desktop.TestDeterministicConversationsKt.main(TestDeterministicConversations.kt)
16:25:45.519 [main] INFO o.b.b.crypto.CryptoComponentImpl - Installed SecureRandom: UnixPRNG SHA1PRNG
```https://code.briarproject.org/briar/briar/-/issues/2429SecurityException: Permission Denial for CLOSE_SYSTEM_DIALOGS2023-04-18T15:39:33ZakwizgranSecurityException: Permission Denial for CLOSE_SYSTEM_DIALOGS* Android version: 12
* Phone model: Google Pixel 3 XL (crosshatch)
* Briar version: 1.4.23 (070165f)
* User feedback: "I wrote a message, then Briar shut down. This also happens frequently to other apps."
Stacktrace:
```
java.lang.Secu...* Android version: 12
* Phone model: Google Pixel 3 XL (crosshatch)
* Briar version: 1.4.23 (070165f)
* User feedback: "I wrote a message, then Briar shut down. This also happens frequently to other apps."
Stacktrace:
```
java.lang.SecurityException: Permission Denial: android.intent.action.CLOSE_SYSTEM_DIALOGS broadcast from org.briarproject.briar.android (pid=24174, uid=10004) requires android.permission.BROADCAST_CLOSE_SYSTEM_DIALOGS.
at android.os.Parcel.createExceptionOrNull(Parcel.java:2425)
at android.os.Parcel.createException(Parcel.java:2409)
at android.os.Parcel.readException(Parcel.java:2392)
at android.os.Parcel.readException(Parcel.java:2334)
at android.app.IActivityManager$Stub$Proxy.closeSystemDialogs(IActivityManager.java:7614)
at com.android.internal.policy.PhoneWindow.sendCloseSystemWindows(PhoneWindow.java:3791)
at com.android.internal.policy.PhoneFallbackEventHandler.sendCloseSystemWindows(PhoneFallbackEventHandler.java:323)
at com.android.internal.policy.PhoneFallbackEventHandler.startCallActivity(PhoneFallbackEventHandler.java:275)
at com.android.internal.policy.PhoneFallbackEventHandler.onKeyUp(PhoneFallbackEventHandler.java:261)
at com.android.internal.policy.PhoneFallbackEventHandler.dispatchKeyEvent(PhoneFallbackEventHandler.java:76)
at android.view.ViewRootImpl$ViewPostImeInputStage.processKeyEvent(ViewRootImpl.java:6317)
at android.view.ViewRootImpl$ViewPostImeInputStage.onProcess(ViewRootImpl.java:6141)
at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:5623)
at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:5680)
at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:5646)
at android.view.ViewRootImpl$AsyncInputStage.forward(ViewRootImpl.java:5811)
at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:5654)
at android.view.ViewRootImpl$AsyncInputStage.apply(ViewRootImpl.java:5868)
at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:5627)
at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:5680)
at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:5646)
at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:5654)
at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:5627)
at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:5680)
at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:5646)
at android.view.ViewRootImpl$AsyncInputStage.forward(ViewRootImpl.java:5844)
at android.view.ViewRootImpl$ImeInputStage.onFinishedInputEvent(ViewRootImpl.java:6002)
at android.view.inputmethod.InputMethodManager$PendingEvent.run(InputMethodManager.java:3158)
at android.view.inputmethod.InputMethodManager.invokeFinishedInputEventCallback(InputMethodManager.java:2722)
at android.view.inputmethod.InputMethodManager.finishedInputEvent(InputMethodManager.java:2713)
at android.view.inputmethod.InputMethodManager$ImeInputEventSender.onInputEventFinished(InputMethodManager.java:3135)
at android.view.InputEventSender.dispatchInputEventFinished(InputEventSender.java:154)
at android.os.MessageQueue.nativePollOnce(Native Method)
at android.os.MessageQueue.next(MessageQueue.java:335)
at android.os.Looper.loopOnce(Looper.java:161)
at android.os.Looper.loop(Looper.java:288)
at android.app.ActivityThread.main(ActivityThread.java:7842)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003)
Caused by: android.os.RemoteException: Remote stack trace:
at com.android.server.wm.ActivityTaskManagerService.checkCanCloseSystemDialogs(ActivityTaskManagerService.java:2955)
at com.android.server.wm.ActivityTaskManagerService.access$900(ActivityTaskManagerService.java:294)
at com.android.server.wm.ActivityTaskManagerService$LocalService.checkCanCloseSystemDialogs(ActivityTaskManagerService.java:5309)
at com.android.server.wm.ActivityTaskManagerService$LocalService.closeSystemDialogs(ActivityTaskManagerService.java:5783)
at com.android.server.am.ActivityManagerService.closeSystemDialogs(ActivityManagerService.java:3800)
```
Edited log:
```
04-02 10:16:30.039 I/BaseActivity: Starting ConversationActivity
04-02 10:16:30.041 I/BaseActivity: Resuming ConversationActivity
04-02 10:16:32.999 I/AutoDeleteManagerImpl: Sending message with auto-delete timer 604800000
04-02 10:16:33.045 I/DuplexOutgoingSession: Next send time decreased
04-02 10:16:33.052 I/DuplexOutgoingSession: Generated offer: true
04-02 10:16:33.052 I/DuplexOutgoingSession: Sent offer
04-02 10:16:33.061 I/DuplexOutgoingSession: Generated offer: false
04-02 10:16:33.495 I/DuplexOutgoingSession: Generated batch: true
04-02 10:16:33.495 I/ConversationActivity: Messages sent
04-02 10:16:33.495 I/DuplexOutgoingSession: Sent batch
04-02 10:16:33.504 I/DuplexOutgoingSession: Generated batch: false
04-02 10:16:34.069 I/ConversationActivity: Messages acked
04-02 10:16:42.127 I/DuplexOutgoingSession: Generated request: true
04-02 10:16:42.127 I/DuplexOutgoingSession: Sent request
04-02 10:16:42.128 I/DuplexOutgoingSession: Generated request: false
04-02 10:16:42.743 I/ValidationManagerImpl: Validating message for org.briarproject.briar.messaging
04-02 10:16:42.761 I/DuplexOutgoingSession: Generated ack: true
04-02 10:16:42.762 I/DuplexOutgoingSession: Sent ack
04-02 10:16:42.768 I/ValidationManagerImpl: Delivering message for org.briarproject.briar.messaging
04-02 10:16:42.770 I/AutoDeleteManagerImpl: Mirroring auto-delete timer 604800000
04-02 10:16:42.786 I/ConversationActivity: Message received, adding
04-02 10:16:42.791 I/DuplexOutgoingSession: Generated ack: false
04-02 10:17:12.763 I/DuplexOutgoingSession: Sending keepalive
04-02 10:17:33.484 I/DuplexOutgoingSession: Checking for retransmittable messages
04-02 10:17:33.514 I/DuplexOutgoingSession: Generated batch: false
04-02 10:17:33.520 I/DuplexOutgoingSession: Generated offer: false
```
As far as I can tell, the crash happens because `PhoneFallbackEventHandler` is being called to [handle a key event](https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/java/com/android/internal/policy/PhoneFallbackEventHandler.java;drc=95c1165bb895dd844e1793460710f7163dd330a3;l=250) for `KEYCODE_CALL`. The handler tries to start a call activity for the current app, which fails because Briar doesn't have permission to close system dialogs (which I guess is part of the process of launching the call activity).
So perhaps this is happening just because the user hits the call button on their device/keyboard, or perhaps it also requires some other circumstances, like an unusual device/keyboard config. Either way, it looks like a problem that's specific to this user and (based on their comment) not specific to Briar.https://code.briarproject.org/briar/briar-mailbox/-/issues/192Set up fastlane for app store metadata2023-08-28T16:00:10ZTorsten GroteSet up fastlane for app store metadatahttps://code.briarproject.org/briar/public-mesh-testbed/-/issues/2Add uncaught exception handler, ensure that crashes get logged2023-04-17T14:11:48ZakwizgranAdd uncaught exception handler, ensure that crashes get loggedhttps://code.briarproject.org/briar/briar-desktop/-/issues/516Notifications are not detected to be not working on Raspbian2023-04-15T18:53:01ZMikolai GütschowNotifications are not detected to be not working on RaspbianQuoting @sebkur from https://code.briarproject.org/briar/briar-desktop/-/issues/327#note_74864:
> Notifications do not work and are not detected to be not working (which might be the thing that we could ideally detect). I think it's not...Quoting @sebkur from https://code.briarproject.org/briar/briar-desktop/-/issues/327#note_74864:
> Notifications do not work and are not detected to be not working (which might be the thing that we could ideally detect). I think it's not much our fault though. After installing `x11-utils`, I have `notify-send` which also doesn't work. It fails silently, much like our app. I think there's just nothing installed on that system that shows the notifications that are being sent to libnotify.
> The message is
>
> ```
> libnotify-WARNING: Failed to connect to proxy
> ```
> `ldd --version` shows:
>
> ```
> Debian GLIBC 2.31-13...
> ```https://code.briarproject.org/briar/briar-desktop/-/issues/515Mailbox Error Dialog: when unpairing is successful, don't show "error" as title2023-04-26T08:00:43ZSebastianMailbox Error Dialog: when unpairing is successful, don't show "error" as titleI think it is rather confusing when this says "error" in this case. It's actually rather a success dialog.I think it is rather confusing when this says "error" in this case. It's actually rather a success dialog.Torsten GroteTorsten Grote