react-sdk branch: bwindels/verification-right-panel
js-sdk branch: bwindels/verification-ready

some notes of current state:

• DONEISH: support .ready event

• replace KeyVerificationStateObserver with VerificationRequest

  • DONE-ISH: in MKeyVerificationRequest
  • in MKeyVerificationConclusion
  • in VerificationToast

• DONE: introduce new phase and panel to right panel

• DONE: navigation to open request in side panel

  • listen for for show_verification_request in MatrixChat
  • show right panel if collapsedRhs
  • emit view_right_panel_phase with new phase

• implement component for side panel

• Room.timeline is not fired for every event in the store upon refresh, duh. So what does this mean for restoring toasts when reloading? Note that this is not a requirement though ...

• wrt to VerificationRequest, sometimes we set an event reference on remote echo, but we already change the phase when sending the event. We should have a consistent approach to this so we don't get it wrong.

• only validated verification events should be displayed in the timeline ... if we don't check timeout in validateEvent and allow all verif events to create requests independent from their age, we can probably make this work. We can mark the request as timed out and not create a verifier and not send any events, but still allow the state machine to update with incoming events.

• while testing, I get the following errors:

  • send a request from chrome
  • click accept in ff, sends .ready event
  • the code in the DeviceVerifyDialog gets the verifier through beginKeyVerif and sends .start event (should verify this)
  • the remove echo of the start event tries to create a verifier and fails because it can't find out who it is directed to (can't determine who the verifier should be targeted at. No .request or .start event and no targetDevice)
  • questions:
    • why doesn't it use the ready event that was cached?
    • why isn't the verifier set earlier? verifier should always be defined while in phase start

the notes above are stale and should be (mostly) ignored ^

@bwindels Is this safe to close then, since we've got other tickets for the remaining work?

(@bwindels says yes.)