Improving federation of profile updates

Features and Ideas
1

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.

2

Uh, changing GUIDs would be a big mess, and probably would break federation completely. A GUID is unique and does never change. You can always identify a profile with that GUID and you don’t just suddenly have the same profile with different GUIDs.

Also, it wouldn’t really fix the problem: Federation of profiles work the same way as federation of posts. They are retried the same amount of times and it usually works pretty stable. Since it works the same way as for posts, it also reaches the same pods … every pod you have a contact on. Every other pod doesn’t get the update. So it’s pretty reliable which pods get they updates, it’s not a retry problem, either a pod gets the update, or it doesn’t get it, but then not even once (so it’s not a retry problem).

I already prepared to solve this problem in #79 but didn’t have the time to build the second part yet. But the plan is, to not only send profile updates to your contacts, it should be sent to every known pod. That way the profile should be updated on every pod, even on pods where only somebody searched for your profile some years ago.

3

Thanks for your quick reply.

Sorry, I should have been clearer. I’m talking about appending something to the guid, not changing the guid itself. That’s what I preceded the extra digit with a hyphen, so that any pod running the up-to-date code would know to strip out the hyphen and take the part of the string to the left as the guid and the digit to the right as the profile update digit. (Without using a hyphen, any guid from a pod that hadn’t updated to the code version implementing this would be broken.)

It’s something that support for which would have to be built in to one version and then implementation of the new ‘guid-plus’ strings introduced in a later version, once all pods had had chance to update to at least support this; otherwise guids with a hyphen and extra digit would break things, yes.

The alternative would be to add a new field to federated data: profile_version or similar, but that would involve sending a lot more data with each interaction, so I thought appending a digit to an already sent field would be more efficient.

My method might be incorrect, so perhaps I should stick to the general idea, which is to include some notification of profile ‘version’ in all federated data relating to an account, not only as a separate profile update push, which if missed could stay outdated for years, until the next profile update is made.

But if, as you say, it’s not a problem of updates being missed by some pods that should have received them but of updates not being sent to many pods because there is no sharing relationship between the account and one on the receiving pod, perhaps mine is not the best approach.

I still quite like the fact of an indication of update profile being included in all federated data, because if a profile update isn’t federated to a pod, that out of date information would be perpetuated on all posts involving that account, which is more serious that missing a single post or comment.

Hope that makes sense.

4

Since a hyphen is a valid sign in the GUID and socialhome already has hyphens in GUIDs, it would automatically be part of the GUID when parsed. It would also break federation with every other project compatible with the diaspora protocol at the moment.

An additional field would work better, but for comments it would need to also be included in the relayable signature mechanism which would make the signature that needs to be stored bigger and it can’t be changed, because that would invalidate the signature. So when fetching an old entity with a different profile version that would always be outdated.

But as said, it’s not a retry problem, it’s just not sent to all pods at the moment. So lets change that first and then see if there still is a problem, but the situation should improve a lot by this.

5

Darn it, I somehow knew my idea wouldn’t be useful. Thanks for your patient explanation, and it’s great to know that you have a proper solution in hand.

1 Like
6

But as said, it’s not a retry problem, it’s just not sent to all pods at the moment. So lets change that first and then see if there still is a problem, but the situation should improve a lot by this.

So could it be as simple as the profile has an update time and they do a simple check against their respective update times before rendering and deciding, “Nope I have an old copy so let me get a new one”?

7

No, checking to the remote pod before every render would be slow and probably DDoS some smaller pods, so it wouldn’t be a good idea to do that (and if you would want to check every time you could just check if your data is up to date and not just compare a date).

8

I think Hank meant to add a ‘profile update time’ field to the metadata attached to each post/comment, in the same way I suggested a ‘version’ digit. The receiving pod checks the ‘profile update time’ in the received metadata against their local copy for that account, and pulls profile data if the times don’t match.

That way the information would be included each time something had to get federated anyway, rather than sending additional update notifications.

9

2 posts were split to a new topic: Questions about how federation works