Conversation
Signed-off-by: Jason Volk <jason@zemos.net>
turt2live
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Client
- Server
| It is possible to add an `account_data` field to the v1.15 § | ||
| [10.11.1](https://spec.matrix.org/v1.15/client-server-api/#get_matrixclientv3devices) | ||
| response's `Device` object as a convenience, but that will not be | ||
| mandated by this proposal without feedback. |
There was a problem hiding this comment.
Devices can already have metadata https://spec.matrix.org/v1.15/client-server-api/#put_matrixclientv3devicesdeviceid, why not add fields to that mechanism rather than adding a new one? The example use cases seem like they'd fit in device metadata just fine
There was a problem hiding this comment.
If the semantics of the metadata are satisfactory (and appear so) we could just pivot this MSC to minimally replace #4292 by specifying supported_room_versions as another metadata field, and maybe client_version for fun.
Metadata isn't a granular key-store though, but it doesn't seem hard to extend those endpoints with another path component e.g. GET /_matrix/client/v3/devices/{deviceId}/display_name which would basically supersede the full functionality of the Account Data approach. This might be mission-creep though.
There was a problem hiding this comment.
Another alternative is a little more radical: deprecate the device metadata suite itself in favor of Device Account Data which has resemblance to other Account Data. One thing missing from the existing proposal is the fact that account_data should come down through /sync which other devices can react to. AFAIK not possible with device metadata?
There was a problem hiding this comment.
This appears to be missing the potential issues, alternatives and security considerations sections
| - Client software version identifier. | ||
| - Encryption metadatas. | ||
|
|
||
| ## Client-server endpoints |
There was a problem hiding this comment.
Does the device account data get deleted when the device is logged out?
| similar characteristics as the other two but with a `device_id` | ||
| division. Device Account Data acts as an arbitrary server-side | ||
| key+value store for each of a user's devices. Writes to this store are | ||
| only permitted by the device with a matching `device_id`. Reads from |
There was a problem hiding this comment.
If any of the user's devices is allowed to write to any other device's account data, it could be used for things like MSC3890 (and, in fact, that MSC calls out per-device account data as an alternative).
There was a problem hiding this comment.
The same-device-writer clause is intended to prevent ABA issues out-of-the-box. The cited case is certainly compelling though. I think a solution would be to allow type-specific semantics, but defaulting to the proposed same-device-writer if the type doesn't specify otherwise. In many cases a single-writer can be specified to mitigate ABA's just as well, even if that single-writer isn't the same device.
Add updates via /sync semantic. Add alternatives, security considerations, potential issues sections. Fix trailing whitespace errors.
jevolk
force-pushed
the
device-account-data
branch
from
046199c to
5189c27
Compare
4 participants
rendered