Add cold start follow recommendations #15945

Gargron · 2021-03-22T11:07:03Z

Joining a new social network is a disorienting experience. Unlike other platforms, offering the user to find their old friends using something like a contact list upload is impossible. So we need to at least present the user with new content. The features that served this purpose so far were the public timelines, the profile directory, trending hashtags, and automatically following the admin user(s).

The public timelines worked while Mastodon was new and small, under the radar of spammers and marketers, and mostly concentrated in a few major languages. As of today, I do not believe anyone could say with a serious face that new users should browse the federated timeline to get accustomed to the platform. The noise to signal ratio is simply too small.

The profile directory is slightly better in this aspect but its egalitarian sorting method (recent activity) means it is just one step of abstraction from the federated timeline and not any more helpful for finding quality content. Previous attempt to at least make it categorized by using hashtags in people's bios proved unsuccessful, due to some fundamental flaws:

People do not use hashtags in bios enough and
Hashtags in bios are not always an honest representation of someone's posting behaviour

Trending hashtags are useful, but not very prominent. Auto-following admin user(s) is probably the feature that has been carrying new user onboarding for years, but it too is flawed. It requires admins to consistently act as curators and boost interesting content from different users. It leaves people wondering why they are already following someone they don't know, and does not always translate into new users following other people.

Regardless of what you think about popularity contests or "clout", the reality is that a new user must be presented with something interesting quickly after signing up, or they will bounce and never return, and that means that popularity must play into the new user experience (that is, unless you have some AI oracle mechanism that can tell you when something is interesting before showing it to real people).

This feature will provide new users "who to follow" recommendations. This is an enhancement of the existing "who to follow" feature which so far has been essentially a reminder to follow people you often engage with (which is useless for new users who have not had anyone to engage with yet).

The results will be a shuffled mix of two parts:

Users who had the highest engagement (reblogs and favourites) in the past 30 days and
Users who have the most local followers (followers who were active in the past 30 days)

Where only users with unlocked, not-limited, active accounts who have opted-into the profile directory feature (though this might warrant a rename of the checkbox label; internally the setting is called "discoverable" and this no longer has anything to do with the profile directory specifically) are considered.

Furthermore, we can localize the results for whichever language the new user's interface is in, by looking at which language is most common among each user's most recent 10 posts.

While 2. highlights accounts that may have high significance or recognizability (like the EFF or Tutanota, or Mastodon itself), 1. promotes accounts that create content that resonates with the community.

The admin UI provides an overview of these recommendations with the ability to moderate them.

Gargron · 2021-03-29T21:20:52Z

app/models/account.rb

@@ -363,7 +364,7 @@ def to_param
  end

  def excluded_from_timeline_account_ids
-    Rails.cache.fetch("exclude_account_ids_for:#{id}") { blocking.pluck(:target_account_id) + blocked_by.pluck(:account_id) + muting.pluck(:target_account_id) }
+    Rails.cache.fetch("exclude_account_ids_for:#{id}") { block_relationships.pluck(:target_account_id) + blocked_by_relationships.pluck(:account_id) + mute_relationships.pluck(:target_account_id) }


This change is unrelated but it does remove a redundant JOIN.

Could be moved in another PR as well.

config/routes.rb

noellabo · 2021-03-29T22:36:05Z

Sometimes I am suggested myself. This should be excluded.

Gargron · 2021-03-29T22:37:14Z

Good point.

noellabo · 2021-03-29T23:12:41Z

The list of suggestions has a dismiss button, but it has no effect on additional candidates. This is not what the user expects.

Hide the dismiss button if disabled
Keep the dismiss list and do not make it a candidate once it is dismissed

Gargron · 2021-03-30T00:16:32Z

Due to the suggestions API returning accounts and not a different entity that wraps accounts it is difficult to add a "dismissable" attribute, or other information about the source/nature of the recommendation. It is also difficult to make the global fallback results dismissable; personalized suggestions live in a personal sorted set, so removing is simple, but to dismiss a global result, another layer of filtering would need to be added.

