Profiles don't federate properly across pods

[DeadSuperHero]

There seems to be an issue with profiles federating across pods. Profile pictures that are changed on one pod remain unchanged on another, nicknames don't change, and recent comments on a status can become completely invisible when viewed on a profile.

The problem boils down to:

-Username changes -User profile picture -Comments in statuses

According to David Morley of Diasp.org, it appears that profile updates themselves appear to be broken.

[dmorley]

this bug gets opened and then closed all the time as works for me. I can confirm that https://joindiaspora.com/people/4d0564183dac139f3d0008e0 displays a photo from > 1 year ago and a bio from > 1 year ago.

[dmorley]

I should have been more clear, both are >1 year ago and I update my photo weeklyish and bio monthlyish and none have ever updated that profile.

[addtest]

From joindiaspora.com and ilikefreedom.org I can see two different versions of an account on diasp.org, neither of which reflects reality, in the sense that the account on diasp.org has a different nick, picture and the posts on which I am able to comment from the other two pods no longer exist for quite some time.

It is amazing how I am able to search on joindiaspora for a certain tag and find posts that are no longer on the original profile and even comment on them, pin them and so forth. I really feel that this is a very big privacy flaw.

In addition to that, if that particular account on diasp.org adds new posts, they will appear on joindiaspora and ilikefreedom under different old nicknames and with an old picture (on ilikefreedom) or without a profile picture at all (on joindiaspora).

What is even more mind boggling is that the one profile on diasp.org, has the nickname that was first used on ilikefreedom and since then changed for a bunch of times and that was never used on diasp,org in the first place.

For example:

1. I create an account on ilikefreedom with the handle firstname@ilikefreedom.org and the nickname andrew stevens. I later change that nickname to whatever.
2. I create an account on diasp.org with the handle shorterfirstname@diasp.org and as a nickname I use johndoe.

Question: how is it possible that when I search from joindiaspora.com for shorterfirstname@diasp.org I find an account with the nick andrew stevens (instead of johndoe, the actual nickname), since andrew stevens was never used as a nickname on diasp.org in the first place? Why do posts added from diasp.org appear under different nicknames (that I don't want to use anymore due to privacy reasons) when searched from joindiaspora or ilikefreedom? Why do deleted posts still appear on the streams of other pods with people being able to comment on them, and how can they be deleted? The pod admin of that particular pod (diasp.org) told me that indeed the profiles update seems broken.

There are also problems while searching from diasp.org for posts and being able to see only some of the comments posted from accounts on joindiaspora.com. If I have to I can also provide admins with the real handles and nicknames that were used.

Thanks and sorry for the long comment. Hope this helps somehow.

[maxwell]

logs from the federation logger from both sides would be really helpful

[maxwell]

the bio seems to work for me in the dev enviroment :/

[dmorley]

the last time this came up we were able to figure out that it was just the old old account with the issue. maybe it would be worth taking the data from 4d0564183dac139f3d0008e0 and see if it has some snafu that a new user account would not have?

[maxwell]

@addtest does that mean only the name was updated in the federation?

[maxwell]

Ok thanks for the info.

There is actually two bugs here. One, that you current pod should not display the posts from disabled accounts on your profile page.

This state exists so that no posts should be shown in the time it takes to get the deletion request, and the time it takes the pod to delete them.

Second, something is up with the account deleter phase. Luckily, this is something that can be re-requested from you home pod, once we fix the pods.

Having you help with federation testing (http://groups.google.com/group/diaspora-dev/browse_thread/thread/a0777f10ba900272) would help us in ironing them out ASAP

[addtest]

Thanks for your reply. I feel I should mention that none of the above accounts are actually deleted/disabled. They are both active (on different pods), but currently have 0 posts.

[maxwell]

@addtest, so you are saying your problem has nothing to do with the bug posted?

[addtest]

@maxwell My problem has everything to do with the bug posted

"There seems to be an issue with profiles federating across pods. Profile pictures that are changed on one pod remain unchanged on another, nicknames don't change, and recent comments on a status can become completely invisible when viewed on a profile. "

I've just given you two links of profiles searched from within joindiaspora that are changed on their original respective pods (ilikefreedom.org and diasp.org), but remain unchanged on other pods. Neither of them is closed and they do not contain any posts anymore.

[maxwell]

This would be about post deletions failing under certain circumstances, which is a different bug. The profiles are just the meta data about the person.

[rivendale2010]

i recently had an issue which i'd like to mention here, not sure if it is related :)

if you have a situation where your pod is sending a user profile when you make contact, and then never sending updates

it can be caused by the URL value in the PEOPLE table being initialized to http instead of https (this possibly related to the legacy SSL in the PODS table, don't know)

anyway, depending on the setup of the remote pod, that can sometimes prevent sending updates

i mention because i did notice that ilikefreedom.org was one of the URLs i had the problem with here :) my pod kept trying to PUT stuff there via http

by changing my PODS table to make SSL=1 for ilikefreedom.org, and running an SQL script on PEOPLE table to change all the URL values from http to https for ilikefreedom.org, the problem was fixed :)

[Flaburgan]

This one is fixed with https://github.com/diaspora/diaspora/issues/3976 isn't it?

[jhass]

It might have improved the situation, we yet have to see if we can consider it as "fixed".

[rivendale2010]

i still have many 'people' with outdated profiles, they are not contacts just profiles for people

i assume that unless i have some sharing with them the remote pod has no queuing to send me any updates, they do not come with a post

it does now update with a share notification now however :)

