Challenges in the Decentralised Web: The Mastodon Case
| Key | Value |
|---|---|
| Author | Raman et. al |
| Year | 2019 |
| Link |
# Summary
- Focus on availability of posts in a federated setting
- Account level
- Instance level
- Resource provider level
- Key statistics
- Instance Growth
- Instance Categories
- Instance Hosting
- Countries
- Autonomous System
- Instance Availability
- Outage Reasons
- Outage Durations
- Federation Graph
- Impact of Removing Users From Social Graph
- Impact of Removing Instances from Instance Federation Graph
- Impact of Removing Autonomous Systems from AS Graph
- Content Federation
- Prevalence of remote posts
- Replication strategies to make Federation Graph more robust
- No Replication
- Subscription-based replication
- Random replication
# Extracted Notes
first, their open source software allows anybody to setup independent servers (“instances”) that people can sign-up to and use within a local community; and second, they build on top of federation protocols so that instances can mesh together, in a peer-to-peer fashion, to offer a globally integrated platform. [@65RK2WI8#Raman_Etal_2019, p. 1]
identifying key challenges that might disrupt continuing efforts to decentralise the web [@65RK2WI8#Raman_Etal_2019, p. 1]
properties that are creating natural pressures towards recentralisation. [@65RK2WI8#Raman_Etal_2019, p. 1]
aimed at providing greater transparency, openness, and democracy on the web [@65RK2WI8#Raman_Etal_2019, p. 1]
decompose their service offerings into independent servers (“instances”) that anybody can easily bootstrap [@65RK2WI8#Raman_Etal_2019, p. 1]
also allow cross-instance interaction via the second innovation, i.e., federation. T [@65RK2WI8#Raman_Etal_2019, p. 1]
Not really true, makes it easier in some ways. [@65RK2WI8#Raman_Etal_2019, p. 1]
data is spread among many independent instances, thus possibly making privacy-intrusive data mining more difficult. [@65RK2WI8#Raman_Etal_2019, p. 1]
Data ownership is more transparent, and the lack of centralisation could make the overall system more robust against technical, legal or regulatory attacks. [@65RK2WI8#Raman_Etal_2019, p. 1]
natural pressures towards centralisation in both social [12, 50] and economic [43] systems. [@65RK2WI8#Raman_Etal_2019, p. 1]
unclear how such systems can securely scale-up, how widearea malicious activity might be detected (e.g., spam bots), or how users can be protected from data loss during instance outages/failures. [@65RK2WI8#Raman_Etal_2019, p. 1]
L. Schwittmann, C. Boelmann, M. Wander, and T. Weis. SoNetPrivacy and Replication in Federated Online Social Networks. In Distributed Computing Systems Workshops, 2013. [@65RK2WI8#Raman_Etal_2019, p. 13]
We use a 15-month dataset covering Mastodon’s instance-level and user-level activity, covering 67 million toots. [@65RK2WI8#Raman_Etal_2019, p. 1]
We explore the deployment and nature of instances, and how the uncoordinated nature of instance administrators drive system behaviours (Section 4); and (ii) We measure how federation impacts these properties, and introduces unstudied availability challenges (Section 5). [@65RK2WI8#Raman_Etal_2019, p. 1]
small subset of administrators have a disproportionate impact on the federated system. [@65RK2WI8#Raman_Etal_2019, p. 2]
0% of instances host almost half of the users. [@65RK2WI8#Raman_Etal_2019, p. 2]
11% of instances are unavailable for half of our measurement period. [@65RK2WI8#Raman_Etal_2019, p. 2]
notable co-location of instances within a small set of hosting providers. We find that failures in these ASes can create a ripple effect that fragments the wider federated graph. For example, the Largest Connected Component (LCC) in the social follower graph reduces from 92% of all users to 46% by outages in five ASes [@65RK2WI8#Raman_Etal_2019, p. 2]
Due to the differing popularities of toots, we find that outages in just 10 instances could remove 62.69% of global toots. To ameliorate this problem, we explore the potential of building toot replication schemes. For example, when a user has followers from different instances, the content posted by the user could be stored and indexed (persistently) in the followers’ instances. By enabling this type of federation-based replication, availability improves so that only 11.4% of toots are lost when the top 3 ASes are offline (rather than 70% without). [@65RK2WI8#Raman_Etal_2019, p. 2]
nice summary [@65RK2WI8#Raman_Etal_2019, p. 2]
his process is implemented using an underlying subscription protocol. To date, Mastodon supports two open protocols: oStatus [37] and ActivityPub [1] (starting from v1.6). [@65RK2WI8#Raman_Etal_2019, p. 2]
Instances: regular snapshots of instance metadata and availability; (ii) Toots: historical user posts (toots) available on each instance; and (iii) Graphs: the follower and federation graphs. [@65RK2WI8#Raman_Etal_2019, p. 2]
This site contains a comprehensive index of instances around the world, allowing us to compile a set of 4,328 unique instances (identified by their domain). [@65RK2WI8#Raman_Etal_2019, p. 2]
public toots [@65RK2WI8#Raman_Etal_2019, p. 3]
ollected their entire history of toots. [@65RK2WI8#Raman_Etal_2019, p. 3]
e find that our dataset covers 62% of the entire toot population. The remaining 38% of toots could not be collected: approximately 20% of these toots were set to private, and the remainder were hosted on instances that blocked toot crawling. [@65RK2WI8#Raman_Etal_2019, p. 3]
Not true since accounts a move (and indicate so) [@65RK2WI8#Raman_Etal_2019, p. 3]
Note that it is impossible to infer if such accounts are owned by the same person and therefore we treat them as separate nodes. [@65RK2WI8#Raman_Etal_2019, p. 3]
However, we have exclusively collected public toot data, followed well established ethical procedures for social data, and obtained a waiver from the ethics committee at Queen Mary University of London. All data is anonymised before usage, it is stored within a secure silo, and we have removed text content from our analysis. [@65RK2WI8#Raman_Etal_2019, p. 3]
growth and popularity of the 4,328 instances under study, and inspect how this relates to instance settings. [@65RK2WI8#Raman_Etal_2019, p. 3]
the #DeleteFacebook campaign (popular at that time) [45], and sporadic bursts of media attention [@65RK2WI8#Raman_Etal_2019, p. 4]
iring an explicit invitation from the administrator (52.2%). Figure 2(a) presents a CDF of the number of users and toots per-instance, separated into open and closed instances. [@65RK2WI8#Raman_Etal_2019, p. 4]
majority of instances are categorised as tech (55.2%), games (37.3%) or art (30.15%). This is not entirely surprising, as Mastodon emerged from the tech community. [@65RK2WI8#Raman_Etal_2019, p. 4]
Unsurprisingly, instances with an open registration process have substantially more users (mean 613 vs. 87). [@65RK2WI8#Raman_Etal_2019, p. 4]
hereas the majority of users are associated with open instances, they create on average 94.8 toots per-person. In contrast, there are fewer users on closed instances, but they generate more toots percapita (average of 186.65). [@65RK2WI8#Raman_Etal_2019, p. 4]
This confirms that closed instances have more engaged populations: the median percentage of active users per closed instance is 75%, compared to 50% for active users in open instances. [@65RK2WI8#Raman_Etal_2019, p. 4]
There is, however, one clear outlier: adult instances constitute only 12.3% of instances but attract 61.03% of all users; that is, adult content is clearly a topic attracting a large user population, which is served by a small set of instances. This has been observed in other forms of online adult content, where websites with limited content sets gain large per-item interest [48]. [@65RK2WI8#Raman_Etal_2019, p. 4]
network, as each instance can have different policy requirements. Out of the 697 instances, 17.5% allow all types of activity. The remaining instances explicitly specify a subset of activities acceptable on the instance. 82% of these list at least one prohibited activity, whereas 93% explicitly specify at least one acceptable activity. [@65RK2WI8#Raman_Etal_2019, p. 4]
Japan dominates in terms of the number of instances, users and toots. In total, it hosts 25.5% of all instances, closely followed by the US which hosts 21.4%. Closer inspection reveals that the ratio between the number of instances and [@65RK2WI8#Raman_Etal_2019, p. 5]
number of users differ across countries though. For example, Japan hosts a just quarter of instances, yet gains 41% of all users; in contrast, France hosts 16% of instances, yet accumulates only 9.2% of users. It is also worth noting that these countries are heavily interconnected, as instances must federate together, i.e., users on one instance may follow users on another instance (thereby creating federated subscription links between them, see Section 2). [@65RK2WI8#Raman_Etal_2019, p. 6]
users of an instance follow other users on instances in the same country, e.g., 32% of federated links are with instances in the same country. The top 5 countries attract 93.66% of all federated subscription links. We posit that this dependency on a small number of countries may undermine the initial motivation for the DW, as large volumes of data are situated within just a small number of jurisdictions; e.g., 89.1% of all toots reside on instances in Japan, the US, and France. [@65RK2WI8#Raman_Etal_2019, p. 6]
Administrators are naturally attracted to well known and low cost providers. Whereas, a centrally orchestrated deployment might replicate across multiple redundant ASes (as often seen with CDNs), this is more difficult in the DW context because each instance is independently managed (without coordination). [@65RK2WI8#Raman_Etal_2019, p. 6]
A sizeable portion of instances do have relatively good availability properties – about half of the instances have less than 5% downtime. 4.5% of instances were even up for 99.5% of the time (these popular instances covered 44% of toots). However, there is a long tail of extremely poor availabilities: 11% of instances are inaccessible more than half of the time, which confirms that failures are relatively commonplace in Mastodon. [@65RK2WI8#Raman_Etal_2019, p. 6]
That said, it is likely that the voluntarily nature of many instance operators has a role, i.e., instances with poor availability might simply be unpopular, and lack dedicated administrators. To test this, we count the number of toots and users that are unavailable during instance failures, see Figure 7 (red lines, top x-axis). Instances may go down multiple times, so we select the 95th percentile of these values for each instance. Disproving our hypothesis, we find that failures happen on instances across the entire spectrum of popularity — there are a number of instances that host in excess of 100K toots which have outages [@65RK2WI8#Raman_Etal_2019, p. 7]
This is further explored in Figure 8, which presents a box plot of daily downtime for Mastodon, where we separate instances based on their number of toots. Although small instances (<10K toots) clearly have the most downtime (median 12%), those with over 1M toots actually have worse availability than instances with between 100K and 1M (2.1% vs. 0.34% median downtime). In fact, the correlation between the number of toots on an instance and its downtime is -0.04, i.e., instance popularity is not a good predictor of availability. [@65RK2WI8#Raman_Etal_2019, p. 7]
Closer inspection reveals that this was caused by the Let’s Encrypt CA short expiry policy (90 days), which simultaneously expired certificates for all 105 instances. In total, these certificate expirations were responsible for 6.3% of the outages observed in our dataset. [@65RK2WI8#Raman_Etal_2019, p. 7]
We only include ASes that host at least 8 instances (to avoid mistaking a small number of failures as an entire AS failure). We observe a small but notable set of outages. In total, 6 ASes suffer an outage. The largest is by AS9370 (Sakura, a Japanese hosting company), which lost 97 instances simultaneously, rendering 3.89M toots unavailable [@65RK2WI8#Raman_Etal_2019, p. 7]
hile almost all instances (98%) go down at least once, a quarter of them are unavailable for at least one day before coming back online, ranging from 1 day (21%) to over a month (7%). Figure 10 also reports the number of toots and users affected by the outages: 14% of users cannot access their instances for a whole day at least once [@65RK2WI8#Raman_Etal_2019, p. 8]
Comments are cached by the host instance (in case of replies) [@65RK2WI8#Raman_Etal_2019, p. 8]
Naturally, these measures are closely correlated to toot unavailability (i.e., toots become unavailable when their host instance goes offline) [@65RK2WI8#Raman_Etal_2019, p. 8]
Here we inspect federation through two lenses: (i) the federated subscription graph that interconnects instances (Section 5.1); and (ii) the distributed placement and sharing of content (toots) via this graph (Section 5.2). [@65RK2WI8#Raman_Etal_2019, p. 8]
his means that instance outages (Section 4.4) can create a transitive ripple effect, e.g., if three users on different instances follow each other, U1 → U2 → U3, then the failure of the instance hosting U2 would also disconnect U1 and U3 (assuming that no other paths exist). [@65RK2WI8#Raman_Etal_2019, p. 8]
Such a failure is not unique to the DW, and many past social networks have failed simply by users abandoning them [46]. [@65RK2WI8#Raman_Etal_2019, p. 8]
i) the size of the Largest Connected Component (LCC), which represents the maximum potential number of users that toots can be propagated to (via shares); and (ii) the number of disconnected components, which relates to the number of isolated communities retaining internal connectivity for propagating toots. These metrics have been used to characterise the attack and error tolerance of social and other graphs [3, 23, 51]. [@65RK2WI8#Raman_Etal_2019, p. 8]
Although Mastodon appears to be a strong social graph, with 99.95% of users in the LCC, removing just the top 1% of accounts decreases the LCC to 26.38% of all users. [@65RK2WI8#Raman_Etal_2019, p. 8]
This confirms that Mastodon’s social graph, by comparison, is far more sensitive to user removals. Although we expect that the top users on any platform will be more engaged, and therefore less likely to abandon the platform, the availability of top users to every other user cannot be guaranteed since there is no central provider and instance outages may remove these users. Indeed, individual instance failures, which we examine next, can take out huge subsets of users from the global social graph. [@65RK2WI8#Raman_Etal_2019, p. 9]
Unlike the drastic breakdown of the social graph, this elegant degradation is caused by the more uniform degree distribution of the federation graph (as compared against traditional social networks [6]). We emphasise that the instance federa- [@65RK2WI8#Raman_Etal_2019, p. 9]
tion graph shows the potential connectivity of instances. However, individual instance failures would still have an enormous impact on the social graph. [@65RK2WI8#Raman_Etal_2019, p. 9]
he size of the largest connected component decreases similarly whether we remove the largest ASes when ranked by instances hosted (blue) or by number of users (red). However, the number of connected components in GF increases drastically when we remove the ASes hosting the largest users [@65RK2WI8#Raman_Etal_2019, p. 9]
Figure 14 plots the proportion of home vs. remote toots taken from the federated timeline (see Section 2) of every instance in our dataset, ordered by the percentage of home toots. The majority of toots on the federated timeline are actually generated by remote instances: 78% of instances produce under 10% of their own toots. [@65RK2WI8#Raman_Etal_2019, p. 10]
This suggests that some highly influential central instances operate as ‘feeders’ to the rest of the network. Also, the more toots an instance generates, the higher the probability of them being replicated to other instances (correlation 0.97), thus highlighting the importance of a small number of feeders, without whom smaller instances would be unable to bootstrap. [@65RK2WI8#Raman_Etal_2019, p. 10]
Mastodon partly supports option (ii), but replicated toots are only temporarily cached and they are not globally indexed, i.e., they are only visible to users local to the instance where the replica is. [@65RK2WI8#Raman_Etal_2019, p. 10]
The figures shows that random replication substantially outperforms subscription-based replication. This is due to the biased way that subscription-based replication works, in which we find that 9.7% of toots have no replication due to a lack of followers, yet 23% of toots have more than 10 replicas because they are authored by popular users. [@65RK2WI8#Raman_Etal_2019, p. 11]
However, other things have to be considered, like availability of the instance that hosts the replication. [@65RK2WI8#Raman_Etal_2019, p. 11]
After removing 25 instances, subscription-based replication has 95% availability, whereas 99.2% availability could have been achieved with just 1 random replication. [@65RK2WI8#Raman_Etal_2019, p. 11]
There are a number of practical concerns that will impact such strategies. Most notably, it would be important to weight replication based on the resources available at the instance (e.g., storage). [@65RK2WI8#Raman_Etal_2019, p. 11]
At first, these were largely peer-to-peer, e.g., LifeSocial.KOM [18] and PeerSON [7], and relied on entirely decentralised protocols. Unfortunately, they did not achieve widespread adoption partly due to challenges related to both performance [4] and reliability [25]. Thus, a new wave of DW platforms has emerged that rely on a server-based federated model, e.g., Mastodon. Before that, the most successful platform was Diaspora, which saw growth around 2011 [19]. Diaspora offers Facebook-like functionality using a federated model similar to Mastodon. However, unlike Mastodon, it relies on bespoke protocols (rather than standards), and its user population has since stagnated. [@65RK2WI8#Raman_Etal_2019, p. 11]
These include OStatus [37], which allows real-time interaction between instances; WebFinger [24] for discovering information about entities on other instances; and ActivityPub [1] for publishing information about social activities. Attempts have also been made to standardise the format of these data structures, e.g., ActivityStreams [2]. This standardisation efforts have had a dramatic impact on the DW. For example, both Mastodon and PeerTube use ActivityStreams and ActivityPub; thus, they can exchange data. [@65RK2WI8#Raman_Etal_2019, p. 11]
Bielenberg et al. performed the first study of a DW application, Diaspora [5]. When inspecting its growth, they found a network far smaller than the one we observe on Mastodon. There has been a small set of recent works that focus on Mastodon. Zignani et al. collected and released Mastodon datasets, as well as exploring several features, e.g., the social graph, placement of instances and content warnings [54, 55 [@65RK2WI8#Raman_Etal_2019, p. 12]
We complement these works with a focus on availability, covering the key aspects of federation. We also inspect the nature and deployment of instances, as well as their topical interests. [@65RK2WI8#Raman_Etal_2019, p. 12]
challenges arising from two key innovations introduced by the DW: (i) the decomposition of a global service into many independent instances; and (ii) the process of federation, whereby these instances collaborate and interact. [@65RK2WI8#Raman_Etal_2019, p. 12]
a common theme in our work has been the discovery of apparent forms of centralisation within Mastodon. For example, 10% of instances host almost half of the users, and certain categories exhibit remarkable reliance on a small set of instances. This extends to hosting practices, with three ASes hosting almost two third of the users. [@65RK2WI8#Raman_Etal_2019, p. 12]
lead to potential points of failure. [@65RK2WI8#Raman_Etal_2019, p. 12]
possible mitigations, we experimented with simple replication strategies to find that availability can be dramatically improved by copying toots onto secondary instances, i.e., by reducing the level of centralisation. Interestingly, the subscription-based strategy (loosely employed by Mastodon currently) is not as effective as a random strategy, due to the propensity to replicate toots onto the same set of instances where the followers are based. [@65RK2WI8#Raman_Etal_2019, p. 12]
decentralised defenses against, e.g., malicious bots. One example of a possible mitigation is the existing instance blocking supported by Mastodon; [@65RK2WI8#Raman_Etal_2019, p. 12]
Did this ever happen? [@65RK2WI8#Raman_Etal_2019, p. 12]
investigate the impact that this has on the social graph and how it can be used to filter malicious content. [@65RK2WI8#Raman_Etal_2019, p. 12]
plan to provide a longitudinal analysis of Mastodon with respect to the issues identified in this paper as well as study the effect in terms of hate speech of alt-right communities like Gab [52] starting to use Mastodon forks [34]. [@65RK2WI8#Raman_Etal_2019, p. 12]
S. Zannettou, B. Bradlyn, E. De Cristofaro, H. Kwak, M. Sirivianos, G. Stringini, and J. Blackburn. What is Gab: A bastion of free speech or an alt-right echo chamber. In WWW Companion, 2018. [@65RK2WI8#Raman_Etal_2019, p. 13]