briar issueshttps://code.briarproject.org/groups/briar/-/issues2023-08-28T16:04:18Zhttps://code.briarproject.org/briar/social-mesh-research/-/issues/3Decide and document evaluation criteria for design candidates2023-08-28T16:04:18ZakwizgranDecide and document evaluation criteria for design candidateshttps://code.briarproject.org/briar/social-mesh-research/-/issues/2Find and document relevant research and practical work2023-08-28T16:04:18ZakwizgranFind and document relevant research and practical workDepends on #1, #6.Depends on #1, #6.https://code.briarproject.org/briar/social-mesh-research/-/issues/1Decide and document the scope of the research2023-08-28T16:04:18ZakwizgranDecide and document the scope of the researchhttps://code.briarproject.org/briar/briar/-/issues/2249Briar sends profile picture updates to clients that have the image attachment...2022-01-07T19:24:51ZSebastianBriar sends profile picture updates to clients that have the image attachments feature flag disabledThe desktop project has image attachments and profile pictures disabled
```
override fun shouldEnableImageAttachments() = false
override fun shouldEnableProfilePictures() = false
```
still briar 1.4.3 is sending avatar updates to it, I b...The desktop project has image attachments and profile pictures disabled
```
override fun shouldEnableImageAttachments() = false
override fun shouldEnableProfilePictures() = false
```
still briar 1.4.3 is sending avatar updates to it, I believe this is a bughttps://code.briarproject.org/briar/briar-desktop/-/issues/184Create debug/release build modes and tasks using Gradle2022-01-07T13:55:58ZSebastianCreate debug/release build modes and tasks using GradleImportant so that we can create builds without expiry warning (see #183)Important so that we can create builds without expiry warning (see #183)https://code.briarproject.org/briar/briar-desktop/-/issues/181own link not visable in "add contact" menu2022-01-06T22:03:11Zbodemsown link not visable in "add contact" menuWhen I open the "Add Contact at a Distance" menu, my own briar link is not visable. Nevertheless I can copy it and so I don't have any problems with adding a contact. I am using the latest briar-desktop.jar on Ubuntu 21.10.
![briar-desk...When I open the "Add Contact at a Distance" menu, my own briar link is not visable. Nevertheless I can copy it and so I don't have any problems with adding a contact. I am using the latest briar-desktop.jar on Ubuntu 21.10.
![briar-desktop-link](/uploads/dd014c8d6e156ff1543e2947f3ce0745/briar-desktop-link.png)https://code.briarproject.org/briar/briar/-/issues/2248Add feature flag for disabling introduction client in core2022-01-06T14:46:18ZSebastianAdd feature flag for disabling introduction client in coreRelated to !1572, requires #1214 to be implemented in concertRelated to !1572, requires #1214 to be implemented in concerthttps://code.briarproject.org/briar/briar-mailbox/-/issues/84Exception logging broken2022-02-25T14:53:58ZSebastianException logging brokenWhen I call this to force a logged exception `logException(LOG, IOException("foo"))`, I get this output on the CLI:
```
20:59:29.737 [main] WARN o.b.m.c.l.LifecycleManagerImpl - java.io.IOException: foo
java.io.IOException: foo
at org...When I call this to force a logged exception `logException(LOG, IOException("foo"))`, I get this output on the CLI:
```
20:59:29.737 [main] WARN o.b.m.c.l.LifecycleManagerImpl - java.io.IOException: foo
java.io.IOException: foo
at org.briarproject.mailbox.core.lifecycle.LifecycleManagerImpl.startServices(LifecycleManagerImpl.kt:130)
at org.briarproject.mailbox.cli.Main.run(Main.kt:100)
…
```
which is OK, but not optimal, as the exception class and message is duplicated.
See [the SLF4J FAQs on "Can I log an exception without an accompanying message?"](https://www.slf4j.org/faq.html#exception_message)
> In short, no.
So bottom line, we should always add a message, I think that's totally OK and reasons why that's a good idea anyway are in that FAQ.
On Android and Logcat however, things look like this:
```
2022-01-05 20:44:33.162 4318-4433/org.briarproject.mailbox W/o.b.m.c.l.LifecycleManagerImpl: java.io.IOException: foojava.io.IOException: foo
at org.briarproject.mailbox.core.lifecycle.LifecycleManagerImpl.startServices(LifecycleManagerImpl.kt:130)
…
```
which is ugly. For some reason the exception does not get printed on the next line after the message; it is just appended instead.
Looks like we're using logback-android as the backend on Android and logback-classic as the backend on the CLI and they have different configuration syntax and options.
We should find a configuration that works on both and produces comparable results.SebastianSebastianhttps://code.briarproject.org/briar/briar-mailbox/-/issues/83Add setting for opting in or out of Tor bridges2023-05-10T17:01:13ZSebastianAdd setting for opting in or out of Tor bridgesIt would make sense to have a way of configuring whether tor use bridges (and all the machinery that goes into deciding the default setting for a given country)It would make sense to have a way of configuring whether tor use bridges (and all the machinery that goes into deciding the default setting for a given country)Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar-mailbox/-/issues/82User feedback / bug / crash-log reporting mechanism2023-08-28T16:00:12ZSebastianUser feedback / bug / crash-log reporting mechanismIn briar, users can report general feedback and get promted to do so if the app crashes. That's very useful for us as developers, so it would make a lot of sense to have something like this in the mailbox app as well.In briar, users can report general feedback and get promted to do so if the app crashes. That's very useful for us as developers, so it would make a lot of sense to have something like this in the mailbox app as well.https://code.briarproject.org/briar/briar/-/issues/2247Always connect to the Internet while Briar is put to foreground2022-11-02T18:30:20ZNorbert 80Always connect to the Internet while Briar is put to foregroundHello all,
Users who use the setting "Connect to the Internet only when charging" have to change this setting every time they want to bring Briar online in the meantime without the charger connected. This is very annoying and inconvenie...Hello all,
Users who use the setting "Connect to the Internet only when charging" have to change this setting every time they want to bring Briar online in the meantime without the charger connected. This is very annoying and inconvenient. In addition, it generally seems senseless to have the app in the foreground while it is offline.
For these reasons, I suggest the following behaviour of Briar while "Connect to the Internet only when charging" is activated:
1. When Briar is brought to the foreground, it should automatically switch to online.
2. When Briar is brought back to the background, it should maintain the internet connection for another 3 minutes. After the 3 minutes, Briar will automatically go offline. This 3 minute delay is to avoid excessive online/offline intervals.
(This is needed for example when the user wants to share texts from another app).https://code.briarproject.org/briar/briar-desktop/-/issues/179Display error messages to user in UI2023-03-21T21:45:34ZSebastianDisplay error messages to user in UISee !80 but there are probably more locations where errors should be shown in the UI instead of only logged.See !80 but there are probably more locations where errors should be shown in the UI instead of only logged.https://code.briarproject.org/briar/tor-reproducer/-/issues/6Define requirements for revised tor-reproducer2023-07-13T11:00:15ZNicoDefine requirements for revised tor-reproducerInstead of trying to build all Tor related dependencies ourselves ([tor-reproducer](https://code.briarproject.org/briar/tor-reproducer), [go-reproducer](https://code.briarproject.org/briar/go-reproducer/)), there is the idea of using off...Instead of trying to build all Tor related dependencies ourselves ([tor-reproducer](https://code.briarproject.org/briar/tor-reproducer), [go-reproducer](https://code.briarproject.org/briar/go-reproducer/)), there is the idea of using official Tor tools to build (and reproduce) binaries. There are various motivations for this and also various possible solutions, so with this issue I want clear up the whole picture a little bit.
_(Terminology: Following Tor Project's [glossary](https://support.torproject.org/glossary/), when I write "Tor" I mean the whole ecosystem, including "little-t-tor", pluggable transports like obfs4 and snowflake and other stuff. little-t-tor is the `tor` binary Briar uses to make use of Tor's features.)_
### Motivations
* building Tor is hard, as underlying toolchains evolve and especially when trying to cross-compile for new architectures
* Additionally to _obfs4_ Briar might want to make use of [_snowflake_](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake), another [pluggable transport](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports) that uses WebRTC technology (the one for video calls in browsers) for bridging. Like _obfs4_ it's written in Go, so it would be reproduced in _go-reproducer_ with our current toolchain.
* _tor-reproducer_ here at Briar was never designed to build for that many different OS/arch combinations, slowing down the whole process a lot
### Possible solutions
Instead of figuring out build and compiler commandos and flags ourselves, we can make use of [the tor-browser-build](https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/blob/master/README) infrastructure. This was first recommended [in this forum post](https://forum.torproject.net/t/are-there-any-official-reproducible-tor-obfs4proxy-binaries/831/3) and, e.g., compiling _tor_ for macOS (x86) is as easy as this:
```bash
./rbm/rbm build tor --target release --target torbrowser-osx-x86_64
```
For more information, see [this wiki page](https://code.briarproject.org/briar/briar-desktop-servers/-/wikis/Tor-builds).
Some comments about this:
* adding new OS/architecture combos becomes _super easy_, as long as we [use one of the officially supported combos](https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/blob/master/doc/HACKING.txt#L46)
* really cool about this is that _rbm_ also compiles a lot of the underlying toolchain like, e.g., the cross-compilers and related stuff
* however, this also seems to result in much longer build times. It took 2 hours on a 4 core vps until it started to compile the actual tor dependencies. Before that, it built all the compiler dependencies like ninja and the cross-compiler. Afterwards, it was quick though, building all tor only took 10 to 20 minutes, if I see it correctly.
### Requirements
If we decide to switch to _rbm_ for building all Tor dependencies, we should make clear what we need now, what we might need in the future (so we don't slow down as much as we do currently with _tor-reproducer_) and how a revised [_all-tor-reproducer_](https://code.briarproject.org/briar-staging/all-tor-reproducer) (?) might differ from the current _tor-reproducer_.
The first difference is that rbm makes use of Docker containers itself to provide reproducibility. I imagine this means that we can't/don't want to use Docker ourselves in _all-tor-reproducer_, although this would mean that we need to [install the build dependencies](https://code.briarproject.org/briar/briar-desktop-servers/-/wikis/Tor-builds?version_id=4e9f5c731dde7a52ebee6f7743f1e79cf9c7b272) on the host machine. Does this break reproducibility? Does Docker inside Docker work?
Another point is versioning. With the current version of _all-tor-reproducer_ do we want to reproduce all current and previous versions of Tor stuff, or say that you need the right version of _all-tor-reproducer_ to reproduce older versions of Tor stuff? This is a point already unclear with _tor-reproducer_ that should definitively get cleared for _all-tor-reproducer_.
Related to that, we might want to build different versions than those listed in _tor-browser-build_. For example, with the current configuration tor version `0.4.7.2-alpha` would be built [according to this line](https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/blob/6aaf06936e472c044c99d204244ef925827f8c15/projects/tor/config#L3), if I understood it correctly. We might be able to build other versions using a flag
```bash
./rbm/rbm build tor --target release --target torbrowser-linux-x86_64 --version 0.5.0
```
but we might want to make more/other changes to the build configurations. Do we want to for _tor-browser-build_ then?
### Additional homework
* [ ] actually try out binaries produced by _rbm_ on different platforms (https://code.briarproject.org/briar-staging/all-tor-reproducer/-/issues/1)
* [ ] link to this issue from the [Create a new build target to package tor daemon, pluggable transports and dependencies](https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40397) issue
Pinging @akwizgran @grote @sebkur @ialokimhttps://code.briarproject.org/briar/briar/-/issues/2246Suggestion to solve battery drain issue2022-02-25T15:00:03ZNorbert 80Suggestion to solve battery drain issueHi there!
After a practical trial of Briar, I would like to make what I think is an important suggestion for improvement.
**First of all, the experience:**
We tested Briar in a group of 8 people. The users were initially very attract...Hi there!
After a practical trial of Briar, I would like to make what I think is an important suggestion for improvement.
**First of all, the experience:**
We tested Briar in a group of 8 people. The users were initially very attracted to Briar. Besides the actual concept, they also liked the clean, functional and yet appealing interface. People enjoyed using the app at first. And that brings us to the problem.
Members have gradually realised that the battery consumption through Briar is high. This has led to some going online sporadically over a few days, others activating the setting to limit online time to connecting to the charger.
The end result is that now none of my contacts go online with Briar. Tel.gram seems more pragmatic to them after all.
**I would like to propose the following solution to this battery problem for discussion:**
- There are three operating modes for the Internet/Tor channel
- Mode 1: Always online (current default)
- Mode 2: The app is offline in the background and automatically goes online for 3 minutes (tbd) every hour (tbd). This setting becomes the new default. For active transmissions, the background online time is extended accordingly. The app is always online in the foreground.
- Mode 3: The app is only online in the background while the charger is plugged in. In contrast to the current battery saving mode, Briar also goes online in this mode when it is in the foreground.
The idea with mode 2 is based on the fact that most phones use precise, network-synchronised clocks. During this time, data exchange takes place in the background between users without user interaction. In the foreground, the app should always be online. It makes little sense to show the user an offline app in the foreground.
After my experience now, regarding the usage behaviour of others, I am absolutely convinced that the above concept would overcome a big hurdle to the further spread/acceptance of Briar.https://code.briarproject.org/briar/briar-desktop/-/issues/177Event-driven loading of single (new) messages instead of reloading all of them2023-03-13T22:19:01ZMikolai GütschowEvent-driven loading of single (new) messages instead of reloading all of themCurrently, when an introduction is initiated, all messages in the current private chat are reloaded. It would be better to switch to an event-based loading of the single newly added message. `ConversationMessageTrackedEvent` which was ad...Currently, when an introduction is initiated, all messages in the current private chat are reloaded. It would be better to switch to an event-based loading of the single newly added message. `ConversationMessageTrackedEvent` which was added for updating group counts currently does not include message IDs, but this could be easily changed. However, Briar core currently does not support loading single messages by message ID.
Another approach would be to emit ConversationMessageSentEvents similar to the ConversationMessageReceivedEvent.
See https://code.briarproject.org/briar/briar-desktop/-/merge_requests/69#note_58749.https://code.briarproject.org/briar/briar-desktop/-/issues/176Enable certain features only if contact supports it2022-04-03T10:36:34ZSebastianEnable certain features only if contact supports itLike briar-desktop not supporting blogs, forums etc, there can be other clients (like old versions of briar) which don't support other features such as images or disappearing messages. We need to make sure that we enable such features on...Like briar-desktop not supporting blogs, forums etc, there can be other clients (like old versions of briar) which don't support other features such as images or disappearing messages. We need to make sure that we enable such features only for contacts that understand the features.https://code.briarproject.org/briar/website/-/issues/34Hidden Service and/or Eepsite Mirror2021-12-23T22:16:49ZpaulHidden Service and/or Eepsite Mirrorrelated to briar-desktop#174
Provide a mirror to briarproject.org so users running tor or an i2p router can access the site over these networks without exiting to the clearnet.related to briar-desktop#174
Provide a mirror to briarproject.org so users running tor or an i2p router can access the site over these networks without exiting to the clearnet.https://code.briarproject.org/briar/briar-desktop/-/issues/174Alternative Distribution Channels2021-12-23T22:16:50ZpaulAlternative Distribution ChannelsIt's great to see the work that is being put in to allow for Briar Desktop to be packaged as .jar, .deb, macOS and windows installers etc. Users might find it useful to offer more privacy-preserving ways to download these files, than jus...It's great to see the work that is being put in to allow for Briar Desktop to be packaged as .jar, .deb, macOS and windows installers etc. Users might find it useful to offer more privacy-preserving ways to download these files, than just through the clearnet.
Two relatively easy methods are to offer `.onion` and/or `.i2p` mirrors of the download page, but it might be worth it to consider p2p distribution methods down the road. One p2p strategy could be through removeable drives and/or hotspots, like Briar android. Another method is i2p's strategy of update-able torrents using i2p's network. Here's a brief description of this strategy, from i2p dev "idk":
> Developer/Maintainer builds update and signs it to create an su3 file. The developer uploads(The whole su3) it somewhere and passes it to a News Server Operator. Either the Developer or the News Server Operator generates a magnet link corresponding to the su3 file. The Developer and the News Operator seed the torrent.
>
> The News Operator then generates a signed feed, which is also an su3 file. Note that the signer of the software is different from the signer of the newsfeed. Both of the pieces of download information are added to a file called releases.json which is combined with a recently updated blocklist of known bad nodes and a series of release notes to create an RSS feed, which is downloaded by the I2P client.
>
> The client then adds the torrent to the build-in I2P torrent client I2PSnark. Over the next 36 hours, every Java I2P user will participate in this torrent, ensuring that there are plentiful sources for the peer-to-peer download. What happens next depends on which UpdatePostProcessor is in use, this is somewhat (I2P)distribution-specific. DMG and NSIS packages use a different UPP than the mainline distro, for instance.
Documentation for this method can be found here: https://geti2p.net/spec/updateshttps://code.briarproject.org/briar/briar-desktop/-/issues/171Document possible log level declarations in logback.xml2022-07-13T11:16:14ZSebastianDocument possible log level declarations in logback.xmlI was confused when trying to set different log levels in our `logback.xml` and even thought it didn't work properly. But it turned out that I just tried to configure an invalid log level. I tried setting WARNING on some classes and pack...I was confused when trying to set different log levels in our `logback.xml` and even thought it didn't work properly. But it turned out that I just tried to configure an invalid log level. I tried setting WARNING on some classes and packages while one needs to use WARN. This seems like a trap others could run into as well, so I though it might be good to add a comment in the file stating which levels are available.SebastianSebastianhttps://code.briarproject.org/briar/briar-desktop/-/issues/169Lock app2022-04-03T10:36:35ZSebastianLock appIt would be a nice feature to be able to lock the app without logging out. As we can only deliver and receive messages while the app is running, one might be tempted to leave it running while leaving the desk. Of course, one should use t...It would be a nice feature to be able to lock the app without logging out. As we can only deliver and receive messages while the app is running, one might be tempted to leave it running while leaving the desk. Of course, one should use the screensaver lock or whatever mechanism to protect others from using anything on one's machine at all (remember, don't leave any root shells open ;)), as briar is an app that most likely contains sensitive information, it would be nice to have a lock feature of its own.