Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
briar
briar
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 678
    • Issues 678
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 11
    • Merge Requests 11
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • briar
  • briarbriar
  • Issues
  • #295

Closed
Open
Opened Apr 13, 2016 by Torsten Grote@groteOwner
  • Report abuse
  • New issue
Report abuse New issue

Handle Declined Introductions

At the moment, introducees are not informed about the other's response. When both accept, they get a notification about that.

However, when Alice declines first, Bob's backend gets the response, so it knows that the protocol has completed. In this case, Bob's response will not be forwarded to Alice whether positive or negative.

This violates our principle that information available in the backend should also be shown to the user so that the user understands what information she's potentially exposing to other users, who may be using different frontends.

So I essentially see two options to solve this:

  1. Show all responses to the user
  2. Do not forward negative responses to the introducees

The first option poses some UX challenge as it is not clear how the response of a contact we do not yet have should be shown. It is also an open question whether responses should always be forwarded. This would require introducing additional protocol states.

The second option would be less work to implement. The only problem is that the session of the introducee who was declined would forever stay "open" (if she accepts herself) and wait for a response that never comes. Since we are not deleting sessions anyway, that would be fine.

Assignee
Assign to
Milestone B
Milestone
Milestone B (Past due)
Assign milestone
Time tracking
None
Due date
None
Reference: briar/briar#295