briar issueshttps://code.briarproject.org/briar/briar/-/issues2018-06-12T11:32:24Zhttps://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/482Store transport properties in metadata2017-12-15T15:04:27ZakwizgranStore transport properties in metadataStore the latest local and remote transport properties in metadata rather than iterating over all update messages whenever we need the latest properties.
Remote update messages can be deleted as soon as the properties have been extrac...Store the latest local and remote transport properties in metadata rather than iterating over all update messages whenever we need the latest properties.
Remote update messages can be deleted as soon as the properties have been extracted. When message receipt hooks have been implemented (#481), local update messages can be deleted as soon as the contact has received them.Android 1.0akwizgranakwizgranhttps://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/474Introduction protocol modifies state external to session2018-04-29T13:15:17ZakwizgranIntroduction protocol modifies state external to sessionSub-task of #456.Sub-task of #456.Android 1.0Torsten 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/467Migrate web, etherpad and email servers2018-08-24T17:51:52ZakwizgranMigrate web, etherpad and email serversSet up a new VM for web, etherpad and email. Migrate the web and etherpad servers from 213.108.108.22, preserving pad contents. Migrate the email and mailman servers from 66.228.56.76, preserving mailbox contents, list membership and lis...Set up a new VM for web, etherpad and email. Migrate the web and etherpad servers from 213.108.108.22, preserving pad contents. Migrate the email and mailman servers from 66.228.56.76, preserving mailbox contents, list membership and list archives.akwizgranakwizgranhttps://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/456Protocols Modify State External to Session2018-04-28T00:13:10ZTorsten GroteProtocols Modify State External to SessionThe fundamental issue is that the protocol modifies state that's external to the session. In the case of forum sharing, the external state is the list of forums and their visibility; in the case of introductions, it's the contact list. I...The fundamental issue is that the protocol modifies state that's external to the session. In the case of forum sharing, the external state is the list of forums and their visibility; in the case of introductions, it's the contact list. If multiple sessions can modify the same external state then we may have problems keeping the sessions consistent with the state and with each other.
When we first thought about sessions, I was thinking of the sequence of messages and the local state stored by the protocol - I didn't think about external state. That's also the reason the ProtocolEngine interface doesn't provide a way to update external state (#376). For any protocol that updates external state, such as the forum sharing and introduction protocols, we need to re-think what a session means.
I think we can solve this issue in the general case by saying that all sessions that affect the same external state must share the same session ID and local state. In other words, a single ongoing session per unit of external state. Then we need to design the state machine to allow for the fact that different parties may try to perform different operations within a given session, possibly at the same time. This will probably make the state machine more complex, but that's because the state machine now captures the possibility of multiple operations affecting the same state, whereas previously we just sort of crossed our fingers and hoped that didn't happen.
To put this in more concrete terms, the unit of external state for forum sharing is the visibility of a given forum to a given contact, so all sessions that affect the visibility of a given forum to a given contact should share the same session ID and local state. In particular, if a contact shares a forum with us and we simultaneously share the same forum with them, both sessions should use the same ID. When we receive their invitation we'll look up the session and discover that we're in the "invitation sent" state. We can then have a rule in the state machine that says what we should do if we receive an invitation in that state. For example, we might apply the Alice/Bob tie-breaker and ignore one of the invitations, or we might decide that we should react in the same way as if the contact had accepted our invitation. But the point is, the need to handle that situation is defined as part of the protocol.Android 1.0Torsten GroteTorsten Grotehttps://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