I think it is not a huge problem if the dismiss button doesn't work on some results, it is unexpected but it might not be noticed often. Removing the dismiss function altogether is another option. While dismissing recommendations is possible on LinkedIn, there is no such option on Twitter, for example. Alternatively, we will need to add another model similar to mutes, but I would not want to do that within this PR.

noellabo · 2021-03-30T01:09:41Z

OK.

The dissmiss button appears to work on the WebUI until it reloads. Until you find a good solution, I think it's best to stay as it is.

ClearlyClaire

I'd like admins to be able to disable the feature entirely. Indeed, this in an additional venue for bad actors to be promoted to users, and while admins are able to suppress individual suggestions, monitoring them and doing so is also additional work for them.

Considering the suggestion criteria, I'm unsure about the sensitive thing. I understand this may to not present people with porn and stuff, but:

that's already some bias
how that bit is set for posts without media is dependent on the client, and, if the account is remote, of the server
this risks effectively filtering out people using content warnings, actively encouraging newcomers using content warnings less than half the time, which might in turn make newcomers accustomed to not using them at all.

Apart from that, I can't really comment on the quality of the recommendations, I'm not too sure

On the technical side of things, I wonder how much space the account_summaries materialized view takes. At many points you were reluctant to add columns to the accounts table because of how big it is… but an additional materialized view on the whole accounts table would be even worse, wouldn't it?

app/workers/scheduler/instance_refresh_scheduler.rb

app/lib/potential_friendship_tracker.rb

app/models/follow_recommendation_filter.rb

app/views/admin/follow_recommendations/show.html.haml

app/models/follow_recommendation_filter.rb

app/workers/scheduler/follow_recommendations_scheduler.rb

Gargron · 2021-03-31T13:23:10Z

Considering the suggestion criteria, I'm unsure about the sensitive thing. I understand this may to not present people with porn and stuff, but:

that's already some bias

how that bit is set for posts without media is dependent on the client, and, if the account is remote, of the server

this risks effectively filtering out people using content warnings, actively encouraging newcomers using content warnings less than half the time, which might in turn make newcomers accustomed to not using them at all.

You don't know when something is "sensitive" because it's porn/gore or because it's a "cat picture with eye contact". You have to err on the side of caution because you don't know how old the new user is. Porn/gore without "sensitive" flag is against most places' rules so while it's possible that it can occur, it becomes a moderation matter. Likewise from the perspective of reducing friction for new users, the less click-throughs are required to view content, the better. The content warning system can be alienating to someone not accustomed to it when it's everywhere.

Gargron · 2021-03-31T14:04:33Z

On the technical side of things, I wonder how much space the account_summaries materialized view takes. At many points you were reluctant to add columns to the accounts table because of how big it is… but an additional materialized view on the whole accounts table would be even worse, wouldn't it?

Okay, so adding columns to the accounts table means that every time you update any column in the table, there is more data to be copied to a new tuple and more data left to be vacuumed in the dead tuple. Also from a maintenance perspective, Postgres allows separate tables to be moved to separate drives on the file system, so the database is generally easier to deal with when you have more tables than if your one table has more columns.

On mastodon.online, accounts is 374 MB, account_summaries is 5 MB.

app/lib/potential_friendship_tracker.rb

ClearlyClaire · 2021-03-31T15:56:09Z

Considering the suggestion criteria, I'm unsure about the sensitive thing. I understand this may to not present people with porn and stuff, but:

that's already some bias

how that bit is set for posts without media is dependent on the client, and, if the account is remote, of the server

this risks effectively filtering out people using content warnings, actively encouraging newcomers using content warnings less than half the time, which might in turn make newcomers accustomed to not using them at all.

