Conversation
anoadragon453
changed the title
anoadragon453
force-pushed
the
anoa/legacy_sync_profile_updates
branch
from
82ac3a7 to
3b205f6
Compare
anoadragon453
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Client (using)
- Server (sending)
There was a problem hiding this comment.
| and compare that against an identifier stored within the provided `since` token | ||
| to know whether a client has yet to receive a given profile update. | ||
|
|
||
| ### Clients |
There was a problem hiding this comment.
How do clients know when to expire the stored cache of profile updates? If the user deletes a profile key, do we get that down sync? (Covered by null above) If another user leaves the scope of the authenticated user, can the homeserver notify that we are no longer interested in the keys for that user?
There was a problem hiding this comment.
Good point. If a user leaves all rooms that you share with them, then it would make sense for homeservers to inform clients of that.
And as you suggested in DM, it would be nice to be able to send:
{
"users": {
"@leftdude:example.org": {
"profile_updates": null
}
}
}
down /sync in order to indicate that all profile fields should be forgotten by the client.
4 participants
Rendered
Conflict of Interest declaration: I am employed by Element. This MSC was written as part of my work on the Element Backend Team to land a "user status" feature (based on top of custom profiles, see MSC4426) for a customer.