briar issueshttps://code.briarproject.org/groups/briar/-/issues2018-06-12T11:32:24Zhttps://code.briarproject.org/briar/briar/-/issues/487Proof-of-concept RSS feed import with ROME on Android2018-06-12T11:32:24ZakwizgranProof-of-concept RSS feed import with ROME on AndroidThe pull request to remove the java.beans dependency from ROME has been merged, but it doesn't affect rome-fetcher as that module is deprecated. Ensure that we can build and run the code we need for a basic RSS feed fetcher on Android.The pull request to remove the java.beans dependency from ROME has been merged, but it doesn't affect rome-fetcher as that module is deprecated. Ensure that we can build and run the code we need for a basic RSS feed fetcher on Android.Milestone DTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/486Convert RSS feed entries into Briar blog posts2018-06-12T11:32:24ZakwizgranConvert RSS feed entries into Briar blog postsSub-task of #135.
First iteration:
* Use whatever content is included in the feed, don't try to fetch the full text if it's not included
* Strip HTML tagsSub-task of #135.
First iteration:
* Use whatever content is included in the feed, don't try to fetch the full text if it's not included
* Strip HTML tagsMilestone DTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/485Extract new entries from RSS feed2018-06-12T11:32:24ZakwizgranExtract new entries from RSS feedSub-task of #135.
For each registered feed, keep track of which entries have been seen. Pass any new entries down the pipeline to be converted and posted.Sub-task of #135.
For each registered feed, keep track of which entries have been seen. Pass any new entries down the pipeline to be converted and posted.Milestone DTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/484Implement background task for fetching RSS feeds2018-06-12T11:32:24ZakwizgranImplement background task for fetching RSS feedsSub-task of #135.
* Implemented in briar-core, possibly as a Service so it gets started when the app starts
* Exposes a FeedManager interface that the UI can use to register and unregister feeds
* In the first iteration, fetches fee...Sub-task of #135.
* Implemented in briar-core, possibly as a Service so it gets started when the app starts
* Exposes a FeedManager interface that the UI can use to register and unregister feeds
* In the first iteration, fetches feeds via HTTP
* In a future iteration, uses Tor's SOCKS proxyMilestone DTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/483Design UX for importing an RSS feed2018-06-12T11:32:24ZakwizgranDesign UX for importing an RSS feedSub-task of #135.
First iteration:
* The feature should be reachable from the blog screen
* Provide a way for the user to enter the feed URL
* No preview at this stage
* Show an error if the URL can't be fetched and parsed
* Post...Sub-task of #135.
First iteration:
* The feature should be reachable from the blog screen
* Provide a way for the user to enter the feed URL
* No preview at this stage
* Show an error if the URL can't be fetched and parsed
* Posts extracted from the feed will be posted to the user's personal blogMilestone Dhttps://code.briarproject.org/briar/briar/-/issues/478Forum: improve new entry highlighting2018-06-12T11:32:24ZErnir ErlingssonForum: improve new entry highlightingNew forum entries are currently only highlighted, with direct scrolling via the snack bar, when the user already has the respective forum screen visible. A user got a new forum entry notification for a forum with a lot of entries, opened...New forum entries are currently only highlighted, with direct scrolling via the snack bar, when the user already has the respective forum screen visible. A user got a new forum entry notification for a forum with a lot of entries, opened the forum but had no idea where the new forum entry was due to the non-linear nature of the forums.
This is simple in private messaging because the latest entries are almost always at the bottom but we really need to show the user better what forum entries he hasn't read yet.Milestone Fhttps://code.briarproject.org/briar/briar/-/issues/477Private messaging: Text bubble and header overlap2018-06-12T11:32:24ZErnir ErlingssonPrivate messaging: Text bubble and header overlapYour text bubbles and the header have a same color and will overlap when given the chance. A user found this a bit confusing and ugly, and I tend to agree :)
![header_overlap](/uploads/8df13a96f2a23d8f294a82c923b9c5bf/header_overlap.png)Your text bubbles and the header have a same color and will overlap when given the chance. A user found this a bit confusing and ugly, and I tend to agree :)
![header_overlap](/uploads/8df13a96f2a23d8f294a82c923b9c5bf/header_overlap.png)Milestone FTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/476Blog sharing protocol modifies state external to session2018-06-12T11:32:24ZakwizgranBlog sharing protocol modifies state external to sessionSub-task of #456.Sub-task of #456.Milestone FTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/475Forum sharing protocol modifies state external to session2018-06-12T11:32:24ZakwizgranForum sharing protocol modifies state external to sessionSub-task of #456.
# Session identifiers
Each invitation session has the same identifier as the forum to which the invitation refers. There is one session per forum (and contact), regardless of how many times the parties share and l...Sub-task of #456.
# Session identifiers
Each invitation session has the same identifier as the forum to which the invitation refers. There is one session per forum (and contact), regardless of how many times the parties share and leave the forum.
# Messages
The sharing protocol uses five message types. It should be noted that all communication happens solely between the sharer and the contacts she invites.
**0: INVITE** - This is send by the sharer to one of her contacts. The content is a BDF list with these elements:
* `type` (int) The type of the message, here 0
* `previous_msg_id` (raw or null) is the identifier of the previous message sent by this party in this session, if any, which is a dependency.
* `group_descriptor` (list) a `BdfList` that makes up the group descriptor of the forum that is invited to with these elements:
* `forum_name` (string) name of the forum
* `forum_salt` (raw) salt to uniquely identify this forum
* `message` (string or null) optional invitation message
**1: ACCEPT** - This can be sent by contacts that received a sharing invitation and must be sent if they want to subscribe to the forum. The content is a BDF list with these elements:
* `type` (int) The type of the message, here 1
* `forum_id` (raw) The `GroupId` of the forum. It can be calculated from `forum_name` and `forum_salt`.
* `previous_msg_id` (raw or null) is the identifier of the previous message sent by this party in this session, if any, which is a dependency.
**2: DECLINE** - This can be sent by contacts that received a sharing invitation and do not want to add the forum. The content is a BDF list with these elements:
* `type` (int) The type of the message, here 2
* `forum_id` (raw) The `GroupId` of the forum. It can be calculated from `forum_name` and `forum_salt`.
* `previous_msg_id` (raw or null) is the identifier of the previous message sent by this party in this session, if any, which is a dependency.
**3: LEAVE** - Must be sent by a contact that is unsubscribing from the forum. The content is a BDF list with these elements:
* `type` (int) The type of the message, here 3
* `forum_id` (raw) The `GroupId` of the forum. It can be calculated from `forum_name` and `forum_salt`.
* `previous_msg_id` (raw) is the identifier of the previous message sent by this party in this session which is a dependency.
**4: ABORT** - This should be send by a contact that encountered an error, so that it can not complete the protocol. The content is a BDF list with these elements:
* `type` (int) The type of the message, here 4
* `forum_id` (raw) The `GroupId` of the forum. It can be calculated from `forum_name` and `forum_salt`.
* `previous_msg_id` (raw or null) is the identifier of the previous message sent by this party in this session, if any, which is a dependency.
# State Machine
![State Machine](https://code.briarproject.org/akwizgran/briar/uploads/7c45438c6f90e96422d8c8bff7275dcc/state-machine-2.png)Milestone FTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/472Forum: No message for the inviter if an invitee accepts or declines2018-06-12T11:32:24ZMegaloxForum: No message for the inviter if an invitee accepts or declinesA tester complained that he didn't get any feedback if his contact accepted or declined the invitation to a forum.A tester complained that he didn't get any feedback if his contact accepted or declined the invitation to a forum.Milestone CTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/471SHOW AVAILABLE FORUMS in speech bubble doesn't work.2018-06-12T11:32:24ZMegaloxSHOW AVAILABLE FORUMS in speech bubble doesn't work.Similar to #470: A gets invitations to the same forum from B and C. First she gets the invitation from B and accepts. In the private message (A-C) appears the system message SHOW AVAILABLE FORUMS. This can't be tapped and stays there.Similar to #470: A gets invitations to the same forum from B and C. First she gets the invitation from B and accepts. In the private message (A-C) appears the system message SHOW AVAILABLE FORUMS. This can't be tapped and stays there.Milestone CTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/470Second invitation doesn't disappear from available forums2018-06-12T11:32:24ZMegaloxSecond invitation doesn't disappear from available forumsA (A is already a member of the forum) gets invitations from B and C for the same forum. She accepts first B, when she accepts C she gets a toast but the entry in "available forums" doesn't disappear.
A (A is already a member of the forum) gets invitations from B and C for the same forum. She accepts first B, when she accepts C she gets a toast but the entry in "available forums" doesn't disappear.
Milestone CTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/468Migrate GitLab and Mattermost servers2018-06-12T11:32:25ZakwizgranMigrate GitLab and Mattermost serversSet up a new VM for GitLab, Mattermost and CI. Migrate the GitLab and Mattermost config and data.Set up a new VM for GitLab, Mattermost and CI. Migrate the GitLab and Mattermost config and data.Android Beta 2akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/465Add a strength indicator for forums2018-06-12T11:32:25Zstr4dAdd a strength indicator for forumsSplit out of #461 (see that issue for motivation):
> What might be useful is some kind of strength/reliability/meshing indicator for a forum (either shown in the titlebar, or on a separate about page) calculated from the available met...Split out of #461 (see that issue for motivation):
> What might be useful is some kind of strength/reliability/meshing indicator for a forum (either shown in the titlebar, or on a separate about page) calculated from the available metrics (how many contacts you are sharing the forum with, and for each of them how long it has been since you received forum messages synced from them - perhaps the last two sync times). I'm thinking of something along the lines of Stack Exchange's [Area 51 proposal commitment score](http://meta.stackexchange.com/questions/53650/area-51-commit-percent/53733#53733), where the commitment fraction of each user decays over time but is renewed when they visit the proposal again. In our case, we could design it so that when one contact is syncing daily or a few are syncing every few days it shows "good", while for only one contact that last synced a month it would show "poor" (and maybe a third intermediate "okay" level).https://code.briarproject.org/briar/briar/-/issues/462Development of a consistent onboarding strategy2018-06-12T11:32:25ZMegaloxDevelopment of a consistent onboarding strategyBecause of its serverless nature briar is different than other messaging/forum/blog apps. These differences need to be explained to the user.
A contextual onboarding has to be developed to help the user understand some of the features...Because of its serverless nature briar is different than other messaging/forum/blog apps. These differences need to be explained to the user.
A contextual onboarding has to be developed to help the user understand some of the features and peculiarities of the briar app.
Contextual onboarding is shown once a certain feature becomes relevant or a screen is shown the first time. In some cases it could be helpful to offer an option to reopen the onboarding again. This could be realised via infoicon (app bar).
This is an (incomplete) list of features which require onboarding (Please feel free to add points):
- Account is stored on device, password can't be recovered (current solution: explanation is shown in setup screen)
- Finding the contact screen (#344)
- Prompt to add first contact (current solution: dialog the first time the user signs in, empty state of contact list)
- Prompt to create first forum (current solution: empty state of forum list)
- Prompt to write first forum post (current solution: empty state of forum)
- Prompt to write first blog post (current solution: empty state of blog feed)
- Panic button settings (first time open, reopenable) (#349)
- Introduction feature (as soon as the user made her second contact) (#357, #358)
- Transports/connections
- Verification status indicators (first time a v.s.i. appears)
- Add contact via QR-code:
- One-on-one restriction (first time open, reopenable) (#348)
- Face-to-face restriction (current solution: explanation is shown in add contact screen, empty state of contact list) (#429)
- Connection failures (#71)
- Privacy properties of the app (#86, #315)Milestone Ehttps://code.briarproject.org/briar/briar/-/issues/461Forum Invitation Can Not be Accepted if Forum Already Added2018-06-12T11:32:25ZTorsten GroteForum Invitation Can Not be Accepted if Forum Already AddedWhen a user shares a forum with another user that already has this forum, the invitation can not be accepted and thus forum posts will only be received by the initial inviter.
This can be a problem if the initial inviter is not online...When a user shares a forum with another user that already has this forum, the invitation can not be accepted and thus forum posts will only be received by the initial inviter.
This can be a problem if the initial inviter is not online frequently or even deleted their account.
Ideally, invitations can be accepted by more than one person, so more people can share forums with each other making for a tighter mesh and faster sync of forum posts through the network.Milestone DTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/460Forum Posts not Synced if Forum was Re-Shared2018-06-12T11:32:25ZTorsten GroteForum Posts not Synced if Forum was Re-SharedWhile testing I noticed that if contacts delete each other and then re-add each other and share the same forum, both had shared earlier already, it seems that forum posts are no longer synchronized between them essentially creating a for...While testing I noticed that if contacts delete each other and then re-add each other and share the same forum, both had shared earlier already, it seems that forum posts are no longer synchronized between them essentially creating a fork of the forum.
We need a test for this and a fix.Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/459Add contact header too long2018-06-12T11:32:25ZErnir ErlingssonAdd contact header too longThe header in the add contact screen is too long, see screenshot below.
![step_header_issue](/uploads/bace12c0da9a5a9b853a8f6d6f410c51/step_header_issue.png)
We should always try to keep the header as concise as possible, here I be...The header in the add contact screen is too long, see screenshot below.
![step_header_issue](/uploads/bace12c0da9a5a9b853a8f6d6f410c51/step_header_issue.png)
We should always try to keep the header as concise as possible, here I believe the simplest would be to remove the step text from the header and put it into the screen itself. This will of course also change the QR scanning screen.
@Megalox How about adding page dots somwehere on the screen, and then retaining them in the QR scanning screen ?Milestone Dhttps://code.briarproject.org/briar/briar/-/issues/458Translate strings.xml into Icelandic2018-06-12T11:32:25ZErnir ErlingssonTranslate strings.xml into IcelandicSelf explanatorySelf explanatoryhttps://code.briarproject.org/briar/briar/-/issues/455Update Timestamps of Messages Every Minute2018-06-12T11:32:25ZTorsten GroteUpdate Timestamps of Messages Every MinuteWe now have relative timestamps in master after !235 was merged. Now we probably want to have a timer task that runs every minute and invalidates the dataset in the adapters, so that the times get updated while the user has the screen op...We now have relative timestamps in master after !235 was merged. Now we probably want to have a timer task that runs every minute and invalidates the dataset in the adapters, so that the times get updated while the user has the screen open.
Like the timestamp at the bottom of this message:
![device-2016-06-28-184748](/uploads/c082ac0f54b50c27f9a1c5ef8865998b/device-2016-06-28-184748.png)Milestone DTorsten GroteTorsten Grote