MSC2285: Private read receipts#2285
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
…den read receipts.
…den read receipts.
There was a problem hiding this comment.
On a HS that doesn't implement this MSC (yet), if a user were to 'disable' read receipts (ie. tell their client to make them hidden), it would silently fail to do as the user requested, because the HS would not recognize the flag.
This should probably at least be listed under the security considerations as a 'fail open' case, or ideally be resolved - maybe through a feature flag of some sort that explicitly indicates to the client that this feature is supported? Or if this will be a required part of the spec in a next version of the protocol, the spec should probably clearly indicate that this feature only exists since that particular version (so that clients know not to offer the feature on lower protocol versions).
Edit: Not really a 'nit', I suppose. Edited accordingly.
|
@joepie91 in general, please use line comments so conversation isn't lost. However, I hope i can respond in one comment here: This is already partially identified in the security considerations section (if you swap out "ignore" for "unaware", at least). The expectation is that this lands in a version of the specification, which is where the MUST takes effect - servers would be non-compliant if they ignored the flag and advertised that they supported the version. |
|
@mscbot fcp merge |
This comment has been minimized.
This comment has been minimized.
mscbot
added
proposed-final-comment-period
|
@turt2live I was hoping that the 'review' feature would produce a thread like a line comment would (since this is a general comment, not tied to a specific line), but apparently not :) Given that it's a MUST, I would propose explicitly adding a note to the spec that says "this flag did not exist before version X of the spec, and all read receipts are assumed to be visible there", so that clients which implement multiple spec versions (retroactively) can take this into account in how they design their UI. I'm not sure whether such an "add note to the spec" point would be part of the MSC itself, or tracked separately. |
|
It would be done at spec PR time - MSCs generally don't try and influence the exact wording of the spec given they are more informal documents than the formal spec. |
|
@mscbot concern There should be an account data config option for this so clients can honour it always. |
|
I'm cancelling FCP on this because I don't think it's ready for that yet, and I want to add a few more things to it: @mscbot fcp cancel |
|
@turt2live proposal cancelled. |
mscbot
removed
proposed-final-comment-period
turt2live
changed the title
mscbot
removed
the
unresolved-concerns
Co-authored-by: Kévin Commaille <76261501+zecakeh@users.noreply.github.com>
|
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
|
Spec PR: matrix-org/matrix-spec#1216 |
|
Merged 🎉 |
|
Do you know if there's any issue to watch, regarding getting this MSC supported in Elerment (Android/iOS/web)? |
It's already implemented in Element Web/Desktop, for Android and iOS: element-hq/element-android#2436 and element-hq/element-ios#4646 respectively |
|
Oh, freaking sweet! This feature was the last blocker before rolling out my Synapse server. Super happy it's already in Element, too! |
20 participants
Rendered
Author: @SimonBrandner
synapse
matrix-js-sdk
matrix-react-sdk
FCP Comment