Split up ACM format article into its own file

2024-05-09 11:40:17 -05:00 · 2024-05-09 11:40:17 -05:00 · 7e86a989eb
commit 7e86a989eb
parent 02227e6bc2
7 changed files with 585 additions and 467 deletions
--- a/.gitignore
+++ b/.gitignore
@ -11,6 +11,7 @@ index_files/
 site_libs/
 .quarto/
 images/server_images/
 _out/
 # R stuff
 .Rproj.user
--- a/5
+++ b/5
@ -0,0 +1,5 @@
 acm:
 	quarto render --profile acm
 preview:
 	quarto preview --profile acm
--- a/_article.qmd
+++ b/_article.qmd
@ -1,441 +0,0 @@
 ```{r}
 #| label: setup
 profile <- Sys.getenv("QUARTO_PROFILE", unset="acm")
 if (profile == "acm") {
  class_wide <- ".column-body"
 } else {
  class_wide <- ".column-page"
 }
 envs <- Sys.getenv()
 ```
 # Introduction
 Following Twitter's 2022 acquisition, Mastodon---an open-source, decentralized social network and microblogging community---saw an increase in activity and attention as a potential Twitter alternative [@heFlockingMastodonTracking2023; @cavaDriversSocialInfluence2023]. While millions of people set up new accounts and significantly increased the size of the network, many newcomers found the process confusing and many accounts did not remain active. Unlike centralized social media platforms, Mastodon is a network of independent servers with their own rules and norms [@nicholsonMastodonRulesCharacterizing2023]. Each server can communicate with each other using the shared ActivityPub protocols and accounts can move between Mastodon servers, but the local experience can vary widely from server to server.
 <!--  Further, many Mastodon servers have specific norms which people coming from Twitter may find confusing, such as local norms around content warnings [@nicholsonMastodonRulesCharacterizing2023]. -->
 Although attracting and retaining newcomers is a key challenge for online communities [@krautBuildingSuccessfulOnline2011 p. 182], Mastodon's onboarding process has not always been straightforward. Variation among servers can also present a challenge for newcomers who may not even be aware of the specific rules, norms, or general topics of interest on the server they are joining [@diazUsingMastodonWay2022]. Various guides and resources for people trying to join Mastodon offered mixed advice on choosing a server. Some suggest that the most important thing is to simply join any server and work from there [@krasnoffMastodon101How2022; @silberlingBeginnerGuideMastodon2023], while others have created tools and guides to help people find potential servers of interest by size and location[@thekinrarMastodonInstances; @kingMastodonMe2024].
 Mastodon's decentralized design has long been in tension with the disproportionate popularity of a small set of large, general-topic servers within the system [@ramanChallengesDecentralisedWeb2019a]. Analysing the activity of new accounts that join the network, we find that users who sign up on such servers are less likely to remain active after 91 days. We also find that many users who move accounts tend to gravitate toward smaller, more niche servers over time, suggesting that established users may also find additional utility from such servers.
 In response to these findings, we propose a potential way to create server and tag recommendations on Mastodon. This recommendation system could both help newcomers find servers that match their interests and help established accounts discover "neighborhoods" of related servers.
 # Background
 ## Empirical Setting
 The Fediverse is a set of decentralized online social networks which interoperate using shared protocols like ActivityPub. Mastodon is a software program used by many Fediverse servers and offers a user experience similar to the Tweetdeck client for Twitter. It was first created in late 2016 and saw a surge in interest in 2022 during and after Elon Musk's Twitter acquisition.
 Mastodon features three kinds of timelines. The primary timelines is a "home" timeline which shows all posts from accounts followed by the user. Mastodon also supports a "local" timeline which shows all public posts from the local server and a "federated" timeline which includes all posts from users followed by other users on their server. The local timeline is unique to each server and can be used to discover new accounts and posts from the local community. On larger servers, this timeline can be unwieldy; however, on smaller servers, this presents the opportunity to discover new posts and users of potential interest.
 Discovery has been challenging on Masotodon. Text search, for instance, was impossible on most servers until support for this feature was added on an optional, opt-in basis using Elasticsearch in late 2023 [@rochkoMastodon2023]. Recommendation systems are currently a somewhat novel problem in the context of decentralized online social networks. @trienesRecommendingUsersWhom2018 developed a recommendation system for finding new accounts to follow on the Fediverse which used collaborative filtering based on BM25 in an early example of a content discovery system on Mastodon.
 Individual Mastodon servers can have an effect on the end experience of users. For example, some servers may choose to federate with some servers but not others, altering the topology of the Fediverse network for their users. At the same time, accounts need to be locked into one specific server. Because of Mastodon's data portability, users can move their accounts freely between servers while retaining their followers, though their post history remains with their original account.
 ## The Mastodon Migrations
 Mastodon saw a surge in interest in 2022 and 2023, particularly after Elon Musk's Twitter acquisition. In particular, four events of interests drove measurable increases in new users to the network: the announcement of the acquisition (April 14, 2022), the closing of the acquisition (October 27, 2022), a day when Twitter suspended a number of prominent journalists (December 15, 2022), and a day when Twitter experienced an outage and started rate limiting accounts (July 1, 2023). Many Twitter accounts announced they were setting up Mastodon accounts and linked their new accounts to their followers, often using tags like #TwitterMigration [@heFlockingMastodonTracking2023] and driving interest in Mastodon in a process @cavaDriversSocialInfluence2023 found consistent with social influence theory.
 Some media outlets have framed reports on Mastodon [@hooverMastodonBumpNow2023] through what @zulliRethinkingSocialSocial2020 calls the "Killer Hype Cycle", whereby the media finds a new alternative social media platform, declares it a potential killer of some established platform, and later calls it a failure if it does not displace the existing platform. Such framing fails to take systems like the Fediverse seriously for their own merits: completely replacing existing commercial systems is not the only way to measure success, nor does it account for the real value the Fediverse provides for its millions of active users.
 Mastodon's approach to onboarding has also changed over time. In much of 2020 and early 2021, the Mastodon developers closed sign-ups to their flagship server and linked to an alternative server, which saw increased sign-ups during this period. They also linked to a list of servers on the "Join Mastodon" webpage [@mastodonggmbhServers], where all servers are pre-approved and follow the Mastodon Server Covenant which guarantees certain content moderation standards and data protections. Starting in 2023, the Mastodon developers shifted toward making the flagship server the default when people sign up on the official Mastodon Android and iOS apps [@rochkoNewOnboardingExperience2023; @rothItGettingEasier2023].
 ## Newcomers in Online Communities
 Onboarding newcomers is an important part of the life cycle of online communities. Any community can expect a certain amount of turnover, and so it is important for the long-term health and longevity of the community to be able to bring in new members [@krautBuildingSuccessfulOnline2011 p. 182]. However, the process of onboarding newcomers is not always straightforward.
 The series of migrations of new users into Mastodon in many ways reflect folk stories of "Eternal Septembers" on previous communication networks, where a large influx of newcomers challenged the existing norms [@driscollWeMisrememberEternal2023; @kieneSurvivingEternalSeptember2016]. Many Mastodon servers do have specific norms which people coming from Twitter may find confusing, such as local norms around content warnings [@nicholsonMastodonRulesCharacterizing2023]. Variation among servers can also present a challenge for newcomers who may not even be aware of the specific rules, norms, or general topics of interest on the server they are joining [@diazUsingMastodonWay2022]. Mastodon servers open to new accounts must thus be both accommodating to newcomers while at the same ensuring the propagation of their norms and culture, either through social norms or through technical means.
 # Data
 ```{r}
 #| label: fig-account-timeline
 #| fig-cap: "Accounts in the dataset created between January 2022 and March 2023. The top panels shows the proportion of accounts still active 45 days after creation, the proportion of accounts that have moved, and the proportion of accounts that have been suspended. The bottom panel shows the count of accounts created each week. The dashed vertical lines in the bottom panel represent the annoucement day of the Elon Musk Twitter acquisition, the acquisition closing day, a day where Twitter suspended a number of prominent journalist, and a day when Twitter experienced an outage and started rate limiting accounts."
 #| fig-height: 2.75
 #| fig-width: 6.75
 #| fig-env: figure*
 #| fig-pos: tb!
 library(here)
 source(here("code/helpers.R"))
 account_timeline_plot()
 ```
 Mastodon has an extensive API which allows for the collection of public posts and account information. We collected data from the public timelines of Mastodon servers using the Mastodon API with a crawler which runs once per day. We also collected account information from the opt-in public profile directories on these servers.
 ```{r}
 #| label: data-counts
 #| cache: true
 library(arrow)
 library(tidyverse)
 library(here)
 source(here("code/helpers.R"))
 accounts <- load_accounts(filt = FALSE) %>%
  filter(created_at >= "2020-08-14") %>%
  filter(created_at < "2024-01-01")
 tag_posts <- "data/scratch/all_tag_posts.feather" %>% 
  arrow::read_ipc_file(. , col_select = c("host", "acct", "created_at")) %>%
  filter(created_at >= as.Date("2023-05-01")) %>%
  filter(created_at < as.Date("2023-08-01"))
 text_format <- function(df) {
  return (format(nrow(df), big.mark=","))
 }
 num_tag_posts <- tag_posts %>% text_format()
 num_tag_accounts <- tag_posts %>% distinct(host, acct) %>% text_format()
 num_tag_servers <- tag_posts %>% distinct(host) %>% text_format()
 num_accounts_unfilt <- accounts %>% text_format()
 num_account_bots <- accounts %>% filter(bot) %>% text_format()
 num_account_nostatuses <- accounts %>% filter(is.na(last_status_at)) %>% text_format()
 num_account_suspended <- accounts %>% mutate(suspended = replace_na(suspended, FALSE)) %>% filter(suspended) %>% text_format()
 num_accounts_moved <- accounts %>% filter(has_moved) %>% text_format()
 num_account_limited <- accounts %>% filter(limited) %>% text_format()
 num_account_samedaystatus <- accounts %>% filter(last_status_at <= created_at) %>% text_format()
 num_account_filt <- load_accounts(filt = TRUE) %>% text_format()
 ```
 **Mastodon Profiles**: We collected accounts using data previously collected from posts on public Mastodon timelines from October 2020 to August 2023. We then queried for up-to-date information on those accounts including their most recent status and if the account had moved as of February 2024. Through this process, we discovered a total of `r num_accounts_unfilt` account created between August 14, 2020 and January 1, 2024. We then filtered out accounts which were bots (`r num_account_bots` accounts), had been suspended (`r num_account_suspended` accounts), had been marked as moved to another account (`r num_accounts_moved` accounts), had been limited by their local server (`r num_account_limited` accounts), had no statuses (`r num_account_nostatuses` accounts), or had posted their last status on the same day as their account creation (`r num_account_samedaystatus` accounts). This gave us a total of `r num_account_filt` accounts which met all the filtering criteria. Note that because we got updated information on each account, we include only accounts on servers which still existed at the time of our profile queries and which returned records for the account.
 **Tags**: Mastodon supports hashtags, which are user-generated metadata tags that can be added to posts. Clicking the link for a tag shows a stream of posts which also have that tag from the federated timeline, which includes accounts on the same server and posts from accounts followed by the accounts on the local server. We collected `r num_tag_posts` statuses posted by `r num_tag_accounts` accounts on `r num_tag_servers` unique servers from between May to July 2023 which contained at least one hashtag.
 # Analysis and Results
 ## Survival Model
 *Are accounts on suggested general servers less likely to remain active than accounts on other servers?*
 ```{r, cache.extra = tools::md5sum("code/survival.R")}
 #| cache: true
 #| label: fig-survival
 #| fig-env: figure
 #| fig-cap: "Survival probabilities for accounts created during May 2023."
 #| fig-width: 3.375
 #| fig-height: 2.5
 #| fig-pos: h!
 library(here)
 source(here("code/survival.R"))
 plot_km 
 ```
 ```{r}
 #| label: table-coxme
 library(ehahelper)
 library(broom)
 cxme_table <- tidy(cxme) %>%
  mutate(conf.low = exp(conf.low), conf.high=exp(conf.high)) %>%
  mutate(term = case_when(
    term == "factor(group)1" ~ "Join Mastodon",
    term == "factor(group)2" ~ "General Servers",
    term == "small_serverTRUE" ~ "Small Server",
    TRUE ~ term
  )) %>%
  mutate(exp.coef = paste("(", round(conf.low, 2), ", ", round(conf.high, 2), ")", sep="")) %>%
  select(term, estimate, exp.coef , p.value)
 ```
 Using `r text_format(sel_a)` accounts created from May 1 to June 30, 2023, we create a Kaplan–Meier estimator for the probability that an account will remain active based on whether the account is on one of the largest general instances [^1] featured at the top of the Join Mastodon webpage or otherwise if it is on a server in the Join Mastodon list. Accounts are considered active if they have made at least one post after the censorship period `r active_period` days after account creation.
 [^1]: `r paste(general_servers, collapse=", ")`
 ::: {.content-visible unless-profile="icwsm"}
 ::: {#tbl-cxme .column-body}
 ```{r}
 if (knitr::is_latex_output()) {
  cxme_table %>% knitr::kable(format="latex", booktabs=TRUE, digits=3)
 } else {
  cxme_table %>% knitr::kable(digits = 3)
 }
 ```
 Coefficients for the Cox Proportional Hazard Model with Mixed Effects. The model includes a random effect for the server.
 :::
 We also construct a Mixed Effects Cox Proportional Hazard Model
 $$
 h(t_{ij}) = h_0(t) \exp\left(\begin{aligned}
  &\beta_1 \text{Join Mastodon} \\
  &+ \beta_2 \text{General Servers} \\
  &+ \beta_3 \text{Small Server} \\
  &+ b_{j}
 \end{aligned}\right)
 $$
 where $h(t_{ij})$ is the hazard for account $i$ on server $j$ at time $t$, $h_0(t)$ is the baseline hazard, $\beta_1$ is the coefficient for whether the account is on a server featured on Join Mastodon, $\beta_2$ is the coefficient for whether the account is on one of the largest general instances, $\beta_3$ is the coefficient for whether the account is on a small server with less than 100 accounts, and $b_{j}$ is the random effect for server $j$.
 <!-- with coefficients for whether the account is on a small server (less than a hundred accounts), and whether the account in featured on JoinMastodon or is featured as one of the largest general instances. -->
 We again find that accounts on the largest general instances are less likely to remain active than accounts on other servers, while accounts created on smaller servers are more likely to remain active.
 :::
 ## Moved Accounts
 *Do accounts tend to move to larger or smaller servers?*
 Mastodon users can move their accounts to another server while retaining their connections (but not their posts) to other Mastodon accounts. This feature, built into the Mastodon software, offers data portability and helps avoid lock-in.
 ```{r}
 #| label: table-ergm-table
 #| echo: false
 #| warning: false
 #| message: false
 #| error: false
 library(here)
 library(modelsummary)
 library(kableExtra)
 library(purrr)
 library(stringr)
 load(file = here("data/scratch/ergm-model-early.rda"))
 load(file = here("data/scratch/ergm-model-late.rda"))
 if (knitr::is_latex_output()) {
  format <- "latex_tabular"
 } else {
  format <- "html"
 }
 x <- modelsummary(
  list("Coef." = model.early, "Std.Error" = model.early, "Coef." = model.late, "Std.Error" = model.late),
  estimate = c("{estimate}", "{stars}{std.error}", "{estimate}", "{stars}{std.error}"),
  statistic = NULL,
  gof_omit = ".*",
  coef_rename = c(
    "sum" = "Sum",
    "nonzero" = "Nonzero",
    "diff.sum0.h-t.accounts" = "Smaller server",
    "nodeocov.sum.accounts" = "Server size\n(outgoing)",
    "nodeifactor.sum.registrations.TRUE" = "Open registrations\n(incoming)",
    "nodematch.sum.language" = "Languages match"
  ),
  align="lrrrr",
  stars = c('*' = .05, '**' = 0.01, '***' = .001),
  output = format
  ) %>% add_header_above(c(" " = 1, "Model A" = 2, "Model B" = 2))
 ```
 :::: {#tbl-ergm-table `r class_wide`}
 ```{r}
 x
 ```
 Exponential family random graph models for account movement between Mastodon servers. Accounts in Model A were created in May 2022 and moved to another account at some later point. Accounts in Model B were created at some earlier point and moved after October 2023.
 ::::
 To corroborate our findings, we also use data from thousands of accounts which moved between Mastodon servers, taking advantage of the data portability of the platform. Conceiving of these moved accounts as edges within a weighted directional network where nodes represent servers, edges represent accounts, and weights represent the number of accounts that moved between servers, we construct an exponential family random graph model (ERGM) with terms for server size, open registrations, and language match between servers. We find that accounts are more likely to move from larger servers to smaller servers.
 # Proposed Recommendation System
 *How can we build an opt-in, low-resource recommendation system for finding Fediverse servers?*
 Based on these findings, we suggest a need for better ways for newcomers to find servers and propose a viable way to create server and tag recommendations on Mastodon. This system could both help newcomers find servers that match their interests and help established accounts discover "neighborhoods" of related servers.
 One challenge in building such a system is the decentralized nature of the system. A single, central actor which collects data from servers and then distributes recommendations would be antithetical to the decentralized nature of Mastodon. Instead, we propose a system where servers can report the top hashtags by the number of unique accounts on the server using them during the last three months. Such a system would be opt-in and require few additional server resources since tags already have their own database table.
 ## Recommendation System Design
 We use Okapi BM25 to construct a term frequency-inverse document frequency (TF-IDF) model to associate the top tags with each server using counts of tag-account pairs from each server for the term frequency and the number of servers that use each tag for the inverse document frequency. We then L2 normalize the vectors for each tag and calculate the cosine similarity between the tag vectors for each server.
 $$
 tf = \frac{f_{t,s} \cdot (k_1 + 1)}{f_{t,s} + k_1 \cdot (1 - b + b \cdot \frac{|s|}{avgstl})}
 $$
 where $f_{t,s}$ is the number of accounts using the tag $t$ on server $d$, $k_1$ and $b$ are tuning parameters, and $avgstl$ is the average sum of account-tag pairs. For the inverse document frequency, we use the following formula: 
 $$
 idf = \log \frac{N - n + 0.5}{n + 0.5}
 $$
 where $N$ is the total number of servers and $n$ is the number of servers where the tag appears as one of the top tags. We then apply L2 normalization:
 $$
 tfidf = \frac{tf \cdot idf}{\| tf \cdot idf \|_2}
 $$
 ## Applications
 ```{r}
 #| eval: false
 library(tidyverse)
 library(igraph)
 library(arrow)
 sim_servers <- "data/scratch/server_similarity.feather" %>% arrow::read_ipc_file() %>% rename("weight" = "Similarity")
 #sim_net <- as.network(sim_servers)
 g <- graph_from_data_frame(sim_servers, directed = FALSE)
 g_strength <- log(sort(strength(g)))
 normalized_strength <- (g_strength - min(g_strength)) / (max(g_strength) - min(g_strength))
 server_centrality <- enframe(normalized_strength, name="server", value="strength")
 server_centrality %>% arrow::write_ipc_file("data/scratch/server_centrality.feather")
 ```
 ### Server Similarity Neighborhoods
 Mastodon provides two feeds in addition to a user's home timeline populated by accounts they follow: a local timeline with all public posts from their local server and a federated timeline which includes all posts from users followed by other users on their server. We suggest a third kind of timeline, a *neighborhood timeline*, which filters the federated timeline by topic.
 We calculate the pairwise similarity between two servers with TF-IDF vectors $A$ and $B$ using cosine similarity:
 $$
 \text{similarity}(A, B) = \frac{A \cdot B}{\|A\| \|B\|}
 $$
 ::: {#tbl-sim-servers .content-visible unless-profile="icwsm"}
 ```{r}
 #| label: table-sim-servers
 library(tidyverse)
 library(arrow)
 sim_servers <- "data/scratch/server_similarity.feather" %>% arrow::read_ipc_file() 
 server_of_interest <- "hci.social"
 server_table <- sim_servers %>%
    arrange(desc(Similarity)) %>%
    filter(Source == server_of_interest | Target == server_of_interest) %>%
    head(5) %>%
    pivot_longer(cols=c(Source, Target)) %>%
    filter(value != server_of_interest) %>%
    select(value, Similarity) %>%
    rename("Server" = "value")
 if (knitr::is_latex_output()) {
  server_table %>% knitr::kable(format="latex", booktabs=TRUE, digits=3)
 } else {
  server_table %>% knitr::kable(digits = 3)
 }
 ```
 Top five servers most similar to hci.social
 :::
 ### Server Discovery
 Given a set of popular tags and a list of servers, we build a recommendation system where users select tags from a list of popular tags and receive server suggestions. The system first creates a subset of vectors based on the TF-IDF matrix which represents the top clusters of topics. After a user selects the top tags of interest to them, it suggests servers which match their preferences.
 ### Tag Similarity
 We also calculate the similarity between tags using the same method. This can be used to suggest related tags to users based on their interests.
 ::: {.content-visible unless-profile="icwsm"}
 ## Rubustness to Limited Data
 ```{r}
 #| label: fig-simulations-rbo
 #| fig-env: figure*
 #| cache: true
 #| fig-width: 6.75
 #| fig-height: 3
 #| fig-pos: tb
 library(tidyverse)
 library(arrow)
 simulations <- arrow::read_ipc_file("data/scratch/simulation_rbo.feather")
 simulations %>%
  group_by(servers, tags, run) %>% summarize(rbo=mean(rbo), .groups="drop") %>%
  mutate(ltags = as.integer(log2(tags))) %>%
  ggplot(aes(x = factor(ltags), y = rbo, fill = factor(ltags))) +
  geom_boxplot() +
  facet_wrap(~servers, nrow=1) +
  #scale_y_continuous(limits = c(0, 1)) +
  labs(x = "Tags (log2)", y = "RBO", title = "Rank Biased Overlap with Baseline Rankings by Number of Servers") +
  theme_minimal() + theme(legend.position = "none")
 ```
 A challenge for a federated recommendation system like we propose is that it needs buy in from a sufficient number of servers to provide value. There is also a tradeoff between the amount of tags to expose for each server and potential concerns about exposing too much data.
 We simulated various scenarios that limit both servers that report data and the number of tags they report. We used rank biased overlap (RBO) to then compare the outputs from these simulations to the baseline with more complete information from all tags on all servers [@webberSimilarityMeasureIndefinite2010]. In particular, we gave a higher weight to suggestions with a higher rank, with weights decaying by a factor of $k^{0.80}$. @fig-simulations-rbo shows how the average agreement with the baseline scales, which take the top 256 tags from each server.
 :::
 # Discussion
 The analysis can also be improved by additionally focusing on factors lead to accounts remaining active or dropping out, which a particular focus on the actual activity of accounts over time. For instance, do accounts that interact with other users more remain active longer? Are there particular markers of activity that are more predictive of account retention? Future work could use these to provide suggests for ways to helps newcomers during the onboarding process.
 The observational nature of the data limit some of the causal claims we can make. It is unclear, for instance, if accounts on general servers are less likely to remain active because of the server itself or because of the type of users who join such servers. For example, it is conceivable that the kind of person who spends more time researching which server to join is more invested in their Mastodon experience than one who simply joins the first server they find.
 Future work is necessary to determine the how well the recommendation system is at helping users find servers that match their interests. This may involve user studies and interviews to determine how well the system works in practice.
 While the work presented here is based on observed posts on the public timelines, simulations may be helpful in determining the robustness of the system to targeted attacks. Due to the decentralized nature of the system, it is feasible that a bad actor could set up zombie accounts on servers to manipulate the recommendation system. Simulations could help determine how well the system can resist such attacks and ways to mitigate this risk.
 # Conclusion
 Based on analysis of trace data from millions of new Fediverse accounts, we find evidence that suggests that servers matter and that users tend to move from larger servers to smaller servers. We then propose a recommendation system that can help new Fediverse users find servers with a high probability of being a good match based on their interests. Based on simulations, we demonstrate that such a tool can be effectively deployed in a federated manner, even with limited data on each local server.
 # References {#references}
 ::: {.content-visible unless-profile="icwsm"}
 # Glossary {.appendix}
 *ActivityPub*: A decentralized social networking protocol based on the ActivityStreams 2.0 data format.
 *Fediverse*: A set of decentralized online social networks which interoperate using shared protocols like ActivityPub.
 *Mastodon*: An open-source, decentralized social network and microblogging community.
 *Hashtag*: A user-generated metadata tag that can be added to posts.
 *Federated timeline*: A timeline which includes all posts from users followed by other users on their server.
 *Local timeline*: A timeline with all public posts from the local server.
 :::
 ::: {.content-visible when-format="html"}
 ```{r}
 library(tidyverse)
 library(arrow)
 library(ggrepel)
 "data/scratch/server_svd.feather" %>% arrow::read_ipc_file() %>%
  as_tibble %>%
  ggplot(aes(x = x, y = y, label = server)) +
  geom_text_repel(size = 2, max.overlaps = 10) +
  #geom_point() +
  theme_minimal()
 ```
 ```{r}
 library(tidyverse)
 library(arrow)
 library(ggrepel)
 library(here)
 library(jsonlite)
 top_tags <- "data/scratch/tag_svd.feather" %>% arrow::read_ipc_file() %>%
  as_tibble %>%
  mutate(s = variance * log(count)) %>% arrange(desc(s))
 top_tags %>% 
  select(tag, index) %>%
  jsonlite::write_json(here("recommender/data/top_tags.json"))
 top_tags %>%
  head(100) %>%
  ggplot(aes(x = x, y = y, label = tag)) +
  geom_text_repel(size = 3, max.overlaps = 10) +
  #geom_point() +
  theme_minimal()
 ```
 :::
--- a/_quarto.yml
+++ b/_quarto.yml
@ -1,5 +1,11 @@
 project:
  type: manuscript
  output-dir: "_out"
  preview:
    port: 2059
    host: 0.0.0.0
    browser: false
    watch-inputs: true
 format:
  acm-html:
    hypothesis: false
--- a/acm.qmd
+++ b/acm.qmd
@ -97,4 +97,491 @@ code-block-border-left: false
 code-block-bg: false
 ---
-{{< include _article.qmd >}}
+```{r}
 #| label: setup
 profile <- Sys.getenv("QUARTO_PROFILE", unset="acm")
 if (profile == "acm") {
  class_wide <- ".column-body"
 } else {
  class_wide <- ".column-page"
 }
 envs <- Sys.getenv()
 ```
 # Introduction
 Following Twitter's 2022 acquisition, Mastodon---an open-source, decentralized social network and microblogging community---saw an increase in activity and attention as a potential Twitter alternative [@heFlockingMastodonTracking2023; @lacavaDriversSocialInfluence2023]. While millions of people set up new accounts and significantly increased the size of the network, many newcomers found the process confusing and many accounts did not remain active. Unlike centralized social media platforms, Mastodon is a network of independent servers with their own rules and norms [@nicholsonMastodonRulesCharacterizing2023]. Each server can communicate with each other using the shared ActivityPub protocols and accounts can move between Mastodon servers, but the local experience can vary widely from server to server.
 <!--  Further, many Mastodon servers have specific norms which people coming from Twitter may find confusing, such as local norms around content warnings [@nicholsonMastodonRulesCharacterizing2023]. -->
 Although attracting and retaining newcomers is a key challenge for online communities [@krautBuildingSuccessfulOnline2011 p. 182], Mastodon's onboarding process has not always been straightforward. Variation among servers can also present a challenge for newcomers who may not even be aware of the specific rules, norms, or general topics of interest on the server they are joining [@diazUsingMastodonWay2022]. Various guides and resources for people trying to join Mastodon offered mixed advice on choosing a server. Some suggest that the most important thing is to simply join any server and work from there [@krasnoffMastodon101How2022; @silberlingBeginnerGuideMastodon2023], while others have created tools and guides to help people find potential servers of interest by size and location[@thekinrarMastodonInstances2017; @kingMastodonMe2024].
 Mastodon's decentralized design has long been in tension with the disproportionate popularity of a small set of large, general-topic servers within the system [@ramanChallengesDecentralisedWeb2019a]. Analysing the activity of new accounts that join the network, we find that users who sign up on such servers are less likely to remain active after 91 days. We also find that many users who move accounts tend to gravitate toward smaller, more niche servers over time, suggesting that established users may also find additional utility from such servers.
 In response to these findings, we propose a potential way to create server and tag recommendations on Mastodon. This recommendation system could both help newcomers find servers that match their interests and help established accounts discover "neighborhoods" of related servers.
 # Background
 ## Empirical Setting
 The Fediverse is a set of decentralized online social networks which interoperate using shared protocols like ActivityPub. Mastodon is a software program used by many Fediverse servers and offers a user experience similar to the Tweetdeck client for Twitter. It was first created in late 2016 and saw a surge in interest in 2022 during and after Elon Musk's Twitter acquisition.
 Mastodon features three kinds of timelines. The primary timelines is a "home" timeline which shows all posts from accounts followed by the user. Mastodon also supports a "local" timeline which shows all public posts from the local server and a "federated" timeline which includes all posts from users followed by other users on their server. The local timeline is unique to each server and can be used to discover new accounts and posts from the local community. On larger servers, this timeline can be unwieldy; however, on smaller servers, this presents the opportunity to discover new posts and users of potential interest.
 Discovery has been challenging on Masotodon. Text search, for instance, was impossible on most servers until support for this feature was added on an optional, opt-in basis using Elasticsearch in late 2023 [@rochkoMastodon2023]. Recommendation systems are currently a somewhat novel problem in the context of decentralized online social networks. @trienesRecommendingUsersWhom2018 developed a recommendation system for finding new accounts to follow on the Fediverse which used collaborative filtering based on BM25 in an early example of a content discovery system on Mastodon.
 Individual Mastodon servers can have an effect on the end experience of users. For example, some servers may choose to federate with some servers but not others, altering the topology of the Fediverse network for their users. At the same time, accounts need to be locked into one specific server. Because of Mastodon's data portability, users can move their accounts freely between servers while retaining their followers, though their post history remains with their original account.
 ## The Mastodon Migrations
 Mastodon saw a surge in interest in 2022 and 2023, particularly after Elon Musk's Twitter acquisition. In particular, four events of interests drove measurable increases in new users to the network: the announcement of the acquisition (April 14, 2022), the closing of the acquisition (October 27, 2022), a day when Twitter suspended a number of prominent journalists (December 15, 2022), and a day when Twitter experienced an outage and started rate limiting accounts (July 1, 2023). Many Twitter accounts announced they were setting up Mastodon accounts and linked their new accounts to their followers, often using tags like #TwitterMigration [@heFlockingMastodonTracking2023] and driving interest in Mastodon in a process @lacavaDriversSocialInfluence2023 found consistent with social influence theory.
 Some media outlets have framed reports on Mastodon [@hooverMastodonBumpNow2023] through what @zulliRethinkingSocialSocial2020 calls the "Killer Hype Cycle", whereby the media finds a new alternative social media platform, declares it a potential killer of some established platform, and later calls it a failure if it does not displace the existing platform. Such framing fails to take systems like the Fediverse seriously for their own merits: completely replacing existing commercial systems is not the only way to measure success, nor does it account for the real value the Fediverse provides for its millions of active users.
 Mastodon's approach to onboarding has also changed over time. In much of 2020 and early 2021, the Mastodon developers closed sign-ups to their flagship server and linked to an alternative server, which saw increased sign-ups during this period. They also linked to a list of servers on the "Join Mastodon" webpage [@mastodonggmbhServers], where all servers are pre-approved and follow the Mastodon Server Covenant which guarantees certain content moderation standards and data protections. Starting in 2023, the Mastodon developers shifted toward making the flagship server the default when people sign up on the official Mastodon Android and iOS apps [@rochkoNewOnboardingExperience2023; @rothItGettingEasier2023].
 ## Newcomers in Online Communities
 Onboarding newcomers is an important part of the life cycle of online communities. Any community can expect a certain amount of turnover, and so it is important for the long-term health and longevity of the community to be able to bring in new members [@krautBuildingSuccessfulOnline2011 p. 182]. However, the process of onboarding newcomers is not always straightforward.
 The series of migrations of new users into Mastodon in many ways reflect folk stories of "Eternal Septembers" on previous communication networks, where a large influx of newcomers challenged the existing norms [@driscollWeMisrememberEternal2023; @kieneSurvivingEternalSeptember2016]. Many Mastodon servers do have specific norms which people coming from Twitter may find confusing, such as local norms around content warnings [@nicholsonMastodonRulesCharacterizing2023]. Variation among servers can also present a challenge for newcomers who may not even be aware of the specific rules, norms, or general topics of interest on the server they are joining [@diazUsingMastodonWay2022]. Mastodon servers open to new accounts must thus be both accommodating to newcomers while at the same ensuring the propagation of their norms and culture, either through social norms or through technical means.
 ## Recommendation Systems and Collaborative Filtering
 Recommendation systems help people with decision-making processes by suggesting items of likely interest [@ricciRecommenderSystemsHandbook2022]. Many contemporary recommendation systems use collaborative filtering, a technique which produces new recommendations based on the preferences of a collection of similar users [@korenAdvancesCollaborativeFiltering2022]. Such systems can be effective at offering relevant suggestions; however, collaborative systems must also deal with the "cold start" problem, where new users have no data to base recommendations on. The cold start problem has three possible facets: boostrapping new communities, dealing with new items, and handling new users. In each case, limited data on the entity makes it impossible to find similar entities without some way of building a profile. Collaborative filtering often also produces a popularity bias where more items enjoyed by a wide range of users receive more recommendations than more obscure but possibly more relevant items.
 Collaborative filtering has the added benefit of producing a matches between both similar users and similar items. That is, a collaborative filtering system can find items similar to each other based on having shared users, but it can also find similar users via shared items.
 Serveral approaches to collaborative filtering have become commonplace. Many of these use dimensionality reduction, which compress the space 
 This is particularly useful because the matrix of items and users tends to be extremely sparse, e.g. in a movie recommendor system, most people have not seen most of the movies in the database. Singular value decomposition (SVD) is one such dimension reduction technique which transforms a $m \times n$ matrix $M$ into the form $M = U\SigmaV\subset{T}$. 
 In the Mastodon context, the cold start problem has two possible facets: there is no information on new servers and there is also no information on new users. New servers are thus likely prone to falling for popularity bias: there is simply more data on larger servers. A common strategy to deal with new users is to ask for some intitial preferences to create an initial workable user profile.
 The decentralized web presents unique challenges for recommendation systems. Centralized recommendation systems can collect data from all users and use this data to make recommendations. However, this is less desirable on the decentralized web, where data is spread across many servers and users may not want to share their data with a central authority.
 ## Evaluation of Recommendation Systems
 Determining the effectiveness of a recommendation system can be tricky because there are usually multiple factors involved [@zangerleEvaluatingRecommenderSystems2022].
 Creators of recommendation systems often decompose evalution into two parts: system-centric evalution and user-centered evalution.
 # Data
 ```{r}
 #| label: fig-account-timeline
 #| fig-cap: "Accounts in the dataset created between January 2022 and March 2023. The top panels shows the proportion of accounts still active 45 days after creation, the proportion of accounts that have moved, and the proportion of accounts that have been suspended. The bottom panel shows the count of accounts created each week. The dashed vertical lines in the bottom panel represent the annoucement day of the Elon Musk Twitter acquisition, the acquisition closing day, a day where Twitter suspended a number of prominent journalist, and a day when Twitter experienced an outage and started rate limiting accounts."
 #| fig-height: 2.75
 #| fig-width: 6.75
 #| fig-env: figure*
 #| fig-pos: tb!
 library(here)
 source(here("code/helpers.R"))
 account_timeline_plot()
 ```
 Mastodon has an extensive API which allows for the collection of public posts and account information. We collected data from the public timelines of Mastodon servers using the Mastodon API with a crawler which runs once per day. We also collected account information from the opt-in public profile directories on these servers.
 ```{r}
 #| label: data-counts
 #| cache: true
 library(arrow)
 library(tidyverse)
 library(here)
 source(here("code/helpers.R"))
 accounts <- load_accounts(filt = FALSE) %>%
  filter(created_at >= "2020-08-14") %>%
  filter(created_at < "2024-01-01")
 tag_posts <- "data/scratch/all_tag_posts.feather" %>% 
  arrow::read_ipc_file(. , col_select = c("host", "acct", "created_at")) %>%
  filter(created_at >= as.Date("2023-05-01")) %>%
  filter(created_at < as.Date("2023-08-01"))
 text_format <- function(df) {
  return (format(nrow(df), big.mark=","))
 }
 num_tag_posts <- tag_posts %>% text_format()
 num_tag_accounts <- tag_posts %>% distinct(host, acct) %>% text_format()
 num_tag_servers <- tag_posts %>% distinct(host) %>% text_format()
 num_accounts_unfilt <- accounts %>% text_format()
 num_account_bots <- accounts %>% filter(bot) %>% text_format()
 num_account_nostatuses <- accounts %>% filter(is.na(last_status_at)) %>% text_format()
 num_account_suspended <- accounts %>% mutate(suspended = replace_na(suspended, FALSE)) %>% filter(suspended) %>% text_format()
 num_accounts_moved <- accounts %>% filter(has_moved) %>% text_format()
 num_account_limited <- accounts %>% filter(limited) %>% text_format()
 num_account_samedaystatus <- accounts %>% filter(last_status_at <= created_at) %>% text_format()
 num_account_filt <- load_accounts(filt = TRUE) %>% text_format()
 ```
 **Mastodon Profiles**: We collected accounts using data previously collected from posts on public Mastodon timelines from October 2020 to August 2023. We then queried for up-to-date information on those accounts including their most recent status and if the account had moved as of February 2024. Through this process, we discovered a total of `r num_accounts_unfilt` account created between August 14, 2020 and January 1, 2024. We then filtered out accounts which were bots (`r num_account_bots` accounts), had been suspended (`r num_account_suspended` accounts), had been marked as moved to another account (`r num_accounts_moved` accounts), had been limited by their local server (`r num_account_limited` accounts), had no statuses (`r num_account_nostatuses` accounts), or had posted their last status on the same day as their account creation (`r num_account_samedaystatus` accounts). This gave us a total of `r num_account_filt` accounts which met all the filtering criteria. Note that because we got updated information on each account, we include only accounts on servers which still existed at the time of our profile queries and which returned records for the account.
 **Tags**: Mastodon supports hashtags, which are user-generated metadata tags that can be added to posts. Clicking the link for a tag shows a stream of posts which also have that tag from the federated timeline, which includes accounts on the same server and posts from accounts followed by the accounts on the local server. We collected `r num_tag_posts` statuses posted by `r num_tag_accounts` accounts on `r num_tag_servers` unique servers from between May to July 2023 which contained at least one hashtag.
 # Analysis and Results
 ## Survival Model
 *Are accounts on suggested general servers less likely to remain active than accounts on other servers?*
 ```{r, cache.extra = tools::md5sum("code/survival.R")}
 #| cache: true
 #| label: fig-survival
 #| fig-env: figure
 #| fig-cap: "Survival probabilities for accounts created during May 2023."
 #| fig-width: 3.375
 #| fig-height: 2.5
 #| fig-pos: h!
 library(here)
 source(here("code/survival.R"))
 plot_km 
 ```
 ```{r}
 #| label: table-coxme
 library(ehahelper)
 library(broom)
 cxme_table <- tidy(cxme) %>%
  mutate(conf.low = exp(conf.low), conf.high=exp(conf.high)) %>%
  mutate(term = case_when(
    term == "factor(group)1" ~ "Join Mastodon",
    term == "factor(group)2" ~ "General Servers",
    term == "small_serverTRUE" ~ "Small Server",
    TRUE ~ term
  )) %>%
  mutate(exp.coef = paste("(", round(conf.low, 2), ", ", round(conf.high, 2), ")", sep="")) %>%
  select(term, estimate, exp.coef , p.value)
 ```
 Using `r text_format(sel_a)` accounts created from May 1 to June 30, 2023, we create a Kaplan–Meier estimator for the probability that an account will remain active based on whether the account is on one of the largest general instances [^1] featured at the top of the Join Mastodon webpage or otherwise if it is on a server in the Join Mastodon list. Accounts are considered active if they have made at least one post after the censorship period `r active_period` days after account creation.
 [^1]: `r paste(general_servers, collapse=", ")`
 ::: {.content-visible unless-profile="icwsm"}
 ::: {#tbl-cxme .column-body}
 ```{r}
 if (knitr::is_latex_output()) {
  cxme_table %>% knitr::kable(format="latex", booktabs=TRUE, digits=3)
 } else {
  cxme_table %>% knitr::kable(digits = 3)
 }
 ```
 Coefficients for the Cox Proportional Hazard Model with Mixed Effects. The model includes a random effect for the server.
 :::
 We also construct a Mixed Effects Cox Proportional Hazard Model
 $$
 h(t_{ij}) = h_0(t) \exp\left(\begin{aligned}
  &\beta_1 \text{Join Mastodon} \\
  &+ \beta_2 \text{General Servers} \\
  &+ \beta_3 \text{Small Server} \\
  &+ b_{j}
 \end{aligned}\right)
 $$
 where $h(t_{ij})$ is the hazard for account $i$ on server $j$ at time $t$, $h_0(t)$ is the baseline hazard, $\beta_1$ is the coefficient for whether the account is on a server featured on Join Mastodon, $\beta_2$ is the coefficient for whether the account is on one of the largest general instances, $\beta_3$ is the coefficient for whether the account is on a small server with less than 100 accounts, and $b_{j}$ is the random effect for server $j$.
 <!-- with coefficients for whether the account is on a small server (less than a hundred accounts), and whether the account in featured on JoinMastodon or is featured as one of the largest general instances. -->
 We again find that accounts on the largest general instances are less likely to remain active than accounts on other servers, while accounts created on smaller servers are more likely to remain active.
 :::
 ## Moved Accounts
 *Do accounts tend to move to larger or smaller servers?*
 Mastodon users can move their accounts to another server while retaining their connections (but not their posts) to other Mastodon accounts. This feature, built into the Mastodon software, offers data portability and helps avoid lock-in.
 ```{r}
 #| label: table-ergm-table
 #| echo: false
 #| warning: false
 #| message: false
 #| error: false
 library(here)
 library(modelsummary)
 library(kableExtra)
 library(purrr)
 library(stringr)
 load(file = here("data/scratch/ergm-model-early.rda"))
 load(file = here("data/scratch/ergm-model-late.rda"))
 if (knitr::is_latex_output()) {
  format <- "latex_tabular"
 } else {
  format <- "html"
 }
 x <- modelsummary(
  list("Coef." = model.early, "Std.Error" = model.early, "Coef." = model.late, "Std.Error" = model.late),
  estimate = c("{estimate}", "{stars}{std.error}", "{estimate}", "{stars}{std.error}"),
  statistic = NULL,
  gof_omit = ".*",
  coef_rename = c(
    "sum" = "Sum",
    "nonzero" = "Nonzero",
    "diff.sum0.h-t.accounts" = "Smaller server",
    "nodeocov.sum.accounts" = "Server size\n(outgoing)",
    "nodeifactor.sum.registrations.TRUE" = "Open registrations\n(incoming)",
    "nodematch.sum.language" = "Languages match"
  ),
  align="lrrrr",
  stars = c('*' = .05, '**' = 0.01, '***' = .001),
  output = format
  ) %>% add_header_above(c(" " = 1, "Model A" = 2, "Model B" = 2))
 ```
 :::: {#tbl-ergm-table `r class_wide`}
 ```{r}
 x
 ```
 Exponential family random graph models for account movement between Mastodon servers. Accounts in Model A were created in May 2022 and moved to another account at some later point. Accounts in Model B were created at some earlier point and moved after October 2023.
 ::::
 To corroborate our findings, we also use data from thousands of accounts which moved between Mastodon servers, taking advantage of the data portability of the platform. Conceiving of these moved accounts as edges within a weighted directional network where nodes represent servers, edges represent accounts, and weights represent the number of accounts that moved between servers, we construct an exponential family random graph model (ERGM) with terms for server size, open registrations, and language match between servers. We find that accounts are more likely to move from larger servers to smaller servers.
 # Proposed Recommendation System
 *How can we build an opt-in, low-resource recommendation system for finding Fediverse servers?*
 Based on these findings, we suggest a need for better ways for newcomers to find servers and propose a viable way to create server and tag recommendations on Mastodon. This system could both help newcomers find servers that match their interests and help established accounts discover "neighborhoods" of related servers.
 ## Constraints and Evaluation
 One challenge in building such a system is the decentralized nature of the system. A single, central actor which collects data from servers and then distributes recommendations would be antithetical to the decentralized nature of Mastodon. Instead, we propose a system where servers can report the top hashtags by the number of unique accounts on the server using them during the last three months. Such a system would be opt-in and require few additional server resources since tags already have their own database table.
 We evaluate the system in part using the accounts which moved between servers. Based on their posting history (e.g. hashtags), can the recommendations system predict where they will move to?
 ## Recommendation System Design
 ### Similarity Matrix
 We use Okapi BM25 to construct a term frequency-inverse document frequency (TF-IDF) model to associate the top tags with each server using counts of tag-account pairs from each server for the term frequency and the number of servers that use each tag for the inverse document frequency. We then L2 normalize the vectors for each tag and calculate the cosine similarity between the tag vectors for each server.
 $$
 tf = \frac{f_{t,s} \cdot (k_1 + 1)}{f_{t,s} + k_1 \cdot (1 - b + b \cdot \frac{|s|}{avgstl})}
 $$
 where $f_{t,s}$ is the number of accounts using the tag $t$ on server $d$, $k_1$ and $b$ are tuning parameters, and $avgstl$ is the average sum of account-tag pairs. For the inverse document frequency, we use the following formula: 
 $$
 idf = \log \frac{N - n + 0.5}{n + 0.5}
 $$
 where $N$ is the total number of servers and $n$ is the number of servers where the tag appears as one of the top tags. We then apply L2 normalization:
 $$
 tfidf = \frac{tf \cdot idf}{\| tf \cdot idf \|_2}
 $$
 ### Recommendation System
 We then used the normalized TF-IDF matrix to produce recommendations using SVD.
 ## Applications
 ```{r}
 #| eval: false
 library(tidyverse)
 library(igraph)
 library(arrow)
 sim_servers <- "data/scratch/server_similarity.feather" %>% arrow::read_ipc_file() %>% rename("weight" = "Similarity")
 #sim_net <- as.network(sim_servers)
 g <- graph_from_data_frame(sim_servers, directed = FALSE)
 g_strength <- log(sort(strength(g)))
 normalized_strength <- (g_strength - min(g_strength)) / (max(g_strength) - min(g_strength))
 server_centrality <- enframe(normalized_strength, name="server", value="strength")
 server_centrality %>% arrow::write_ipc_file("data/scratch/server_centrality.feather")
 ```
 ### Server Similarity Neighborhoods
 Mastodon provides two feeds in addition to a user's home timeline populated by accounts they follow: a local timeline with all public posts from their local server and a federated timeline which includes all posts from users followed by other users on their server. We suggest a third kind of timeline, a *neighborhood timeline*, which filters the federated timeline by topic.
 We calculate the pairwise similarity between two servers with TF-IDF vectors $A$ and $B$ using cosine similarity:
 $$
 \text{similarity}(A, B) = \frac{A \cdot B}{\|A\| \|B\|}
 $$
 ::: {#tbl-sim-servers .content-visible unless-profile="icwsm"}
 ```{r}
 #| label: table-sim-servers
 library(tidyverse)
 library(arrow)
 sim_servers <- "data/scratch/server_similarity.feather" %>% arrow::read_ipc_file() 
 server_of_interest <- "hci.social"
 server_table <- sim_servers %>%
    arrange(desc(Similarity)) %>%
    filter(Source == server_of_interest | Target == server_of_interest) %>%
    head(5) %>%
    pivot_longer(cols=c(Source, Target)) %>%
    filter(value != server_of_interest) %>%
    select(value, Similarity) %>%
    rename("Server" = "value")
 if (knitr::is_latex_output()) {
  server_table %>% knitr::kable(format="latex", booktabs=TRUE, digits=3)
 } else {
  server_table %>% knitr::kable(digits = 3)
 }
 ```
 Top five servers most similar to hci.social
 :::
 ### Server Discovery
 Given a set of popular tags and a list of servers, we build a recommendation system where users select tags from a list of popular tags and receive server suggestions. The system first creates a subset of vectors based on the TF-IDF matrix which represents the top clusters of topics. After a user selects the top tags of interest to them, it suggests servers which match their preferences.
 ### Tag Similarity
 We also calculate the similarity between tags using the same method. This can be used to suggest related tags to users based on their interests.
 ::: {.content-visible unless-profile="icwsm"}
 ## Rubustness to Limited Data
 ```{r}
 #| label: fig-simulations-rbo
 #| fig-env: figure*
 #| cache: true
 #| fig-width: 6.75
 #| fig-height: 3
 #| fig-pos: tb
 library(tidyverse)
 library(arrow)
 simulations <- arrow::read_ipc_file("data/scratch/simulation_rbo.feather")
 simulations %>%
  group_by(servers, tags, run) %>% summarize(rbo=mean(rbo), .groups="drop") %>%
  mutate(ltags = as.integer(log2(tags))) %>%
  ggplot(aes(x = factor(ltags), y = rbo, fill = factor(ltags))) +
  geom_boxplot() +
  facet_wrap(~servers, nrow=1) +
  #scale_y_continuous(limits = c(0, 1)) +
  labs(x = "Tags (log2)", y = "RBO", title = "Rank Biased Overlap with Baseline Rankings by Number of Servers") +
  theme_minimal() + theme(legend.position = "none")
 ```
 A challenge for a federated recommendation system like we propose is that it needs buy in from a sufficient number of servers to provide value. There is also a tradeoff between the amount of tags to expose for each server and potential concerns about exposing too much data.
 We simulated various scenarios that limit both servers that report data and the number of tags they report. We used rank biased overlap (RBO) to then compare the outputs from these simulations to the baseline with more complete information from all tags on all servers [@webberSimilarityMeasureIndefinite2010]. In particular, we gave a higher weight to suggestions with a higher rank, with weights decaying by a factor of $k^{0.80}$. @fig-simulations-rbo shows how the average agreement with the baseline scales, which take the top 256 tags from each server.
 :::
 # Discussion
 The analysis can also be improved by additionally focusing on factors lead to accounts remaining active or dropping out, which a particular focus on the actual activity of accounts over time. For instance, do accounts that interact with other users more remain active longer? Are there particular markers of activity that are more predictive of account retention? Future work could use these to provide suggests for ways to helps newcomers during the onboarding process.
 The observational nature of the data limit some of the causal claims we can make. It is unclear, for instance, if accounts on general servers are less likely to remain active because of the server itself or because of the type of users who join such servers. For example, it is conceivable that the kind of person who spends more time researching which server to join is more invested in their Mastodon experience than one who simply joins the first server they find.
 ## Future Work
 Future work is necessary to determine the how well the recommendation system is at helping users find servers that match their interests. This may involve user studies and interviews to determine how well the system works in practice.
 While the work presented here is based on observed posts on the public timelines, simulations may be helpful in determining the robustness of the system to targeted attacks. Due to the decentralized nature of the system, it is feasible that a bad actor could set up zombie accounts on servers to manipulate the recommendation system. Simulations could help determine how well the system can resist such attacks and ways to mitigate this risk.
 # Conclusion
 Based on analysis of trace data from millions of new Fediverse accounts, we find evidence that suggests that servers matter and that users tend to move from larger servers to smaller servers. We then propose a recommendation system that can help new Fediverse users find servers with a high probability of being a good match based on their interests. Based on simulations, we demonstrate that such a tool can be effectively deployed in a federated manner, even with limited data on each local server.
 # References {#references}
 # Appendix {.appendix}
 ::: {.content-visible when-format="html"}
 ```{r}
 library(tidyverse)
 library(arrow)
 library(ggrepel)
 "data/scratch/server_svd.feather" %>% arrow::read_ipc_file() %>%
  as_tibble %>%
  ggplot(aes(x = x, y = y, label = server)) +
  geom_text_repel(size = 2, max.overlaps = 10) +
  #geom_point() +
  theme_minimal()
 ```
 ```{r}
 library(tidyverse)
 library(arrow)
 library(ggrepel)
 library(here)
 library(jsonlite)
 top_tags <- "data/scratch/tag_svd.feather" %>% arrow::read_ipc_file() %>%
  as_tibble %>%
  mutate(s = variance * log(count)) %>% arrange(desc(s))
 top_tags %>% 
  select(tag, index) %>%
  jsonlite::write_json(here("recommender/data/top_tags.json"))
 top_tags %>%
  head(100) %>%
  ggplot(aes(x = x, y = y, label = tag)) +
  geom_text_repel(size = 3, max.overlaps = 10) +
  #geom_point() +
  theme_minimal()
 ```
 :::
 ## Glossary {.appendix}
 *ActivityPub*: A decentralized social networking protocol based on the ActivityStreams 2.0 data format.
 *Fediverse*: A set of decentralized online social networks which interoperate using shared protocols like ActivityPub.
 *Mastodon*: An open-source, decentralized social network and microblogging community.
 *Hashtag*: A user-generated metadata tag that can be added to posts.
 *Federated timeline*: A timeline which includes all posts from users followed by other users on their server.
 *Local timeline*: A timeline with all public posts from the local server.
 ## More Evaluation
 ### User Stories
 We also illustrate the potential value of such a system with three user stories:
 **User Story 1**: Juan is a human-computer interaction researcher looking for a server to connect with colleagues and also share about his projects.
 **User Story 2** (Arthur) just wants to connect with friends and family.
 **User Story 3** (Tracy) has run a niche aesthetic blog on Tumblr for the last eight years and is curious about migrating to the Fediverse.
--- a/icwsm.qmd
+++ b/icwsm.qmd
@ -49,9 +49,9 @@ envs <- Sys.getenv()
 # Introduction
-Following Twitter's 2022 acquisition, Mastodon---an open-source, decentralized social network and microblogging community---saw an increase in activity and attention as a potential Twitter alternative [@heFlockingMastodonTracking2023; @cavaDriversSocialInfluence2023]. While millions of new accounts significantly increased the size of the network, many newcomers found the process confusing and did not remain active. Unlike centralized social media platforms, Mastodon is a network of independent servers, each with their own rules and norms [@nicholsonMastodonRulesCharacterizing2023], which can communicate with each other using the shared ActivityPub protocols. Athough accounts can move between Mastodon servers, the local experience can vary widely from server to server.
+Following Twitter's 2022 acquisition, Mastodon---an open-source, decentralized social network and microblogging community---saw an increase in activity and attention as a potential Twitter alternative [@heFlockingMastodonTracking2023; @lacavaDriversSocialInfluence2023]. While millions of new accounts significantly increased the size of the network, many newcomers found the process confusing and did not remain active. Unlike centralized social media platforms, Mastodon is a network of independent servers, each with their own rules and norms [@nicholsonMastodonRulesCharacterizing2023], which can communicate with each other using the shared ActivityPub protocols. Athough accounts can move between Mastodon servers, the local experience can vary widely from server to server.
-Attracting and retaining newcomers is a key challenge for online communities [@krautBuildingSuccessfulOnline2011 p. 182]. On Mastodon, the onboarding process has not always been straightforward: variation among servers mean newcomers who may not even be aware of the specific rules, norms, or general topics of interest on the server they are joining [@diazUsingMastodonWay2022]. Various guides and resources for people trying to join Mastodon offered mixed advice on choosing a server. Some suggest that the most important thing is to simply join any server and work from there [@krasnoffMastodon101How2022; @silberlingBeginnerGuideMastodon2023]; others have created tools and guides to help people find potential servers of interest by size and location[@thekinrarMastodonInstances; @kingMastodonMe2024].
+Attracting and retaining newcomers is a key challenge for online communities [@krautBuildingSuccessfulOnline2011 p. 182]. On Mastodon, the onboarding process has not always been straightforward: variation among servers mean newcomers who may not even be aware of the specific rules, norms, or general topics of interest on the server they are joining [@diazUsingMastodonWay2022]. Various guides and resources for people trying to join Mastodon offered mixed advice on choosing a server. Some suggest that the most important thing is to simply join any server and work from there [@krasnoffMastodon101How2022; @silberlingBeginnerGuideMastodon2023]; others have created tools and guides to help people find potential servers of interest by size and location[@thekinrarMastodonInstances2017; @kingMastodonMe2024].
 Mastodon's decentralized design has long been in tension with the disproportionate popularity of a small set of large, general-topic servers within the system [@ramanChallengesDecentralisedWeb2019a]. Analysing the activity of new accounts that join the network, we find that users who sign up on such servers are less likely to remain active after 91 days. We also find that users who move accounts tend to gravitate toward smaller, more niche servers over time, suggesting that established users may also find additional utility from such servers.
@ -65,17 +65,19 @@ The Fediverse is a set of decentralized online social networks which interoperat
 Mastodon features three kinds of timelines: a "home" timeline which shows all posts from accounts followed by the user; a "local" timeline which shows all public posts from the local server; and a "federated" timeline which includes all posts from users followed by other users on their server. The local timeline is unique to each server. On larger servers, this timeline can be unwieldy; however, on smaller servers, it presents the opportunity to discover new posts and users of potential interest.
-Discovery has been challenging on Masotodon. Text search, for instance, was impossible on most servers until support for this feature was added on an optional, opt-in basis using Elasticsearch in late 2023 [@rochkoMastodon2023]. Recommendation systems are currently a somewhat novel problem in the context of decentralized online social networks. @trienesRecommendingUsersWhom2018 developed a recommendation system for finding new accounts to follow on the Fediverse which used collaborative filtering based on BM25 in an early example of a content discovery system on Mastodon.
+Discovery has been challenging on Mastodon. Text search, for instance, was impossible on most servers until support for this feature was added on an optional, opt-in basis using Elasticsearch in late 2023 [@rochkoMastodon2023]. Recommendation systems are currently a somewhat novel problem in the context of decentralized online social networks. @trienesRecommendingUsersWhom2018 developed a recommendation system for finding new accounts to follow on the Fediverse which used collaborative filtering based on BM25 in an early example of a content discovery system on Mastodon.
 Individual Mastodon servers can have an effect on the end experience of users. For example, some servers may choose to federate with some servers but not others, altering the topology of the Fediverse network for their users. At the same time, accounts need to be locked into one specific server. Because of Mastodon's data portability, users can move their accounts freely between servers while retaining their followers, though their post history remains with their original account.
 ## The Mastodon Migrations
-Mastodon saw a surge in interest in 2022 and 2023, particularly after Elon Musk's Twitter acquisition. In particular, four events of interests drove measurable increases in new users to the network: the announcement of the acquisition (April 14, 2022), the closing of the acquisition (October 27, 2022), a day when Twitter suspended a number of prominent journalists (December 15, 2022), and a day when Twitter experienced an outage and started rate limiting accounts (July 1, 2023). Many Twitter accounts announced they were setting up Mastodon accounts and linked their new accounts to their followers, often using tags like #TwitterMigration [@heFlockingMastodonTracking2023] and driving interest in Mastodon in a process @cavaDriversSocialInfluence2023 found consistent with social influence theory.
+Mastodon saw a surge in interest in 2022 and 2023, particularly after Elon Musk's Twitter acquisition. In particular, four events of interests drove measurable increases in new users to the network: the announcement of the acquisition (April 14, 2022), the closing of the acquisition (October 27, 2022), a day when Twitter suspended a number of prominent journalists (December 15, 2022), and a day when Twitter experienced an outage and started rate limiting accounts (July 1, 2023). Many Twitter accounts announced they were setting up Mastodon accounts and linked their new accounts to their followers, often using tags like #TwitterMigration [@heFlockingMastodonTracking2023] and driving interest in Mastodon in a process @lacavaDriversSocialInfluence2023 found consistent with social influence theory.
-Some media outlets have framed reports on Mastodon [@hooverMastodonBumpNow2023] through what @zulliRethinkingSocialSocial2020 calls the "Killer Hype Cycle", whereby the media finds a new alternative social media platform, declares it a potential killer of some established platform, and later calls it a failure if it does not displace the existing platform. Such framing fails to take systems like the Fediverse seriously for their own merits: completely replacing existing commercial systems is not the only way to measure success, nor does it account for the real value the Fediverse provides for its millions of active users.
+Despite the influx of users, not all of these new accounts remained active. As such, some media outlets have framed reports on Mastodon [@hooverMastodonBumpNow2023] through what @zulliRethinkingSocialSocial2020 calls the "Killer Hype Cycle", whereby the media finds a new alternative social media platform, declares it a potential killer of some established platform, and later calls it a failure if it does not displace the existing platform. Such framing fails to take systems like the Fediverse seriously for their own merits: completely replacing existing commercial systems is not the only way to measure success, nor does it account for the real value the Fediverse provides for its millions of active users.
-Mastodon's approach to onboarding has also changed over time. In much of 2020 and early 2021, the Mastodon developers closed sign-ups to their flagship server and linked to an alternative server, which saw increased sign-ups during this period. They also linked to a list of servers on the "Join Mastodon" webpage [@mastodonggmbhServers], where all servers are pre-approved and follow the Mastodon Server Covenant which guarantees certain content moderation standards and data protections. Starting in 2023, the Mastodon developers shifted toward making the flagship server the default when people sign up on the official Mastodon Android and iOS apps [@rochkoNewOnboardingExperience2023; @rothItGettingEasier2023].
+Mastodon's approach to onboarding has changed over time. In much of 2020 and early 2021, the Mastodon developers closed sign-ups to their flagship server and linked to an alternative server, which saw increased sign-ups during this period. They also linked to a list of servers on the "Join Mastodon" webpage[^2], where all servers are pre-approved and follow the Mastodon Server Covenant which guarantees certain content moderation standards and data protections. Starting in 2023, the Mastodon developers shifted toward making the flagship server the default when people sign up on the official Mastodon Android and iOS apps [@rochkoNewOnboardingExperience2023; @rothItGettingEasier2023]. These changes suggest that removing friction to onboarding is an increasing priority for the Mastodon developers.
 [^2]: https://joinmastodon.org/servers
 ## Newcomers in Online Communities
@ -363,7 +365,7 @@ We also calculate the similarity between tags using the same method. This can be
 Given a set of popular tags and a list of servers, we build a recommendation system[^rec] where users select tags from a list of popular tags and receive server suggestions. The system first creates a subset of vectors based on the TF-IDF matrix which represents the top clusters of topics. After a user selects the top tags of interest to them, it suggests servers which match their preferences using the singular value decomposition (SVD) of the TF-IDF matrix.
-[^rec]: A live demo for the system is availible at https://cheesecake.live/files/jsdemo/witch.html
+[^rec]: A live demo for the system is availible at https://carlcolglazier.com/demos/deweb2024/
 ::: {.content-visible unless-profile="icwsm"}
--- a/references.bib
+++ b/references.bib
@ -53,22 +53,6 @@
  isbn = {978-1-60558-246-7}
 }
@article{cavaDriversSocialInfluence2023,
  title = {Drivers of Social Influence in the {{Twitter}} Migration to {{Mastodon}}},
  author = {Cava, Lucio La and Aiello, Luca Maria and Tagarelli, Andrea},
  year = {2023},
  month = dec,
  journal = {Scientific Reports},
  volume = {13},
  number = {1},
  pages = {21626},
  issn = {2045-2322},
  doi = {10.1038/s41598-023-48200-7},
  urldate = {2024-02-02},
  abstract = {The migration of Twitter users to Mastodon following Elon Musk's acquisition presents a unique opportunity to study collective behavior and gain insights into the drivers of coordinated behavior in online media. We analyzed the social network and the public conversations of about 75,000 migrated users and observed that the temporal trace of their migrations is compatible with a phenomenon of social influence, as described by a compartmental epidemic model of information diffusion. Drawing from prior research on behavioral change, we delved into the factors that account for variations of the effectiveness of the influence process across different Twitter communities. Communities in which the influence process unfolded more rapidly exhibit lower density of social connections, higher levels of signaled commitment to migrating, and more emphasis on shared identity and exchange of factual knowledge in the community discussion. These factors account collectively for 57\% of the variance in the observed data. Our results highlight the joint importance of network structure, commitment, and psycho-linguistic aspects of social interactions in characterizing grassroots collective action, and contribute to deepen our understanding of the mechanisms that drive processes of behavior change of online groups.},
  langid = {english}
 }
@misc{diazUsingMastodonWay2022,
  title = {Using {{Mastodon}} Is Way Too Complicated to Ever Topple {{Twitter}}},
  author = {Diaz, Jesus},
@ -206,13 +190,26 @@
  title = {Mastodon {{Near Me}}},
  author = {King, Jaz-Michael},
  year = {2024},
  month = jan,
  journal = {jaz-michael king},
  urldate = {2024-03-04},
  abstract = {A map and data directory showcasing ActivityPub service providers, each specifically catering to a certain locality or offering support in a notable language.},
  langid = {english}
 }
@incollection{korenAdvancesCollaborativeFiltering2022,
  title = {Advances in {{Collaborative Filtering}}},
  booktitle = {Recommender Systems Handbook},
  author = {Koren, Yehuda and Rendle, Steffen and Bell, Robert},
  editor = {Ricci, Francesco and Ro{\d k}a{\d h}, Liʾor and Shapira, Bracha},
  year = {2022},
  edition = {Third edition},
  pages = {91--142},
  publisher = {Springer},
  address = {New York, NY},
  isbn = {978-1-07-162196-7 978-1-07-162199-8},
  langid = {english}
 }
@misc{krasnoffMastodon101How2022,
  title = {Mastodon 101: How to Follow (and Unfollow) Other Accounts},
  shorttitle = {Mastodon 101},
@ -239,6 +236,22 @@
  keywords = {Computer networks,internet,Online social networks,Planning,Social aspects,Social aspects Planning,Social psychology}
 }
@article{lacavaDriversSocialInfluence2023,
  title = {Drivers of Social Influence in the {{Twitter}} Migration to {{Mastodon}}},
  author = {La Cava, Lucio and Aiello, Luca Maria and Tagarelli, Andrea},
  year = {2023},
  month = dec,
  journal = {Scientific Reports},
  volume = {13},
  number = {1},
  pages = {21626},
  issn = {2045-2322},
  doi = {10.1038/s41598-023-48200-7},
  urldate = {2024-02-02},
  abstract = {The migration of Twitter users to Mastodon following Elon Musk's acquisition presents a unique opportunity to study collective behavior and gain insights into the drivers of coordinated behavior in online media. We analyzed the social network and the public conversations of about 75,000 migrated users and observed that the temporal trace of their migrations is compatible with a phenomenon of social influence, as described by a compartmental epidemic model of information diffusion. Drawing from prior research on behavioral change, we delved into the factors that account for variations of the effectiveness of the influence process across different Twitter communities. Communities in which the influence process unfolded more rapidly exhibit lower density of social connections, higher levels of signaled commitment to migrating, and more emphasis on shared identity and exchange of factual knowledge in the community discussion. These factors account collectively for 57\% of the variance in the observed data. Our results highlight the joint importance of network structure, commitment, and psycho-linguistic aspects of social interactions in characterizing grassroots collective action, and contribute to deepen our understanding of the mechanisms that drive processes of behavior change of online groups.},
  langid = {english}
 }
@misc{masnickProtocolsNotPlatforms,
  title = {Protocols, {{Not Platforms}}: {{A Technological Approach}} to {{Free Speech}}},
  shorttitle = {Protocols, {{Not Platforms}}},
@ -305,6 +318,18 @@
  isbn = {978-1-4503-6948-0}
 }
@book{ricciRecommenderSystemsHandbook2022,
  title = {Recommender Systems Handbook},
  editor = {Ricci, Francesco and Ro{\d k}a{\d h}, Liʾor and Shapira, Bracha},
  year = {2022},
  edition = {Third edition},
  publisher = {Springer},
  address = {New York, NY},
  abstract = {This third edition handbook describes in detail the classical methods as well as extensions and novel approaches that were more recently introduced within this field. It consists of five parts: general recommendation techniques, special recommendation techniques, value and impact of recommender systems, human computer interaction, and applications. The first part presents the most popular and fundamental techniques currently used for building recommender systems, such as collaborative filtering, semantic-based methods, recommender systems based on implicit feedback, neural networks and context-aware methods. The second part of this handbook introduces more advanced recommendation techniques, such as session-based recommender systems, adversarial machine learning for recommender systems, group recommendation techniques, reciprocal recommenders systems, natural language techniques for recommender systems and cross-domain approaches to recommender systems. The third part covers a wide perspective to the evaluation of recommender systems with papers on methods for evaluating recommender systems, their value and impact, the multi-stakeholder perspective of recommender systems, the analysis of the fairness, novelty and diversity in recommender systems. The fourth part contains a few chapters on the human computer dimension of recommender systems, with research on the role of explanation, the user personality and how to effectively support individual and group decision with recommender systems. The last part focusses on application in several important areas, such as, food, music, fashion and multimedia recommendation. This informative third edition handbook provides a comprehensive, yet concise and convenient reference source to recommender systems for researchers and advanced-level students focused on computer science and data science. Professionals working in data analytics that are using recommendation and personalization techniques will also find this handbook a useful tool},
  isbn = {978-1-07-162196-7 978-1-07-162199-8},
  langid = {english}
 }
@misc{rochkoMastodon2023,
  title = {Mastodon 4.2},
  author = {Rochko, Eugen},
@ -339,6 +364,21 @@
  langid = {english}
 }
@inproceedings{sarwarItembasedCollaborativeFiltering2001,
  title = {Item-Based Collaborative Filtering Recommendation Algorithms},
  booktitle = {Proceedings of the 10th International Conference on {{World Wide Web}}},
  author = {Sarwar, Badrul and Karypis, George and Konstan, Joseph and Riedl, John},
  year = {2001},
  month = apr,
  series = {{{WWW}} '01},
  pages = {285--295},
  publisher = {Association for Computing Machinery},
  address = {New York, NY, USA},
  doi = {10.1145/371920.372071},
  urldate = {2024-05-07},
  isbn = {978-1-58113-348-6}
 }
@misc{silberlingBeginnerGuideMastodon2023,
  title = {A Beginner's Guide to {{Mastodon}}, the Open Source {{Twitter}} Alternative {\textbar} {{TechCrunch}}},
  author = {Silberling, Amanda},
@ -364,9 +404,10 @@
  keywords = {Computer Science - Human-Computer Interaction,Computer Science - Social and Information Networks}
 }
-@misc{thekinrarMastodonInstances,
+@misc{thekinrarMastodonInstances2017,
  title = {Mastodon Instances},
  author = {TheKinrar},
  year = {2017},
  journal = {instances.social},
  urldate = {2024-03-04},
  howpublished = {https://instances.social/}
@ -405,6 +446,23 @@
  keywords = {probabilistic models,Rank correlation,ranking}
 }
@article{zangerleEvaluatingRecommenderSystems2022,
  title = {Evaluating {{Recommender Systems}}: {{Survey}} and {{Framework}}},
  shorttitle = {Evaluating {{Recommender Systems}}},
  author = {Zangerle, Eva and Bauer, Christine},
  year = {2022},
  month = dec,
  journal = {ACM Computing Surveys},
  volume = {55},
  number = {8},
  pages = {170:1--170:38},
  issn = {0360-0300},
  doi = {10.1145/3556536},
  urldate = {2024-05-07},
  abstract = {The comprehensive evaluation of the performance of a recommender system is a complex endeavor: many facets need to be considered in configuring an adequate and effective evaluation setting. Such facets include, for instance, defining the specific goals of the evaluation, choosing an evaluation method, underlying data, and suitable evaluation metrics. In this article, we consolidate and systematically organize this dispersed knowledge on recommender systems evaluation. We introduce the Framework for Evaluating Recommender systems (FEVR), which we derive from the discourse on recommender systems evaluation. In FEVR, we categorize the evaluation space of recommender systems evaluation. We postulate that the comprehensive evaluation of a recommender system frequently requires considering multiple facets and perspectives in the evaluation. The FEVR framework provides a structured foundation to adopt adequate evaluation configurations that encompass this required multi-facetedness and provides the basis to advance in the field. We outline and discuss the challenges of a comprehensive evaluation of recommender systems and provide an outlook on what we need to embrace and do to move forward as a research community.},
  keywords = {FEVR,Framework for EValuating Recommender systems,Survey}
 }
@article{zulliRethinkingSocialSocial2020,
  title = {Rethinking the ``Social'' in ``Social Media'': {{Insights}} into Topology, Abstraction, and Scale on the {{Mastodon}} Social Network},
  shorttitle = {Rethinking the ``Social'' in ``Social Media''},