MSC4441: Encrypted User Profile Annotations via Account Data#4441
MSC4441: Encrypted User Profile Annotations via Account Data#4441thetayloredman wants to merge 4 commits into
Conversation
tulir
added
e2e
proposal
There was a problem hiding this comment.
Implementation requirements:
- Client (creating annotations)
- Client (rendering annotations)
github-project-automation
Bot
moved this to Tracking for review
in Spec Core Team Workflow
turt2live
moved this from Tracking for review
to Ready for general review
in Spec Core Team Workflow
|
The author would like review of this MSC prior to implementation, especially around crypto. See https://matrix.to/#/!0KNSXYXB_2xtEUkQ9MGBRy5oNIOfAKoq2uIqPZCJbI8/$Zss0QZ3VKtAqDlOCj4oBD2U7EO3UWVSgQ5xX3DuXe0Y?via=element.io&via=matrix.org&via=codestorm.net |
|
This may also benefit from the attempts at solving RMW races in #4438. The addition of an ADK for encrypting account data could also potentially benefit that MSC and could potentially be factored out into a separate proposal? |
| Rather than using `account_data`, a new dedicated endpoint for annotations would be created. Rejected because it | ||
| requires substantial serverside changes, this MSC aims to be entirely clintside. | ||
|
|
||
| #### Encrypt the entire event as one blob |
There was a problem hiding this comment.
If the contents of each item are encrypted separately, how does storing all items in a single account data entry compare to using one account data entry per item (with a common prefix)?
There was a problem hiding this comment.
That could definitely be considered. It would reduce the risk of a data race, however my concerns would be:
- There is existing precedent for keeping it together, e.g. in
m.direct. - How well do homeservers handle lots and lots of account_data events?
Room annotations could use a different implementation via room account data and are out of scope for this MSC. Via review.
4 participants
Rendered
Implementations: