MSC4019: Encrypted event relationships #4019
Conversation
Signed-off-by: tusooa <tusooa@kazv.moe>
Signed-off-by: tusooa <tusooa@kazv.moe>
tusooa
changed the title
tusooa
force-pushed
the
tusooa/encrypted-relationships
branch
from
6c50199
to
4b7fb4d
Compare
Signed-off-by: tusooa <tusooa@kazv.moe>
tusooa
force-pushed
the
tusooa/encrypted-relationships
branch
from
4b7fb4d
to
6816a05
Compare
uhoreg
added
proposal
| ## Potential issues | ||
|
|
||
| According to the existing specs, clients might ignore the `m.relates_to` in the encrypted payload of | ||
| an event, causing rendering issues for them. Thus, clients that supports `m.room.relationship_encryption` | ||
| MAY send the `m.relates_to` in both the cleartext part and the encrypted payload for rooms that has this state event. | ||
| Clients that do so SHOULD inform their users of this, and SHOULD allow the users to choose whether they | ||
| want to send the `m.relates_to` in the cleartext part. |
There was a problem hiding this comment.
Obviously, server-side aggregations and the /relationships API will not work any more with this change.
These exist for a reason: clients are heavily reliant on them for things like finding the reactions and threads which relate to a particular event.
It seems to me that these are "Potential issues" which need discussing here.
There was a problem hiding this comment.
For my use case (1-to-1 chats and small groups of at most 10 people), aggregations from server side just do not help much. Most used relation is reply, second most editing, and tiny little bits of reactions. Reply and editing chains wouldn't be spanned across like 100s of events.
The sole purpose of this is to sacrifice the ability for the server to track relationships in order to achieve better privacy.
Made this explicit in the potential issues section.
There was a problem hiding this comment.
@richvdh A somewhat recent discussion in Client Dev Room revealed no matrix clients use aggregations for Reactions. If a client does nobody was able to present one in that conversation. (Date of Discussion is Feburary 21nd of 2023. According to Central European Summer Time.)
So the concern that Reactions would break is if that conversation was accurate incorrect for most users.
Due to that reactions wont break a MSC like this is safe to move forward for Reactions atleast if that conversation was accurate. As we are trying to prove a negative in this case its up to whoever wants to do the work to find a counterexample.
Edit: lets update this comment. So i dug up that MSC2677 and this specific comment is where the call is made that relations in the case of reactions are not aggregated and this PR to synapse removes the code from synapse in line with the MSC.
There was a problem hiding this comment.
that Relations specifically are not aggregated
I think you mean reactions.
There was a problem hiding this comment.
You're right, reactions are not aggregated, I'd forgotten. Nevertheless the concern remains around other relation types (especially edits).
There was a problem hiding this comment.
@clokep is correct about what i intended to communicate. And yes its a valid concern to be concerned about other relation types.
There was a problem hiding this comment.
The key field for reactions makes sense to encrypt in private conversations. However, I think that fields denoting the relationship itself should always be unencrypted. It doesn't help with just server aggregation. Bots and clients will have it way easier getting relevant events on demand rather than needing a full sync cached and searched through. It could be made the default and no extra toggle (m.room.relationship_encryption) would be needed; if a room is encrypted, all other relationship fields are stored inside the encrypted content, whereas the event_id and rel_type remain outside, unencrypted.
There was a problem hiding this comment.
The
keyfield for reactions makes sense to encrypt in private conversations. However, I think that fields denoting the relationship itself should always be unencrypted. It doesn't help with just server aggregation. Bots and clients will have it way easier getting relevant events on demand rather than needing a full sync cached and searched through. It could be made the default and no extra toggle (m.room.relationship_encryption) would be needed; if a room is encrypted, all other relationship fields are stored inside the encrypted content, whereas theevent_idandrel_typeremain outside, unencrypted.
I am talking about the possibility for clients to not rely on servers to keep record of event relationships. And it's optional. Clients that do want to rely on servers can simply not support it.
|
Regarding implementation, libkazv currently sends all outbound relations encrypted in encrypted rooms. |
Rendered