MSC3122: Deprecate starting verifications without requesting first #3122
Conversation
uhoreg
changed the title
uhoreg
added
kind:maintenance
| not provide a good user experience, and allowing this adds unnecessary | ||
| complexity to implementations. | ||
|
|
||
| We propose to deprecate allowing this behaviour. |
There was a problem hiding this comment.
Yes please! This is one thing that tripped me up a lot when implementing it, since Element either sends request or start. It would make this a lot easier to implement for new clients and allow me to clean out some cruft! It adds a few extra branches to already a complex state machine, not having things start with start would allow me to clean up stuff like this in the future: https://github.com/Nheko-Reborn/nheko/blob/a6c89d13622907e4c4bf8464fc54fd6e98b62b0a/src/DeviceVerificationFlow.cpp#L468 and would be much easier to test then, because you need half as many test cases.
|
@mscbot fcp merge |
|
Team member @uhoreg has proposed to merge this. The next step is review by the rest of the tagged people: Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for information about what commands tagged team members can give me. |
mscbot
added
disposition-merge
proposed-final-comment-period
proposals/3122-deprecate-starting-verifications-without-request.md
Outdated
Show resolved
Hide resolved
…t.md Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
| verifications in this way, but will still need to accept verifications begun in | ||
| this way, until it is removed from the spec. |
There was a problem hiding this comment.
I'm not sure this actually changes much at the spec level, given everyone will still have to support it :/.
still, not much else we can do, I guess.
There was a problem hiding this comment.
It at least discourages new implementations from implementing it and in practice, it is only element still doing requests without request. So if a client dev doesn't care for old Element versions, they can drop it. Considering that you probably want to have a secure client anyway, you shouldn't be running very old versions of any client anyway, if you are trying to verify someone securely. Considering that, I feel like this could actually be removed from the spec somewhat soonish, like in a year for example.
There was a problem hiding this comment.
Yeah, the goal is to eventually remove it from the spec. Currently, Element is the only client that does it, and only in one specific spot, which I hope to remove soonish. So probably a year or two after it gets removed from Element, it should probably be safe to drop from the spec.
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
mscbot
added
final-comment-period
|
The final comment period, with a disposition to merge, as per the review above, is now complete. |
mscbot
added
finished-final-comment-period
and removed
disposition-merge
final-comment-period
turt2live
added
spec-pr-missing
richvdh
moved this from Ready for FCP ticks
to Done to some definition
in Spec Core Team Backlog
uhoreg
added
merged
|
Merged! 🎉 |
MSC3122: Deprecate starting verifications without requesting first
MSC3122: Deprecate starting verifications without requesting first
The old verification methods start a verification by sending an `m.key.verification.start` message, rather than an `m.key.verification.request` message. This behaviour is deprecated in the spec (matrix-org/matrix-spec-proposals#3122), so these functions should be deprecated too.
The old verification methods start a verification by sending an `m.key.verification.start` message, rather than an `m.key.verification.request` message. This behaviour is deprecated in the spec (matrix-org/matrix-spec-proposals#3122), so these functions should be deprecated too.
Rendered