briar issueshttps://code.briarproject.org/groups/briar/-/issues2018-06-12T11:32:17Zhttps://code.briarproject.org/briar/briar/-/issues/683Refactor forum UI to improve asymptotic performance2018-06-12T11:32:17ZakwizgranRefactor forum UI to improve asymptotic performanceNestedForumAdapter has some methods that run in O(N\^2) time. Refactor the forum code so we don't need nested loops to calculate things like visibility and descendent counts.NestedForumAdapter has some methods that run in O(N\^2) time. Refactor the forum code so we don't need nested loops to calculate things like visibility and descendent counts.https://code.briarproject.org/briar/briar/-/issues/682Test effect of touching forum entries while they're collapsing/expanding2018-06-12T11:32:17ZakwizgranTest effect of touching forum entries while they're collapsing/expandingWrite UI tests that generate touch events for forum entries during the expand/collapse animations, to ensure the NestedForumAdapter logic for assigning positions to visible elements doesn't have any corner cases for elements that are in ...Write UI tests that generate touch events for forum entries during the expand/collapse animations, to ensure the NestedForumAdapter logic for assigning positions to visible elements doesn't have any corner cases for elements that are in the process of expanding/collapsing.https://code.briarproject.org/briar/briar/-/issues/681Convert forum post bodies to strings, remove content type2018-06-12T11:32:17ZakwizgranConvert forum post bodies to strings, remove content typeMilestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/674Ending a transaction can throw an exception in a finally block2018-06-12T11:32:18ZakwizgranEnding a transaction can throw an exception in a finally blockWe use the following pattern to commit or roll back a transaction:
```
Transaction txn = db.startTransaction();
try {
db.doSomething(txn);
txn.setComplete();
} finally {
db.endTransaction(txn);
}
```
`DatabaseComponent#endTr...We use the following pattern to commit or roll back a transaction:
```
Transaction txn = db.startTransaction();
try {
db.doSomething(txn);
txn.setComplete();
} finally {
db.endTransaction(txn);
}
```
`DatabaseComponent#endTransaction()` can throw a `DbException`, and Android Studio warns about the potential for the exception to be thrown in a finally block.
We should move the exception-throwing code from `endTransaction()` into a new `commitTransaction()` method, which replaces `Transaction#setComplete()` and is called inside the try block. The new contract of `endTransaction()` should be to abort the transaction if it has not already been committed, and release the database lock in either case.
```
Transaction txn = db.startTransaction();
try {
db.doSomething(txn);
db.commitTransaction(txn);
} finally {
db.endTransaction(txn);
}
```Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/673PrivateGroupManager facade2018-06-12T11:32:18ZakwizgranPrivateGroupManager facadeCreate a PrivateGroupManager interface in briar-api, with a stub implementation in briar-core, to allow development of the UI. The interface can be based on the existing ForumManager, with supporting classes for message headers, etc, as ...Create a PrivateGroupManager interface in briar-api, with a stub implementation in briar-core, to allow development of the UI. The interface can be based on the existing ForumManager, with supporting classes for message headers, etc, as required.
Subtask of #127.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/670Uncaught exceptions do not print a stack trace in IntroductionIntegrationTest2018-06-12T11:32:18ZSantiago Torres-AriasUncaught exceptions do not print a stack trace in IntroductionIntegrationTestErrors and uncaught exceptions do not print a stack trace unless a try/catch block is added for NPE. This is a followup for the discussion in !237Errors and uncaught exceptions do not print a stack trace unless a try/catch block is added for NPE. This is a followup for the discussion in !237Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/669Integration tests need to know the client ID of MessageStateChangedEvents2018-06-12T11:32:18ZakwizgranIntegration tests need to know the client ID of MessageStateChangedEventsRecent refactoring of the validation manager removed the client ID from MessageStateChangedEvents, because these events are only used by tests and a lot of code in the validation manager and DB existed just to attach client IDs to these ...Recent refactoring of the validation manager removed the client ID from MessageStateChangedEvents, because these events are only used by tests and a lot of code in the validation manager and DB existed just to attach client IDs to these events. This has made the tests fail unpredictably.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/659Protocol for private group invitations2018-06-12T11:32:18ZakwizgranProtocol for private group invitationsThis could be similar to the blog and forum invitation protocols, but there's an opportunity to make it simpler, as only the creator of the group can send invitations. When a member has been added or removed, the creator should send an a...This could be similar to the blog and forum invitation protocols, but there's an opportunity to make it simpler, as only the creator of the group can send invitations. When a member has been added or removed, the creator should send an announcement to the group (see #658).
Related to #456. Subtask of #127.Milestone Eakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/658Protocol for private group messaging2018-06-12T11:32:18ZakwizgranProtocol for private group messagingThis can be similar to the forum protocol, plus messages for announcing when members join and leave. We may not need a message for announcing that the group has been dissolved, as that may be part of the invitation protocol.
Posts will ...This can be similar to the forum protocol, plus messages for announcing when members join and leave. We may not need a message for announcing that the group has been dissolved, as that may be part of the invitation protocol.
Posts will need to be compared with the current membership list to ensure they're signed by members, taking into account the possibility of posts and membership messages arriving out of order.
Subtask of #127.Milestone Eakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/643Allow messages to be deleted in the delivery hook2018-06-12T11:32:19ZakwizgranAllow messages to be deleted in the delivery hookIf a client deletes a message in the delivery hook, the validation manager treats the message as invalid. Clients may want to delete messages they've finished handlng without having them invalidated, so we should provide some other way f...If a client deletes a message in the delivery hook, the validation manager treats the message as invalid. Clients may want to delete messages they've finished handlng without having them invalidated, so we should provide some other way for the delivery hook to signal that a message is invalid, such as throwing an InvalidMessageException.Milestone FTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/642Remove loading screen callbacks from BaseFragmentListener2018-06-12T11:32:19ZakwizgranRemove loading screen callbacks from BaseFragmentListenerFragments should be responsible for their own progress bars.Fragments should be responsible for their own progress bars.Milestone Ehttps://code.briarproject.org/briar/briar/-/issues/640Detect blogs that are no longer receiving updates2020-11-21T17:05:02ZakwizgranDetect blogs that are no longer receiving updatesIt's possible for a blog subscriber to be cut off from the blog's author due to upstream subscribers unsubscribing or leaving the network. We could use some combination of keepalive messages from the author and an adaptive timeout at the...It's possible for a blog subscriber to be cut off from the blog's author due to upstream subscribers unsubscribing or leaving the network. We could use some combination of keepalive messages from the author and an adaptive timeout at the subscriber to detect this and mark the blog as inactive or unreachable.
If we use keepalives, the interval between keepalives should adapt to the average interval between posts. If we use a timeout at the subscriber based on the arrival times of updates, TCP's running estimates of round-trip time and round-trip time variance might be a good place to start.
Depending on the mechanism used, this might also be applicable to other kinds of group.https://code.briarproject.org/briar/briar/-/issues/631Inject fragments earlier in their lifecycle2018-12-19T11:24:56ZakwizgranInject fragments earlier in their lifecycleFragments are injected in `Fragment#onActivityCreated()`, which is called after `Fragment#onCreate()` and `Fragment#onCreateView()`, meaning injected fields can't be used in those methods. It would sometimes be useful to have access to i...Fragments are injected in `Fragment#onActivityCreated()`, which is called after `Fragment#onCreate()` and `Fragment#onCreateView()`, meaning injected fields can't be used in those methods. It would sometimes be useful to have access to injected fields earlier in the fragment's lifecycle.
Injection happens at this point because BaseActivity creates its ActivityComponent in `Activity#onCreate()`. Would it be possible for BaseFragment to create a FragmentComponent in `Fragment#onCreate()` (or even `Fragment#onAttach()`) to avoid this dependency on the activity to perform injection?Android 1.1Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/629Test whether Tor hidden service patch is still needed2018-07-31T16:17:46ZakwizgranTest whether Tor hidden service patch is still needed~~Repeat the Tor performance experiments from #115 using Tor 0.2.6.7 with the old and new code to determine the impact of improvements to Tor itself, specifically issue #8239 (https://trac.torproject.org/projects/tor/ticket/8239).~~
Rep...~~Repeat the Tor performance experiments from #115 using Tor 0.2.6.7 with the old and new code to determine the impact of improvements to Tor itself, specifically issue #8239 (https://trac.torproject.org/projects/tor/ticket/8239).~~
Repeat the Tor performance experiments from #115 using Tor 0.2.9.15, with and without our hidden service patch, to see whether our patch still affects performance. Test the patch from issue #19522 (https://trac.torproject.org/projects/tor/ticket/19522) to see whether it would be a suitable alternative to our patch.
If our patch is still needed, update it to address the reviewers' comments from https://trac.torproject.org/projects/tor/ticket/18620. That ticket should be closed, as v2 hidden services are being deprecated. If we need a new patch for v3 hidden services we should open a new ticket.
See discussion on #115. ~~Subtask of #152.~~Android 1.1akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/628Bring protocols into line with spec2018-04-16T16:24:37ZakwizgranBring protocols into line with spec* BQP should ignore records with unknown versions/record types
* BSP should ignore records with unknown versions/record types
* BSP should use "record" rather than "packet"
* Max message body length should be 2^15 bytes (32 KiB)
* Max gr...* BQP should ignore records with unknown versions/record types
* BSP should ignore records with unknown versions/record types
* BSP should use "record" rather than "packet"
* Max message body length should be 2^15 bytes (32 KiB)
* Max group descriptor length should be 2^15 bytes (32 KiB)
* Message ID should hash group ID, timestamp, body as separate argumentsMilestone FTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/627Tests for Introduction Security Properties2018-06-12T11:32:19ZTorsten GroteTests for Introduction Security PropertiesWhen testing the introduction protocol, it makes sense to use a real MAC and signature, otherwise we're just testing that verification detects an invalid signature/MAC, rather than testing that modifying the response makes the signature/...When testing the introduction protocol, it makes sense to use a real MAC and signature, otherwise we're just testing that verification detects an invalid signature/MAC, rather than testing that modifying the response makes the signature/MAC invalid.
It would be good to have tests for the security properties we're trying to provide:
1. If the introducer replaces the ephemeral public key, transport properties and/or timestamp and doesn't modify the ack, the protocol is aborted because the MAC fails
2. If the introducer replaces the ephemeral public key (and optionally the transport properties and/or timestamp) and modifies the ack to use a nonce and MAC key that match the new ephemeral public key, the protocol is aborted because the signature is invalid
Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/625Avoid repeated author status lookups2018-06-12T11:32:19ZakwizgranAvoid repeated author status lookupsWhen loading all post headers in a forum or blog, the author status is looked up for each post individually. The number of lookups could be reduced, especially for blogs, by first creating a set of authors and then looking up each author...When loading all post headers in a forum or blog, the author status is looked up for each post individually. The number of lookups could be reduced, especially for blogs, by first creating a set of authors and then looking up each author's status once.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/623Clean up progress bar handling in BlogActivity2018-06-12T11:32:19ZakwizgranClean up progress bar handling in BlogActivityBlogActivity uses a ViewPager with two FragmentStatePagerAdapters, one of which contains a single BlogFragment (which in turn contains its own RecyclerView adapter) and the other a series of BlogPostFragments. The two adapters allow the ...BlogActivity uses a ViewPager with two FragmentStatePagerAdapters, one of which contains a single BlogFragment (which in turn contains its own RecyclerView adapter) and the other a series of BlogPostFragments. The two adapters allow the blog to be viewed either as a feed or one post at a time.
The BlogFragment uses the RecyclerView's progress bar, whereas the BlogPostFragments rely on a progress bar in the BlogActivity. This complicates the interaction between the components and leads to a small bug when the BlogPostFragments are loading their posts: the progress bar is hidden when the first fragment finishes loading, even if the currently visible fragment is still loading.
Clean this up by moving the progress bar into the BlogPostFragment.
We should investigate other code that uses `BaseFragmentListener#show/hideLoadingScreen()` for similar problems. We may be able to simplify the interaction between components by making each component responsible for showing its own progress bar.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/622Transactional database interface2018-06-12T11:32:19ZakwizgranTransactional database interfaceCurrently the DB is guarded by a read-write lock: read-only transactions acquire the read lock and read-write transactions acquire the write lock. This ensures that we never get lock timeouts from the DB, so clients don't need to worry a...Currently the DB is guarded by a read-write lock: read-only transactions acquire the read lock and read-write transactions acquire the write lock. This ensures that we never get lock timeouts from the DB, so clients don't need to worry about rolling back and retrying transactions if there's a lock timeout. However, if a transaction performs long-running work such as verifying a signature, other transactions are prevented from accessing the database in the meantime.
We can avoid this by creating a transactional interface to the database, which encapsulates each transaction in a task object. Users of the database submit tasks, and the database is responsible for rolling back and retrying any tasks that time out. This allows us to remove the global read-write lock.
```
interface TransactionTask {
boolean run(Transaction txn) throws DbException;
}
```
The task's `run()` method performs DB operations using the provided transaction and returns true if the transaction should be committed or false if it should be aborted. If the `run()` method throws an exception, the transaction is aborted.
The DB has a method for running database tasks:
```
boolean runTask(TransactionTask task) throws DbException;
```
The database's `runTask()` method starts a transaction, passes it to the task, and commits or aborts it as required. The method returns true if the transaction was committed, false if it was aborted, or rethrows an exception thrown by the task.
We can remove the DB's `startTransaction()` and `endTransaction()` methods, along with the transaction's `setComplete()` method, since the DB itself will handle starting, committing and aborting transactions. It will no longer be necessary to specify whether a transaction is read-only or read-write.
Depends on #319.https://code.briarproject.org/briar/briar/-/issues/618BdfDictionary should have a defined iteration order2018-06-12T11:32:20ZakwizgranBdfDictionary should have a defined iteration orderThe iterators for BdfDictionary's keys, values and entries should return their elements in a defined order. Currently BdfDictionary uses the iterators inherited from Hashtable, which have no defined order, so deserialising and reserialis...The iterators for BdfDictionary's keys, values and entries should return their elements in a defined order. Currently BdfDictionary uses the iterators inherited from Hashtable, which have no defined order, so deserialising and reserialising a dictionary may produce output that's different from the input. This will be a problem whenever we want to hash or sign data that contains dictionaries.Milestone Bakwizgranakwizgran