briar issueshttps://code.briarproject.org/groups/briar/-/issues2022-01-18T16:24:05Zhttps://code.briarproject.org/briar/briar-desktop/-/issues/145Inform contacts about supported features such as groups, forums, blogs etc2022-01-18T16:24:05ZSebastianInform contacts about supported features such as groups, forums, blogs etcNow that we know, that the first Desktop release is not going to support forums, group chats and blogs, we need to inform contacts about that. @akwizgran any guidance on what we need to do there?Now that we know, that the first Desktop release is not going to support forums, group chats and blogs, we need to inform contacts about that. @akwizgran any guidance on what we need to do there?Desktop 0.1.0SebastianSebastianhttps://code.briarproject.org/briar/briar-desktop/-/issues/144Add Features flags like in briar2022-01-07T21:38:07ZSebastianAdd Features flags like in briarSo that we can disable forums, group chats and blogsSo that we can disable forums, group chats and blogsDesktop 0.1.0SebastianSebastianhttps://code.briarproject.org/briar/briar-desktop/-/issues/142Bump Compose to stable v1.0.12022-01-07T22:43:51ZMikolai GütschowBump Compose to stable v1.0.1Desktop 0.1.0Mikolai GütschowMikolai Gütschowhttps://code.briarproject.org/briar/briar-desktop/-/issues/140Check TODO notes in code before release2022-01-18T21:03:04ZSebastianCheck TODO notes in code before releaseAt some point, we should check whether any of the TODO notes in code needs to be resolved before the first release for example. Create issues for them or might solve them direct.At some point, we should check whether any of the TODO notes in code needs to be resolved before the first release for example. Create issues for them or might solve them direct.Desktop 0.1.0NicoNicohttps://code.briarproject.org/briar/briar/-/issues/2234Abstract task for calling an API endpoint2022-06-17T13:34:16ZakwizgranAbstract task for calling an API endpointCreate an abstract task for calling an API endpoint. The task should block until the API call succeeds or permanently fails. Temporary failures should be retried automatically with backoff, and it should be possible to cancel the task be...Create an abstract task for calling an API endpoint. The task should block until the API call succeeds or permanently fails. Temporary failures should be retried automatically with backoff, and it should be possible to cancel the task between tries.Mailboxakwizgranakwizgranhttps://code.briarproject.org/briar/briar-desktop/-/issues/138Add Contact Dialog TextBox Visual Bug2022-01-06T22:00:22ZpaulAdd Contact Dialog TextBox Visual BugOn Trisquel Linux, with the default Briar desktop window size, the bottom textbox's content is not visible.
![dialog-bug](/uploads/e0c98ac0c82e3564208d4100e157f285/dialog-bug.gif)On Trisquel Linux, with the default Briar desktop window size, the bottom textbox's content is not visible.
![dialog-bug](/uploads/e0c98ac0c82e3564208d4100e157f285/dialog-bug.gif)Desktop 0.1.0SebastianSebastianhttps://code.briarproject.org/briar/briar-desktop/-/issues/137First release2022-01-07T14:07:42ZMikolai GütschowFirst releasePrivate chats (almost) feature-complete:
- [x] write/read messages
- [ ] introductions
- [ ] self-destructing messages
- [ ] receive/show images (perhaps not send yet)
- [ ] user avatars
- [ ] delete messages
- [ ] change contact alias
-...Private chats (almost) feature-complete:
- [x] write/read messages
- [ ] introductions
- [ ] self-destructing messages
- [ ] receive/show images (perhaps not send yet)
- [ ] user avatars
- [ ] delete messages
- [ ] change contact alias
- [ ] delete contacts
Supported platform: Linux
Planned release: January, 21sthttps://code.briarproject.org/briar/briar-desktop/-/issues/136IDEA formatting and ktlintFormat disagreement2021-12-06T14:25:10ZSebastianIDEA formatting and ktlintFormat disagreementDesktop 0.1.0SebastianSebastianhttps://code.briarproject.org/briar/briar/-/issues/2233Method for deleting a file from a mailbox2022-03-25T17:18:28ZakwizgranMethod for deleting a file from a mailboxDepends on briar-mailbox#3, briar-mailbox#53.Depends on briar-mailbox#3, briar-mailbox#53.Mailbox: File management APITorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/2232Method for downloading a file from a mailbox2022-03-25T17:18:28ZakwizgranMethod for downloading a file from a mailboxDepends on briar-mailbox#3, briar-mailbox#52.Depends on briar-mailbox#3, briar-mailbox#52.Mailbox: File management APITorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/2231Method for uploading a file to a mailbox2022-03-25T16:03:18ZakwizgranMethod for uploading a file to a mailboxDepends on briar-mailbox#3, briar-mailbox#54.Depends on briar-mailbox#3, briar-mailbox#54.Mailbox: File management APITorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/2230Add DB methods for tracking pending uploads2022-03-30T14:29:01ZakwizgranAdd DB methods for tracking pending uploadsAdd database methods for storing the contact ID and filename of pending mailbox uploads. It should be possible to query by contact ID (for use when a mailbox becomes reachable and we want to retry failed uploads) and to delete by contact...Add database methods for storing the contact ID and filename of pending mailbox uploads. It should be possible to query by contact ID (for use when a mailbox becomes reachable and we want to retry failed uploads) and to delete by contact ID and filename (for use when an upload succeeds).Mailbox: Manage mailbox connectionsTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/2229Mailbox client superclass2022-06-20T11:20:55ZakwizgranMailbox client superclassMailbox clients for communicating with our own mailbox and contacts' mailboxes are managed by a singleton mailbox client manager (#2228).
We'll need different client implementations for our own mailbox (#2290) and contacts' mailboxes (#...Mailbox clients for communicating with our own mailbox and contacts' mailboxes are managed by a singleton mailbox client manager (#2228).
We'll need different client implementations for our own mailbox (#2290) and contacts' mailboxes (#2289), but there will be a shared interface and some shared code. This ticket covers the code shared between the client for our own mailbox and the client for a contact's mailbox.
Interface:
* The manager can create and destroy clients
* The manager can assign/deassign contacts for upload or download
* The client's upload and download workers can request connectivity checks
Implementation:
* At any given time the client may have multiple upload workers and/or a single download worker
* The client has a connectivity check method, which takes an observer as an argument
* The client stores the time of the latest successful connectivity check, a reference to the current connectivity check task, if any, and a list of observers waiting for the result of a connectivity check
When the client is destroyed:
* If a connectivity check task is running:
* Cancel the connectivity check task
* Destroy the upload workers, if any
* Destroy the download worker, if any
When the connectivity check method is called:
* Compare the current time to the time of the latest successful connectivity check
* If a connectivity check has recently succeeded:
* Notify the observer
* Else if a connectivity check task is running:
* Add the observer to the list of waiting observers
* Else:
* Add the observer to the list of waiting observers
* Start a connectivity check task
When a connectivity check task succeeds:
* Update the time of the latest successful connectivity check
* Notify any waiting observers
* Clear the list of waiting observersMailbox: Manage mailbox connectionsakwizgranakwizgranhttps://code.briarproject.org/briar/briar-desktop/-/issues/135Display pending contacts in contact list2022-01-18T16:38:42ZSebastianDisplay pending contacts in contact listDesktop 0.1.0SebastianSebastianhttps://code.briarproject.org/briar/briar-desktop/-/issues/134KDoc formatting2021-12-06T14:25:10ZSebastianKDoc formattingI just noticed the KDoc in DeterministicTestDataCreator as a bit strangely indented. ktlintFormat and the IDEA formatter don't seem to care, but they both allow us to format multi-line `@param` descriptions on the second line as we like....I just noticed the KDoc in DeterministicTestDataCreator as a bit strangely indented. ktlintFormat and the IDEA formatter don't seem to care, but they both allow us to format multi-line `@param` descriptions on the second line as we like. I've looked through the kotlin codebase to find examples on how the do it and found [at least this](https://github.com/JetBrains/kotlin/blob/master/libraries/stdlib/src/kotlin/reflect/KProperty.kt#L63). In the same file there's also an example of different style, so apparently they didn't agree on or enforce something either.Desktop 0.1.0SebastianSebastianhttps://code.briarproject.org/briar/briar-desktop/-/issues/133Show notification badge for new messages in BriarSidebar2023-01-17T11:11:44ZMikolai GütschowShow notification badge for new messages in BriarSidebarSee the discussion at https://code.briarproject.org/briar/briar-desktop/-/issues/108#note_57164:
@paul-lorenc:
> Would it also make sense to add a blue notification badge to the sidebar above the type of incoming message? For example, i...See the discussion at https://code.briarproject.org/briar/briar-desktop/-/issues/108#note_57164:
@paul-lorenc:
> Would it also make sense to add a blue notification badge to the sidebar above the type of incoming message? For example, if you are having a one-on-one conversation with a contact, it might be useful to see that there are unread messages in the private group or forum tabs. I don't think a numbered message badge is needed, just a simple blue or green badge to indicate there are new messages in that tab. If something like this would be somewhat simple, I think it would help UX a lot.
@akwizgran:
> Yeah, on Android it looks like we depend on ContactListFragment reloading the contact list to update the unread count when the user returns from a conversation to the contact list (which incidentally makes me wonder how briar#2145 ever existed - apparently the problem was not what I thought).
>
> To update the contact list's unread count via events we'd want to do something similar to briar!1541, wrapping MessageTracker#setReadFlag() and broadcasting an event with the contact ID. Fortunately ConversationManager already wraps that method, so we don't need to refactor any callers, just add the event. So the first part of this should be easy.
>
> Similarly, we can display the unread counts and timestamps for individual forums and private groups by adding an event broadcast to ForumManager and PrivateGroupManager's existing wrappers around MessageTracker methods.
>
> Blogs don't seem to use GroupCounts at all, so there's a big pile of work to do there.
>
> And then finally we'd want to display an aggregate count for all private conversations, another aggregate count for all forums, etc, in the sidebar (nav drawer on Android). We could add methods to ConversationManager, ForumManager, PrivateGroupManager and BlogManager (after adding GroupCounts to the individual blogs) to calculate these aggregate counts when first loading the sidebar, and then update the aggregate counts via the same events that would be used to update the individual counts.
The related upstream issue is https://code.briarproject.org/briar/briar/-/issues/42 and the custom event introduced in https://code.briarproject.org/briar/briar-desktop/-/merge_requests/46#note_56940 could be adapted for this.Desktop 0.4.0Mikolai GütschowMikolai Gütschowhttps://code.briarproject.org/briar/briar/-/issues/2228Mailbox client manager2022-08-16T14:20:43ZakwizgranMailbox client manager* Create a singleton mailbox client manager
* This component manages a set of mailbox clients (#2229): one client for each mailbox we know about
* The manager creates the clients when we come online and destroys them when we go offline
*...* Create a singleton mailbox client manager
* This component manages a set of mailbox clients (#2229): one client for each mailbox we know about
* The manager creates the clients when we come online and destroys them when we go offline
* The manager is responsible for assigning contacts to mailboxes for upload and/or download - so each client has a set of contacts assigned for upload and a (possibly different) set of contacts assigned for download
* These assignments can change based on pairing/unpairing a mailbox, learning which API versions our own mailbox supports, a contact being added/removed, or receiving new mailbox properties from a contact
* The assignments don't change based on connecting to a contact or disconnecting from a contact
* A contact's mailbox is "usable" if it supports an API version that we and the contact can both use, according to our hardcoded client-supported versions and the latest server-supported and client-supported versions received from the contact
* Our own mailbox is "usable" by a contact if it supports an API version that we and the contact can both use, according to our hardcoded client-supported versions, the latest server-supported versions fetched from our own mailbox, and the latest client-supported versions received from the contact
* If we have a mailbox, we always have a client for it regardless of whether our hardcoded client-supported versions are compatible with the latest server-supported versions fetched from the mailbox
* If a contact has a mailbox, we only have a client for it if it's usable
When we come online:
* For each contact:
* If the contact has a usable mailbox:
* Create a client for the contact's mailbox
* Assign the contact to the contact's mailbox for upload
* If we don't have a mailbox that's usable by the contact:
* Assign the contact to the contact's mailbox for download
* If we have our own mailbox:
* Create a client for our own mailbox
* For each contact:
* If our own mailbox is usable by the contact:
* Assign the contact to our own mailbox for download
* If the contact doesn't have a usable mailbox:
* Assign the contact to our own mailbox for upload
When we go offline:
* Destroy all clients
When we pair a mailbox:
* If we're online:
* Create a client for our own mailbox
* For each contact:
* If the contact has a usable mailbox:
* If our own mailbox is usable by the contact:
* Reassign the contact from the contact's mailbox to our own mailbox for download
* (The contact remains assigned to the contact's mailbox for upload)
* Else, if our own mailbox is usable by the contact:
* Assign the contact to our own mailbox for upload and download
When we unpair a mailbox:
* If we're online:
* For each contact:
* If the contact has a usable mailbox:
* If the contact is assigned to our own mailbox for download:
* Reassign the contact from our own mailbox to the contact's mailbox for download
* (The contact is already assigned to the contact's mailbox for upload)
* Destroy the client for our own mailbox
When a contact is added:
* Assumption: the contact has no mailbox properties yet, as the event informing us of the contact's first mailbox update is always delivered after the event informing us that the contact was added
* Wait until we receive the contact's first mailbox update before deciding how to assign the contact for upload and download
When a contact is removed:
* If we're online:
* If we have a client for the contact's mailbox:
* Destroy the client for the contact's mailbox
* If the contact is assigned to our own mailbox for download:
* Deassign the contact from our own mailbox for download
* If the contact is assigned to our own mailbox for upload:
* Deassign the contact from our own mailbox for upload
When we receive a mailbox update from a contact:
* If we're online:
* If the contact didn't previously have a usable mailbox and now has one:
* Create a client for the contact's mailbox
* If we have a mailbox that's usable by the contact:
* Reassign the contact from our own mailbox to the contact's mailbox for upload
* (The contact remains assigned to our own mailbox for download)
* Else:
* Assign the contact to the contact's mailbox for upload and download
* Else if the contact previously had a usable mailbox and no longer has one:
* If we have a mailbox that's usable by the contact:
* Reassign the contact from the contact's mailbox to our own mailbox for upload
* (The contact remains assigned to our own mailbox for download)
* Destroy the client for the contact's mailbox
* Else if the contact previously had a usable mailbox and now has a different mailbox that's also usable:
* Destroy the client for the contact's mailbox
* Create a new client for the contact's mailbox
* Assign the contact to the contact's mailbox for upload
* If we don't have a mailbox that's usable by the contact:
* Assign the contact to the contact's mailbox for downloadMailbox: Manage mailbox connectionsakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/2225Error handling for mailbox downloads2021-12-10T14:45:35ZakwizgranError handling for mailbox downloadsWhen communicating via mailboxes, the max latency and thus the retransmission interval are very long, so we need to be careful about any circumstances that could cause messages to be lost.
On the receiver side, if an error (such as an I...When communicating via mailboxes, the max latency and thus the retransmission interval are very long, so we need to be careful about any circumstances that could cause messages to be lost.
On the receiver side, if an error (such as an IO error, app shutdown, app crash or device crash) occurs while we're reading messages from a file, we need to ensure that the file can be read again after recovering from the error. Reading the file twice isn't possible with the current protocol stack because the pseudo-random tag at the start of the file is recognised on the first read and can't be recognised again.
To fix this we should divide the process of recognising a tag into two steps. The first step looks up the tag and returns the keys needed for authenticating and decrypting the stream header. The second step marks the tag as recognised and updates the reordering window.
When processing a file downloaded from a mailbox, we should defer the second step until the file has been completely processed.Mailboxhttps://code.briarproject.org/briar/briar-desktop/-/issues/132SecureRandomProvider problem on Mac OS2023-06-26T13:20:35ZSebastianSecureRandomProvider problem on Mac OSWhen I run briar-desktop on Mac OS I get this exception; it does start but prints this to the console:
```
15:46:14.502 [main] WARN o.b.b.s.UnixSecureRandomProvider - java.io.IOException: Operation not permitted
java.io.IOException: Op...When I run briar-desktop on Mac OS I get this exception; it does start but prints this to the console:
```
15:46:14.502 [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:354)
at java.base/java.io.DataOutputStream.writeLong(DataOutputStream.java:224)
at org.briarproject.bramble.system.AbstractSecureRandomProvider.writeToEntropyPool(AbstractSecureRandomProvider.java:25)
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:78)
at org.briarproject.bramble.crypto.CryptoModule.provideCryptoComponent(CryptoModule.java:32)
at org.briarproject.bramble.crypto.CryptoModule_ProvideCryptoComponentFactory.provideCryptoComponent(CryptoModule_ProvideCryptoComponentFactory.java:42)
at org.briarproject.bramble.crypto.CryptoModule_ProvideCryptoComponentFactory.get(CryptoModule_ProvideCryptoComponentFactory.java:31)
at org.briarproject.bramble.crypto.CryptoModule_ProvideCryptoComponentFactory.get(CryptoModule_ProvideCryptoComponentFactory.java:10)
at dagger.internal.DoubleCheck.get(DoubleCheck.java:47)
at org.briarproject.bramble.sync.MessageFactoryImpl_Factory.get(MessageFactoryImpl_Factory.java:21)
at org.briarproject.bramble.sync.MessageFactoryImpl_Factory.get(MessageFactoryImpl_Factory.java:8)
at org.briarproject.bramble.sync.SyncModule_ProvideMessageFactoryFactory.get(SyncModule_ProvideMessageFactoryFactory.java:26)
at org.briarproject.bramble.sync.SyncModule_ProvideMessageFactoryFactory.get(SyncModule_ProvideMessageFactoryFactory.java:9)
at org.briarproject.bramble.db.DatabaseModule_ProvideDatabaseFactory.get(DatabaseModule_ProvideDatabaseFactory.java:36)
at org.briarproject.bramble.db.DatabaseModule_ProvideDatabaseFactory.get(DatabaseModule_ProvideDatabaseFactory.java:12)
at dagger.internal.DoubleCheck.get(DoubleCheck.java:47)
at org.briarproject.bramble.db.DatabaseModule_ProvideDatabaseComponentFactory.get(DatabaseModule_ProvideDatabaseComponentFactory.java:40)
at org.briarproject.bramble.db.DatabaseModule_ProvideDatabaseComponentFactory.get(DatabaseModule_ProvideDatabaseComponentFactory.java:13)
at dagger.internal.DoubleCheck.get(DoubleCheck.java:47)
at org.briarproject.bramble.lifecycle.LifecycleManagerImpl_Factory.get(LifecycleManagerImpl_Factory.java:30)
at org.briarproject.bramble.lifecycle.LifecycleManagerImpl_Factory.get(LifecycleManagerImpl_Factory.java:10)
at org.briarproject.bramble.lifecycle.LifecycleModule_ProvideLifecycleManagerFactory.get(LifecycleModule_ProvideLifecycleManagerFactory.java:26)
at org.briarproject.bramble.lifecycle.LifecycleModule_ProvideLifecycleManagerFactory.get(LifecycleModule_ProvideLifecycleManagerFactory.java:9)
at dagger.internal.DoubleCheck.get(DoubleCheck.java:47)
at org.briarproject.bramble.cleanup.CleanupModule_ProvideCleanupManagerFactory.get(CleanupModule_ProvideCleanupManagerFactory.java:35)
at org.briarproject.bramble.cleanup.CleanupModule_ProvideCleanupManagerFactory.get(CleanupModule_ProvideCleanupManagerFactory.java:11)
at dagger.internal.DoubleCheck.get(DoubleCheck.java:47)
at org.briarproject.briar.desktop.DaggerBriarDesktopApp.injectEagerSingletons(DaggerBriarDesktopApp.java:1444)
at org.briarproject.briar.desktop.DaggerBriarDesktopApp.inject(DaggerBriarDesktopApp.java:1336)
at org.briarproject.bramble.BrambleCoreEagerSingletons$Helper.injectEagerSingletons(BrambleCoreEagerSingletons.java:48)
at org.briarproject.briar.desktop.Main.run(Main.kt:75)
at com.github.ajalt.clikt.parsers.Parser.parse(Parser.kt:198)
at com.github.ajalt.clikt.parsers.Parser.parse(Parser.kt:18)
at com.github.ajalt.clikt.core.CliktCommand.parse(CliktCommand.kt:395)
at com.github.ajalt.clikt.core.CliktCommand.parse$default(CliktCommand.kt:392)
at com.github.ajalt.clikt.core.CliktCommand.main(CliktCommand.kt:410)
at com.github.ajalt.clikt.core.CliktCommand.main(CliktCommand.kt:435)
at org.briarproject.briar.desktop.MainKt.main(Main.kt:102)
```
Happens with different distributions of JDK 11 (openjdk and temurin) and also when running (not building) with JDK 17 (azul)Desktop 0.5.0SebastianSebastianhttps://code.briarproject.org/briar/briar/-/issues/2222Headless BriarService doesn't check for lifecycle startup errors2022-01-03T16:38:00ZakwizgranHeadless BriarService doesn't check for lifecycle startup errorsBriarService.kt doesn't check the return value of LifecycleManager#startServices(), and stopServices() is called regardless of whether startup succeeded.BriarService.kt doesn't check the return value of LifecycleManager#startServices(), and stopServices() is called regardless of whether startup succeeded.