You don't know when something is "sensitive" because it's porn/gore or because it's a "cat picture with eye contact". You have to err on the side of caution because you don't know how old the new user is. Porn/gore without "sensitive" flag is against most places' rules so while it's possible that it can occur, it becomes a moderation matter. Likewise from the perspective of reducing friction for new users, the less click-throughs are required to view content, the better. The content warning system can be alienating to someone not accustomed to it when it's everywhere.

Yeah, but I'm worried such a criteria would just discourage use of CWs and the sensitive flag overall. That being said, I'm not sure how effective that check even is, e.g. if someone posts properly-tagged porn 9 out of 20 times, they're going to be eligible anyway.

On the technical side of things, I wonder how much space the account_summaries materialized view takes. At many points you were reluctant to add columns to the accounts table because of how big it is… but an additional materialized view on the whole accounts table would be even worse, wouldn't it?

Okay, so adding columns to the accounts table means that every time you update any column in the table, there is more data to be copied to a new tuple and more data left to be vacuumed in the dead tuple. Also from a maintenance perspective, Postgres allows separate tables to be moved to separate drives on the file system, so the database is generally easier to deal with when you have more tables than if your one table has more columns.

On mastodon.online, accounts is 374 MB, account_summaries is 5 MB.

Ok, we probably don't have to care about that then. Although we could do some a-priori filtering (e.g. only keeping discoverable and non-locked accounts in the materialized view) to reduce both the materialized view size and the query time.

app/models/account_suggestions.rb

ClearlyClaire

Added a few inline comments. My comments about the whole approach still stand, but the PR is in better shape overall.

app/javascript/mastodon/features/compose/components/search_results.js

ClearlyClaire · 2021-04-09T12:27:18Z

app/models/account.rb

@@ -363,7 +364,7 @@ def to_param
  end

  def excluded_from_timeline_account_ids
-    Rails.cache.fetch("exclude_account_ids_for:#{id}") { blocking.pluck(:target_account_id) + blocked_by.pluck(:account_id) + muting.pluck(:target_account_id) }
+    Rails.cache.fetch("exclude_account_ids_for:#{id}") { block_relationships.pluck(:target_account_id) + blocked_by_relationships.pluck(:account_id) + mute_relationships.pluck(:target_account_id) }


Could be moved in another PR as well.

app/models/follow_recommendation.rb

app/workers/scheduler/follow_recommendations_scheduler.rb

ClearlyClaire

Apart from the inline comment this seems technically ok to me.

I'm just not completely sure about the metrics and criteria, and I would rather prefer if admins could disable the feature altogether, but otherwise it seems fine to me.

app/javascript/mastodon/features/compose/components/search_results.js

ClearlyClaire

Again I want to reiterate that:

I'm not sure about the criteria/metrics used (especially wrt. it discouraging CWs use)
I'd like admins to have the ability to disable the feature altogether

Otherwise, LGTM

nemobis · 2023-04-24T13:36:19Z

Some follow-up discussions on #18128

Gargron added the new user experience Features for attracting and onboarding new users label Mar 22, 2021

Gargron force-pushed the feature-cold-start-follow-recommendations branch 10 times, most recently from 9cca164 to 66cedcb Compare March 24, 2021 17:29

Gargron force-pushed the feature-cold-start-follow-recommendations branch from 66cedcb to d3d6e97 Compare March 29, 2021 20:51

Gargron marked this pull request as ready for review March 29, 2021 20:59

Gargron commented Mar 29, 2021

View reviewed changes

config/routes.rb Outdated Show resolved Hide resolved

Gargron force-pushed the feature-cold-start-follow-recommendations branch from d3d6e97 to 71652f4 Compare March 29, 2021 22:40

Gargron requested a review from ClearlyClaire March 30, 2021 15:55

ClearlyClaire requested changes Mar 31, 2021

View reviewed changes

ClearlyClaire reviewed Mar 31, 2021

View reviewed changes

app/workers/scheduler/follow_recommendations_scheduler.rb Outdated Show resolved Hide resolved

ClearlyClaire reviewed Mar 31, 2021

