User search: profile replication from HS #56
Conversation
Although with zero verification yet
|
|
||
| bad_uids = [] | ||
| for uid, info in batch.items(): | ||
| if 'display_name' not in info or 'avatar_url' not in info: |
There was a problem hiding this comment.
I'm slightly surprised we don't just ignore malformed profile updates? Especially as it's presumably quite common for only one of display_name or avatar_url to be updated, so it might feel reasonable to skip the other field?
There was a problem hiding this comment.
Yeah, it does feel like unchanged fields could be omitted (not that synapse would know how) but this would apply moreso if we had extensible profiles. It would make for some slightly more complex SQL on sydent.
|
this generally lgtm, although i'm slightly surprised that we're having to synthesise and track our batch IDs on both client and server like this, and I'm a bit scared about what happens if a sending HS implementation finds it hard to generate monotonically increasing IDs, or if the HS drops its DB and then has no way of knowing how to restart the sync process? |
So the sender doesn't have to generate exactly sequential batches.
|
Good point, and I realised that synapse as is could easily skip batch numbers if someone updated their profile twice in quick succession. I've made sydent accept any batch number greater than the previous, which hopefully loosens the requirements on senders a bit. If the HS drops its db, everything probably needs to start from scratch anyway since it presumably wouldn't know what data the target doesn't have either. |
Accept profile replication push from the HS and save profile data to the database.
NB. This is missing the signature verification that validates the HS is who it says it is