[polsvoice]

My diasp.org account has friended my JoinDiaspora account. I changed the JD display name and picture, and I could see both changes in my d.o account fairly quickly. On the other hand, I changed display name and picture for the d.o account, and I could see the picture change in my JD account, but NOT the name (and it's >24 hours).

[cmrd-senya]

I'm replying here to this comment of @SuperTux88: https://github.com/diaspora/diaspora_federation/pull/79#issuecomment-328365000 (in order to avoid off-topic discusiion at https://github.com/diaspora/diaspora_federation/pull/79)

And then? What should the pod do? Delete the profile? That's not possible if there are already posts/comments with this profile. Or remove name and avatar and use diaspora ID and default avatar instead? Then we should change WebFinger to never include a name or an avatar, because when a pod fetches a profile with WebFinger the profile will never be updated too and the pod will never receive a Retraction.

If pod fetches profile and never received a Profile "push" then it'll likely not to have updates as well. So I guess that if we never received a profile "push" or if we receive a profile retraction then we shouldn't render basic details as well. Person may have changed the name and doesn't want the old name to be rendered anywhere, even if someone has WebFinger-fetched the profile before. Of course we don't have a control over every software that does it ever, but it is a nice behavior for diaspora to respect user's name change ability and not to show it if we don't have some "proof" that we'll receive updates. We can count that we will have updates if:

• The profile was pushed at least once
• We didn't receive a profile retraction.

So we can just add a flag to the profile model which tells if we are allowed to show basic properties or not. Or just have the basic fields empty unless we expect the updates (if that is possible at all).

I think many users expect that they don't see their old name if they have changed it and we can see complains about it so I guess what I propose is actually an acceptable solution.

What do you think?

[SuperTux88]

I think many users expect that they don't see their old name if they have changed it and we can see complains about it so I guess what I propose is actually an acceptable solution.

If you put something publicly in the internet you can't control it anymore. Even when we hide the details everywhere, it's still available on old pods, other software fetched the profile via WebFinger or it's maybe also saved in the waybackmachine or somewhere else.

Pushing searchable profiles to all known pods will already improve the situation very much, lets see if that's enough or if we need to do more.

There are still open questions:

• do we delete the data when receiving a Retraction (and don't save data at all when WebFingering new profiles), or do we keep them and just not display them?
• What happens when somebody on that pod searches or visits the profile (depending on the question above): When we have the data, do we display the data we have saved? Or do we need to WebFinger the profile everytime?

The easiest solution would be to not make any data available publicly when searchable is false (but this would end up in some profiles without data in posts and comments, so it's probably not what users want too), but once this was true, you can't go back.

There will never be a 100% solution for this, again everything that's publicly in the internet is in the internet, you have no full control about it anymore. Pushing searchable profiles will already improve the situation by 80% with a really simple solution. Then we can decide if it's worth to add a lot of complexity to push it to 95%.

For now I'm for starting with the simple 80% solution and then see if it's really needed and if it's worth to multiply the complexity and do the 95% solution, but since it's still not 100% then I don't think it's worth it.

[cmrd-senya]

If you put something publicly in the internet you can't control it anymore.

According to this logic we don't have to retract public posts like we do now.

For post retraction we rely on pods being nice, so I don't see why we can't do that here.

Also, we'll have exactly the same problems with posts when we introduce editing.

Maybe instead of (or along with) deciding where do we push the updates we can allow subscribing on profile (and maybe posts) updates as well? E.g. a pod fetches a WebFinger profile and subscribes itself for updates, so even if it is non-searchable we push basic data to this pod (like if there were some contacts there even if there aren't). I guess that what we will eventually have to do for posts (and we already discussed this per-pod subscription for public posts at #6726), so why not do the same thing for profiles?

[SuperTux88]

According to this logic we don't have to retract public posts like we do now.

Yes, especially when the pod has enabled to send everything to the relay, you can't delete it everywhere anymore, because you don't have control about it (that's one reason why I didn't activate the relay on my pod yet). If you don't use the relay, you can probably delete it again, if you delete it fast. After somebody reshared it, you probably can't delete it either ... subscribing to received posts will fix this, but that's offtopic here.

Also, we'll have exactly the same problems with posts when we introduce editing.

What do you mean with same problem? That the edit doesn't reach all pods? Yes, but subscribing to posts will fix that (which I want to do first).

Maybe instead of (or along with) deciding where do we push the updates we can allow subscribing on profile (and maybe posts) updates as well?

Yes, that's a possibility, but we don't have the structure to subscribe to profiles yet. For the beginning it's probably enough to continue sending it to every pod after we did that once (because after that every pod would be subscribed anyway). So when searchable was true once (and profile was sent once with this setting, so we need a new flag if the profile was sent to everybody once), keep sending profiles to everybody even when the user sets it to false.

I also would prefer a message with searchable set to false instead of a Retraction, because that is also understood from old pods and other software and they set the searchable flag to the correct state. And that would be the case anyway, if we continue sending it to everybody after we sent it to everybody once. So I don't think we need a Retraction for profiles, we can just use the searchable flag for that.

[goobertron]

For now I'm for starting with the simple 80% solution and then see if it's really needed and if it's worth to multiply the complexity and do the 95% solution, but since it's still not 100% then I don't think it's worth it.

This sounds like a good solution to me. There are two slightly separate issues here:

• a user's 'right' to have their public data the way they want it everywhere on the internet at any point in time;
• changing profile data wherever it can be changed when a user updates their profile.

It seems worth making an attempt to do the second – at least to improve the situation as much as is feasible – even though the first is impossible.

[yurkobb]

An live example of this bug: notice that here the 6-th comment is shown as being written by "setThemFree" while over here the same comment appears as being written by "Yury Bulka". They both refer to my account on diasp.eu (where the first link is rendered), however "setThemFree" is the current name of the account for already quite some time (a year?) while "Yury Bulka" was the name I used when initially creating the account.

I noticed this because I was mentioned in the thread by the old name of the account.

[goobertron]

I'd forgotten about this ticket. This issue came up again this week in this post (with another live example); this time with someone's bio and location not being visible on some pods. The reason suggested by SuperTux is that parts of the extended profile was only made (optionally) public some time ago, and the fact of this information being public hasn't federated to all pods. Likely related to the same underlying issue, though.