briar issueshttps://code.briarproject.org/groups/briar/-/issues2020-11-15T18:54:25Zhttps://code.briarproject.org/briar/briar/-/issues/1539Retrieving the onion address of a specific contact2020-11-15T18:54:25ZalexRetrieving the onion address of a specific contactHello;
This is more a question than an issue, and it will help many others develop this app.
I was looking for very long hours, for the onion address of the target contact when sending a message.
I followed the 'createMessage()' method ...Hello;
This is more a question than an issue, and it will help many others develop this app.
I was looking for very long hours, for the onion address of the target contact when sending a message.
I followed the 'createMessage()' method and it's usage/declaration but found no clue .
I/WE will be very grateful if you show us the location of these onion addresses to where the packets are sent to;
and how to retrieve them.
Thank you for your time , and again, this is gonna help us develop new features and finally commit them.https://code.briarproject.org/briar/briar/-/issues/1540Make it easier to find the changelog2020-05-09T15:15:42ZakwizgranMake it easier to find the changelogUser feedback: "Please provide change logs that are easily accessible."
Perhaps we should link to the changelog from the website and/or include it in the app.
Related to #1312.User feedback: "Please provide change logs that are easily accessible."
Perhaps we should link to the changelog from the website and/or include it in the app.
Related to #1312.https://code.briarproject.org/briar/briar/-/issues/1541Allow users to create polls2020-11-15T18:52:19ZakwizgranAllow users to create pollsA user asked for the ability to create polls in groups, blogs and forums.
This would be pretty easy to implement at the client layer, by adding "poll" and "vote" message types, where a vote message depends on a poll message, indicates o...A user asked for the ability to create polls in groups, blogs and forums.
This would be pretty easy to implement at the client layer, by adding "poll" and "vote" message types, where a vote message depends on a poll message, indicates one of the options in the poll message, and is signed by the voter. The client would use metadata attached to the poll message to count votes and apply rules for situations like an identity voting for multiple options (whether this is valid [depends on the voting system!](https://en.wikipedia.org/wiki/Approval_voting)).
I think this feature would make the most sense for private groups. Forums don't have any limit on which identities can take part, so vote stuffing would be easy. Blogs have the same issue, and allowing subscribers to send vote messages would remove one of the nice security properties of blogs, which is that subscribers have no way to DoS a blog because only the owner can post messages.https://code.briarproject.org/briar/briar/-/issues/1542Pinned posts2020-11-15T18:51:08ZakwizgranPinned postsA user asked for the ability to pin posts in private groups and forums.
Related to #880.A user asked for the ability to pin posts in private groups and forums.
Related to #880.https://code.briarproject.org/briar/briar/-/issues/1543Make sign-in reminder more prominent2020-11-15T18:50:15ZakwizgranMake sign-in reminder more prominentUser feedback: "Please consider making the sign-in notification more prominent after restart. Sometimes I forget I'm not signed in for hours or even days, a more visible reminder would really help. Splash page after restart maybe?"
Poss...User feedback: "Please consider making the sign-in notification more prominent after restart. Sometimes I forget I'm not signed in for hours or even days, a more visible reminder would really help. Splash page after restart maybe?"
Possibly related to #1458.https://code.briarproject.org/briar/briar/-/issues/1544AMOLED dark theme2021-09-23T12:30:59ZakwizgranAMOLED dark themeA user asked for an AMOLED dark theme (i.e. based on pure black).
Related to #976.A user asked for an AMOLED dark theme (i.e. based on pure black).
Related to #976.https://code.briarproject.org/briar/website/-/issues/32Public roadmap2021-02-17T01:04:47ZakwizgranPublic roadmapUser feedback: "It would be nice if your web site listed planned versions and added features so users could know what capabilities are in the pipeline."
The closest we currently have is this:
https://code.briarproject.org/briar/briar/w...User feedback: "It would be nice if your web site listed planned versions and added features so users could know what capabilities are in the pipeline."
The closest we currently have is this:
https://code.briarproject.org/briar/briar/wikis/product-backlogCleopatraCleopatrahttps://code.briarproject.org/briar/briar/-/issues/1548Chat with Tor Browser users via hidden service2020-11-15T18:45:55ZakwizgranChat with Tor Browser users via hidden serviceUser feedback: "It would be a realy cool feature for Briar if one could generate a .onion link that one can share over another channel (basically like OnionShare), that would then open a text chat in the Tor Browser to allow communicatio...User feedback: "It would be a realy cool feature for Briar if one could generate a .onion link that one can share over another channel (basically like OnionShare), that would then open a text chat in the Tor Browser to allow communication with other platforms than Android."https://code.briarproject.org/briar/briar/-/issues/1549Release beta versions via F-Droid2020-11-15T18:45:20ZakwizgranRelease beta versions via F-DroidA user asked for beta versions to be released via F-Droid.
Currently we make releases in two stages. In the first stage (beta tag) the release is made available for direct download, via our F-Droid repo, and to Google Play beta testers....A user asked for beta versions to be released via F-Droid.
Currently we make releases in two stages. In the first stage (beta tag) the release is made available for direct download, via our F-Droid repo, and to Google Play beta testers. In the second stage (release tag) it's made available via the main F-Droid repo and to all Google Play users.
It would be nice if (a) beta releases weren't marked as recommended in our F-Droid repo, and (b) beta releases were made available, but not marked as recommended, in the main F-Droid repo.https://code.briarproject.org/briar/briar/-/issues/1550Relay encrypted messages between contacts2020-11-15T18:44:35ZakwizgranRelay encrypted messages between contactsSeveral users have suggested that Briar should relay encrypted messages between contacts, so that users who can't communicate directly can pass messages through mutual contacts.
This would have implications for battery and bandwidth con...Several users have suggested that Briar should relay encrypted messages between contacts, so that users who can't communicate directly can pass messages through mutual contacts.
This would have implications for battery and bandwidth consumption. If message propagation was restricted then it would also have privacy implications (Alice could see that Bob and Carol were both sending messages at 3am, when nobody else was sending anything). If message propagation was unrestricted then the battery and bandwidth impact would be hard to control - this would affect scalability and enable flooding attacks. Fair queueing might help to mitigate flooding attacks (#511).
One user suggested that the privacy impact could be mitigated through fine-grained controls (e.g. Bob and Carol would only choose Alice to relay their messages if they didn't mind her knowing when they were communicating). I'm skeptical about whether most people can predict and manage their privacy needs at that granularity in advance, but I could be wrong.https://code.briarproject.org/briar/briar/-/issues/1553Option to revert screen filter setting2020-11-15T18:32:09ZakwizgranOption to revert screen filter settingA user asked for the ability to revert the decision to allow certain apps to draw on top of Briar.A user asked for the ability to revert the decision to allow certain apps to draw on top of Briar.https://code.briarproject.org/briar/briar/-/issues/1555Factor out BriarActionBarActivity for ActionBar handling2020-11-15T18:31:40ZTorsten GroteFactor out BriarActionBarActivity for ActionBar handlingFrom https://code.briarproject.org/briar/briar/merge_requests/1035#note_36028
Push action bar handling code up into a BriarActionBarActivity and make current activities using it inherit it.
```java
ActionBar ab = getSupportActionBar();...From https://code.briarproject.org/briar/briar/merge_requests/1035#note_36028
Push action bar handling code up into a BriarActionBarActivity and make current activities using it inherit it.
```java
ActionBar ab = getSupportActionBar();
if (ab != null) {
ab.setDisplayHomeAsUpEnabled(true);
}
```
`onOptionsItemSelected()`https://code.briarproject.org/briar/briar/-/issues/1558ViewModelModule is breaking package encapsulation2021-04-30T13:38:33ZTorsten GroteViewModelModule is breaking package encapsulationThe ViewModelModule is breaking package encapsulation. Let's refactor the ViewModel bindings into the respective packages and cleaning them up.The ViewModelModule is breaking package encapsulation. Let's refactor the ViewModel bindings into the respective packages and cleaning them up.https://code.briarproject.org/briar/briar/-/issues/1559Avoid using third parties' resources for testing and maybe enable offline tes...2020-11-15T18:28:22ZiwakehAvoid using third parties' resources for testing and maybe enable offline testing```testFeedImportAndRemoval``` uses a third party blog feed for testing.
1) Maybe, rather use briar's own resources instead of Schneier's blog, e.g. simply supply a static test feed on briarproject's server or use https://code.briarproj...```testFeedImportAndRemoval``` uses a third party blog feed for testing.
1) Maybe, rather use briar's own resources instead of Schneier's blog, e.g. simply supply a static test feed on briarproject's server or use https://code.briarproject.org/briar/briar.atom.
2) This way of testing will fail when the testing machine is offline, which is not the aim of the test. So, avoiding internet access here might be a better solution and would also support to introduce test cases for feed content that could trip briar functionality.https://code.briarproject.org/briar/briar/-/issues/1563DozeView disappears when rotating screen after whitelisting Briar2020-11-15T18:27:59ZakwizgranDozeView disappears when rotating screen after whitelisting BriarSteps to reproduce:
* Use a device with Android 6+
* Ensure Briar isn't whitelisted for doze
* Create a new account
* In the power management setup screen, tap "Allow Connections" and accept the dialog
* Rotate the screen
* Expected: The...Steps to reproduce:
* Use a device with Android 6+
* Ensure Briar isn't whitelisted for doze
* Create a new account
* In the power management setup screen, tap "Allow Connections" and accept the dialog
* Rotate the screen
* Expected: The layout stays the same
* Actual: The "Allow Connections" button (with its check mark and help button) disappears
* Use the back button to return to the password setup screen
* Expected: The layout is the same as before
* Actual: The "Next" button changes to "Create Account"
The unexpected layout changes happen because we re-check whether we're whitelisted.
If the fragment instances are retained across rotations, perhaps the password and doze fragments could remember the whitelisting state when they were first created, and use that to control the text of the password fragment's "Next" / "Create Account" button and the visibilty of DozeView, so that they stay the same after we're whitelisted, while using the current whitelisting state to show/hide the "Allow Connections" button's check mark and enable/disable the power management fragment's "Create Account" button, which are the bits that are supposed to change when we're whitelisted.https://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.