I’ve been thinking about this over the past few days. Although the federation performance is infinitely better than it was a few years ago, profile updates (screen name, avatar, bio and other information) still fail to federate to some pods in some instances; and, when this happens, those updates may never get made on the remote pod.
I’m not sure how profile updates are currently federated, but it seems that if the notification doesn’t get through first time, it’s not retried; or at least, not often or for long enough to be reliably federated to all pods.
I’ve been thinking about a different approach, which I hope might be workable and help to improve this.
My idea is to append a digit to the account guid, which is changed each time a profile is updated.
For instance, the guid for my account when created is [guid]-0. When I make a profile update, this is changed to [guid]-1. (When it reaches f – I’m assuming a hex digit – it will return to 0 on the next update.)
As the account guid is (I assume) part of the information federated with each user action (post/comment etc), a receiving pod that had missed the initial update notification would know when it received any action from that account that there has been a profile update that it missed, because the guid attached to the data is [guid]-1 rather than the record for this account in its database, [guid]-0. It can therefore request the updated profile information.
I don’t think there’s any necessity for this addition to the guid to be unique to each update. In the unlikely case that someone has made 16 profile updates since a remote pod last had any information federated from that account, it’s likely that that person will update again soon and thus the profile can be pulled by the remote pod then. For that reason, it shouldn’t add too much to server load or traffic to add this single digit.
It might be better to include a new field in the federated data for this ‘update’ digit; I leave that up to you technical wizards to decide!
Hope this is useful.