briar issueshttps://code.briarproject.org/groups/briar/-/issues2018-06-12T11:32:32Zhttps://code.briarproject.org/briar/briar/-/issues/266Message queues2018-06-12T11:32:32ZakwizgranMessage queuesWrite a generic one-to-one message queue implementation that clients can use to exchange ordered messages with a contact.Write a generic one-to-one message queue implementation that clients can use to exchange ordered messages with a contact.Milestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/265Fuzzing tests for message validators2021-02-10T15:10:26ZakwizgranFuzzing tests for message validatorsUse fuzzing to ensure the message validators reject invalid messages without crashing. Record any messages that trigger crashes.
We can either look for a suitable fuzzing library or write our own fuzzer, starting from valid messages and...Use fuzzing to ensure the message validators reject invalid messages without crashing. Record any messages that trigger crashes.
We can either look for a suitable fuzzing library or write our own fuzzer, starting from valid messages and applying random mutations (delete/replace/repeat).https://code.briarproject.org/briar/briar/-/issues/256Verify and bind long-term public keys when adding contacts2018-06-12T11:32:32ZakwizgranVerify and bind long-term public keys when adding contactsDesign a protocol for verifying and binding long-term public keys when adding contacts directly or via introductions.
The current Bluetooth protocol does this by generating two nonces from the ephemeral shared secret - each party sign...Design a protocol for verifying and binding long-term public keys when adding contacts directly or via introductions.
The current Bluetooth protocol does this by generating two nonces from the ephemeral shared secret - each party signs one of the nonces. We could use a similar approach for the new protocols, or an approach based on triple Diffie-Hellman.
Identities already have long-term signature keys but they don't have long-term DH keys, so if we use 3DH we either need to be sure it's safe to reuse the signature keys as DH keys, or we need to extend the identity object with a long-term DH key, signed with the long-term signature key. This has the disadvantage of committing us to a DH primitive for the long term.
Using signatures would make the key exchange undeniable, but it's debatable whether that matters in practice.Milestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/255Client API improvements2018-06-12T11:32:32ZakwizgranClient API improvementsQuoting @grote:
> Last night I thought about the Client API as well and I tried to forget most of what I know about how things are implemented at the moment, so I can have a fresh view on how a developer writing a client without being f...Quoting @grote:
> Last night I thought about the Client API as well and I tried to forget most of what I know about how things are implemented at the moment, so I can have a fresh view on how a developer writing a client without being familiar with Briar's internals would see things.
> It is nice to being able to access the raw message, being able to put your own data structures in there. It is nice that you can encode and parse metadata. However, for many applications that might not be necessary and all the developer wants is a simple key value store. We have this already with the BdfDictionary which resembles JSON and which I like.
> So I was wondering, why we don't add a layer on top of what we have and allow the client developer to directly get a BdfDictionary (which I will call Payload) from the message. The same way, when composing the message, just let the developer provide the payload and the lower layers handle the rest.
> Here's some pseudo code to illustrate those thoughts:
```java
class MyClient extends BrambleClient {
@Override
public void receivedMessage(Message m) {
Payload payload = m.getPayload(); // this is currently called BdfDictionary
String myString = payload.getString("myString");
long myInt = payload.getIntegeger("myInt");
Object myObject = payload.getSerializable("mySerializableObject");
doSomething(myString, myInt);
}
public void sendMessage() {
Payload payload = new Payload();
payload.putString("myString", "foo");
payload.putInteger("myString", "foo");
payload.putSerializable("mySerializableObject", myObject);
Message m = messageFactory.createMessage(payload);
// if that's not possible, it can be db.addLocalMessage(group, ...)
Group group = getGroup(contact);
group.sendMessage(m);
}
public void doSomething(String s, int i) {
// payload queries for easy access to messages
List<Messages> msgs1 = db.getMessagesWithPayloadKey(group, "myString");
List<Messages> msgs2 = db.getMessagesWherePayload(group, "myString", String, s);
}
}
```
> Adding data to the payload is very similar to how intent extras or bundles work in the Android API, so many people are already familar with it.
> Also note that there's no mention of validatingMessage() because the client developer is only interesting in receiving a message, so there could be just another hook for that.
> If at all possible, I would like the client developer to write as little validation code as possible. Not having to check lengths and such things, but maybe only to see if the payload objects she expects are there.
> I think that payload queries (however they will look like) would also be a very nice addition and convenience methods for client developers, so they don't have to iterate through message lists themselves just to find the ones they are interested in.Milestone Cakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/253Show Introduction and Responses in UI2018-06-12T11:32:32ZTorsten GroteShow Introduction and Responses in UICurrently, the introduction client shows the introductions and the responses to them only in system notifications. See [the related wiki page](https://code.briarproject.org/akwizgran/briar/wikis/IntroductionClient#draft-of-user-interface...Currently, the introduction client shows the introductions and the responses to them only in system notifications. See [the related wiki page](https://code.briarproject.org/akwizgran/briar/wikis/IntroductionClient#draft-of-user-interface) for how it is done at the moment.
If the user signs out of Briar before responding via the notification, the notification will be removed leaving the user with no way to respond and the invitation protocol in limbo forever. Therefore, the received introductions should be shown somewhere else in the UI as long as they are not responded to.
Very similar to that are invitations to participate in a forum where there's also a message the user needs to respond to and that needs to be visually presented to the user in some way. That functionality is tracked in #121.
Other related tickets are [Show new messages/forum posts on dashboard](#42) and [Show recent activity on the dashboard](#88) which focus on the Dashboard which does not exist anymore. It has been proposed to show introductions/invitations in the navigation drawer in the appropriate section, so either Contacts or Forums.
There, the number of unread messages could also be shown. Later other notifications might be needed e.g. for Blogs or RSS feed reader. So a unified UI concept would be welcome.
Subtask of #118.Milestone Bhttps://code.briarproject.org/briar/briar/-/issues/252New polling logic for LAN2018-06-12T11:32:32ZakwizgranNew polling logic for LANSubtask of #116.Subtask of #116.Milestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/251New polling logic for Bluetooth2018-06-12T11:32:32ZakwizgranNew polling logic for BluetoothSubtask of #116.Subtask of #116.Milestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/250New polling logic for Tor2018-06-12T11:32:32ZakwizgranNew polling logic for TorSubtask of #116.Subtask of #116.Milestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/249Support multi-block messages2018-05-11T13:29:32ZakwizgranSupport multi-block messagesDepends on #175.Depends on #175.https://code.briarproject.org/briar/briar/-/issues/248Expose transactions to sync clients2018-06-12T11:32:32ZakwizgranExpose transactions to sync clientsSubtask of #112.Subtask of #112.Milestone Aakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/247Replace Guice/Roboguice with Dagger 22018-06-12T11:32:33ZErnir ErlingssonReplace Guice/Roboguice with Dagger 2After much deliberation we decided to replace Guice and Roboguice with Dagger 2 due to these benefits:
* Better performance
* No reflection
* Smaller library
* Compile errors instead of runtime errors.After much deliberation we decided to replace Guice and Roboguice with Dagger 2 due to these benefits:
* Better performance
* No reflection
* Smaller library
* Compile errors instead of runtime errors.Milestone Chttps://code.briarproject.org/briar/briar/-/issues/246Set up unit testing for Android code2018-06-12T11:32:33ZakwizgranSet up unit testing for Android codeWe currently have unit tests for (parts of) briar-core and briar-desktop, but not for briar-android. Some of the UI logic is quite complex and should be tested. Choose an appropriate test framework and set up automated unit tests.We currently have unit tests for (parts of) briar-core and briar-desktop, but not for briar-android. Some of the UI logic is quite complex and should be tested. Choose an appropriate test framework and set up automated unit tests.Milestone Chttps://code.briarproject.org/briar/briar/-/issues/245Create constants for keys used to store extras in intents2018-06-12T11:32:33ZakwizgranCreate constants for keys used to store extras in intents> @ernir: We really should make constants for all of these keys, I don't want to spend any time debugging in the future because of a spelling error...> @ernir: We really should make constants for all of these keys, I don't want to spend any time debugging in the future because of a spelling error...Milestone Ehttps://code.briarproject.org/briar/briar/-/issues/239Implement proguard and clean up the gradle dependencies2018-06-12T11:32:33ZErnir ErlingssonImplement proguard and clean up the gradle dependenciesFelt right to make this atomicFelt right to make this atomicMilestone Bhttps://code.briarproject.org/briar/briar/-/issues/238Allow messages to be deleted2018-06-12T11:32:33ZakwizgranAllow messages to be deletedAllow messages to be deleted from the database. If a message being deleted is shared, we need to keep enough information about it to avoid syncing it back to life.Allow messages to be deleted from the database. If a message being deleted is shared, we need to keep enough information about it to avoid syncing it back to life.Milestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/237Create client for negotiating supported clients2018-04-29T16:28:05ZakwizgranCreate client for negotiating supported clientsIn future we'll add support for new clients (blogs, group messaging) and we'll need to know which contacts support those clients. Create a BSP client supported by all versions of Briar that syncs a list of supported clients with each con...In future we'll add support for new clients (blogs, group messaging) and we'll need to know which contacts support those clients. Create a BSP client supported by all versions of Briar that syncs a list of supported clients with each contact. The list should include a device ID for future multi-device support.Android 1.0akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/236Migrate to Curve25519 and Ed255192018-02-16T18:19:21Zstr4dMigrate to Curve25519 and Ed25519See comments in #117.See comments in #117.Android 1.0https://code.briarproject.org/briar/briar/-/issues/234Remove consumers from BdfWriter2018-06-12T11:32:33ZakwizgranRemove consumers from BdfWriterMilestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/233Add MAC to messages in private groups2018-01-28T11:30:28ZakwizgranAdd MAC to messages in private groupsFor future multi-device support it would be useful for private groups (i.e. groups shared between a pair of contacts) to be shared by all the contacts' devices, so that messages are automatically synchronised among all devices.
A user...For future multi-device support it would be useful for private groups (i.e. groups shared between a pair of contacts) to be shared by all the contacts' devices, so that messages are automatically synchronised among all devices.
A user's devices need to be able to distinguish remote messages created by the user's other devices from remote messages created by the contact's devices.
A simple way to achieve that is to add a MAC to all messages and share the MAC key between the user's devices. Any message with a valid MAC was created by one of the user's devices, any other message was created by one of the contact's devices.
We're not implementing multi-device support yet, but we should add this now so we don't have to change the wire format later.https://code.briarproject.org/briar/briar/-/issues/229Convert TransportPropertyManager into a BSP client2018-04-16T16:24:37ZakwizgranConvert TransportPropertyManager into a BSP clientSubtask of #112Subtask of #112Milestone Aakwizgranakwizgran