View reviewed changes

app/lib/potential_friendship_tracker.rb Outdated Show resolved Hide resolved

Gargron force-pushed the feature-cold-start-follow-recommendations branch from 71652f4 to 09d38c6 Compare April 8, 2021 19:50

ClearlyClaire reviewed Apr 8, 2021

View reviewed changes

app/models/account_suggestions.rb Outdated Show resolved Hide resolved

Gargron force-pushed the feature-cold-start-follow-recommendations branch 3 times, most recently from 75c8cef to 2e5db73 Compare April 8, 2021 20:47

ClearlyClaire reviewed Apr 9, 2021

View reviewed changes

Gargron force-pushed the feature-cold-start-follow-recommendations branch from 2e5db73 to 0609a62 Compare April 9, 2021 21:36

Gargron requested a review from ClearlyClaire April 10, 2021 15:26

ClearlyClaire requested changes Apr 10, 2021

View reviewed changes

app/javascript/mastodon/features/compose/components/search_results.js Outdated Show resolved Hide resolved

Add cold-start follow recommendations

6cb0a0e

Gargron force-pushed the feature-cold-start-follow-recommendations branch from 0609a62 to 6cb0a0e Compare April 10, 2021 19:55

Gargron requested a review from ClearlyClaire April 11, 2021 13:17

ClearlyClaire approved these changes Apr 12, 2021

View reviewed changes

Gargron merged commit f711764 into main Apr 12, 2021

Gargron deleted the feature-cold-start-follow-recommendations branch April 12, 2021 10:37

Gargron mentioned this pull request Apr 19, 2021

Change onboarding by replacing tutorial with follow recommendations in web UI #16060

Merged

Gargron mentioned this pull request May 17, 2021

Regression in 3.4: Default follows for new users #16229

Closed

heguro mentioned this pull request Nov 1, 2021

Make welcome email fit for current follow recommendation feature #16919

Closed

chrisguida pushed a commit to Start9Labs/mastodon that referenced this pull request Feb 26, 2022

Add cold-start follow recommendations (mastodon#15945)

9f69736

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add cold start follow recommendations #15945

Add cold start follow recommendations #15945

Gargron commented Mar 22, 2021 •

edited

Loading

Gargron Mar 29, 2021

ClearlyClaire Apr 9, 2021

noellabo commented Mar 29, 2021

Gargron commented Mar 29, 2021

noellabo commented Mar 29, 2021

Gargron commented Mar 30, 2021

noellabo commented Mar 30, 2021

ClearlyClaire left a comment

Gargron commented Mar 31, 2021

Gargron commented Mar 31, 2021

ClearlyClaire commented Mar 31, 2021

ClearlyClaire left a comment

ClearlyClaire Apr 9, 2021

ClearlyClaire left a comment

ClearlyClaire left a comment

nemobis commented Apr 24, 2023

Add cold start follow recommendations #15945

Add cold start follow recommendations #15945

Conversation

Gargron commented Mar 22, 2021 • edited Loading

Gargron Mar 29, 2021

Choose a reason for hiding this comment

ClearlyClaire Apr 9, 2021

Choose a reason for hiding this comment

noellabo commented Mar 29, 2021

Gargron commented Mar 29, 2021

noellabo commented Mar 29, 2021

Gargron commented Mar 30, 2021

noellabo commented Mar 30, 2021

ClearlyClaire left a comment

Choose a reason for hiding this comment

Gargron commented Mar 31, 2021

Gargron commented Mar 31, 2021

ClearlyClaire commented Mar 31, 2021

ClearlyClaire left a comment

Choose a reason for hiding this comment

ClearlyClaire Apr 9, 2021

Choose a reason for hiding this comment

ClearlyClaire left a comment

Choose a reason for hiding this comment

ClearlyClaire left a comment

Choose a reason for hiding this comment

nemobis commented Apr 24, 2023

Gargron commented Mar 22, 2021 •

edited

Loading