Remove the need for the user relation extensions in statuses

These are only used by PleromaFE and slow things down a lot

mentioned in issue pleroma-meta#33

how do we handle situations where user following status isn't known beforehand? fetch relation data for every profile open?

Fetching relationships for every profile card/profile page on open seems fine to me

Note that the statuses rendered for notifications (mention / favourite / reblog / pleroma:emoji_reaction) would also be optimized to not contain relationships. Pl. report any foreseen issues with that.

Upd.: I'm handling back-end part for this functionality. It'd be good if FE could start with sending with_relationships=true for all status / notification listing routes where FE currently relies on relationships to be present. Then we could bundle such FE revision with BE supporting that parameter, and once FE supports relationships-less operation it could stop sending this parameter with no further changes in BE.

Related issue — current PleromaFE needs relationships-related fixes anyways: #820 (closed)

seems to be a problem with newer version of backend, can't reproduce on older version

Fixed in pleroma!2347 (merged).

Btw, this issue demonstrates that relation data is already fetched by PleromaFE for every profile open (it's calling /accounts/relationships?id=<single_id> which was returning incorrect result due to a typo in preloading code). So, there should be no need in account/pleroma/relationship data for every status rendered anyways (yet FE need to be adjusted to switch from using this data).

FE needs to handle the case when relationship isn't present at all, and prevent jumpy UI when data does appear.

Right. In the video recorded for the above issue (#820 (closed)) a proper relationship map is delivered for status but when user clicks on status actor, /accounts/relationships?id=... is requested and it mistakenly yields conflicting data, then we observe the "jump" from initial data to /accounts/relationships then to initial (status-embedded) data (!), and that's weird — /accounts/relationships data should have been displayed but it's not happening on the first visit to profile (only when the profile is visited again, as shown in video).

anything could happen because FE unconditionally updates statuses and users when new data is processed (see also #793) and IIRC it doesn't have any checks if field is missing or not. It also has a leftover bit of code that fetches relationship on profile open.

so there's:

• user data in each status
• user data in user profile
• user relationship data in leftover relationship request

data processing order might change since requests response time may vary or other asynchronicity weirdness.

This creates a weird problem: We can display user profile even before we request data for user profile, but if we don't know the relationships yet we need to display something instead of follow/mute buttons and also redesign "follows you!" label entirely. We also need to track if missing relationship is expected situation (user logged out) or unexpected (it was missing in status data)

all of this is the reason why relationship data was embedded even in statuses in the first place - significantly added complexity to UI in all the wrong places

I'm trying to look into it and I don't really see the relationship stuff used much outside of usercard/profile and various lists of users. Am I missing something?

If it's like this, then it wouldn't be too hard to change the UI to not rely on relationships in users in statuses, as long as we can still get accounts with relationships in follow/follower lists etc.

@shpuld we maintain a "known users" store in FE based on any user data, which includes status data. It also sorta expects relationship data to be always present.

If relationship data is removed from status' user data, what happens is:

• when you click on avatar in status it will show inline user profile as if you're not following them, not muting, not blocking, and them not following you, (domain blocks, subscription, etc.). UI isn't blocked at this time.
• when relationship request finishes it will update profile accordingly, if they are following you UI will jump because "Follows you!" label will appear and shift contents after it downwards
• if any new posts by same users are fetched during this time, it might shift again and display as if you're not following them anymore, and "Follows you!" will disappear, shifting UI again. This is because new statuses update user data with missing relationships.

What needs to be done in UI to fix all this:

• write merger for user data so that empty relationship data doesn't overwrite present relationship data
  • this may include restructuring of internal User object representation, since PleromaFE uses qvitterapi-like structures inside so relationship object is essentially translated into several properties of user object ( user.relationship.following -> user.is_following or something)
• handle the case when relationship data isn't present yet (show a spinner over follow/mute/etc buttons?)
  • make sure it doesn't affect buttons that don't require relationship data (moderation, mention, report)
• handle the error case when relationship data failed to fetch
• redesign/fix "Follows you!" label so it doesn't cause UI to jump

Yeah this doesn't seem too bad, fixing the merging seems like the most important part or just separate relationships from users, so we have relationships: { <userid1>: { follows_you: true, ... }, ... } that can be used to easily get the data we want per user.

For the inline user cards I wouldn't bother redesigning it to prevent jumps, since the inline user cards themselves need to be redesigned completely out anyway. Would probably be a better idea to show a spinner for the entire profile before the relationship data is fetched, and error the entire profile if it fails. I'd rather not figure out super granular error states for the rare cases when we have partial data.

i would rather much avoid showing spinner for whole thing. It would be very annoying for simple cases like changing user highlight color or reading bio.

keep in mind that everything I've described also applies to non-inline user profiles as well.

It depends on how fast of a request it is, besides if you already have the relationship in store there's no need to fetch it again.

how fast request is also depends on network connection, which could be suddenly-shitty-2G.

there is a need to fetch request again because relationship status can change - somebody (un)followed you since last time we fetched relationship data. We also should re-fetch relationship when (un)following, (un)muting, (un)blocking etc. to confirm that action was successful and/or if following made a follow request instead.

This case is already handled now and it could be better, but otherwise we initially have zero data on user relationships, so first open of profile (inline or full) will always have this delay before first relationship data is fetched, which means we have to handle this case at least somehow.

mentioned in merge request pleroma!2342 (merged)

Corresponding BE MR:

pleroma!2342 (merged)

Note: please change config :pleroma, :extensions, output_relationships_in_statuses_by_default: true to config :pleroma, :extensions, output_relationships_in_statuses_by_default: false locally for the above MR when implementing this feature.

mentioned in issue pleroma-meta#34

Any updates on this? Looking forward to demoing it to see how it improves performance in certain scenarios.

@feld Could we assign this issue to someone specific (and available)?

I am working on this, didn't remember to assign

assigned to @shpuld

mentioned in merge request !1091 (merged)

closed via merge request !1091 (merged)

mentioned in commit 47c56ffa