Managing communities in decentralised social environments

Many decentralised systems can be represented as graphs, and the detection of their community structure can uncover important properties. Several community detection algorithms have been proposed, however, only a few solutions are suitable for detecting and managing communities in a distributed and highly dynamic environment. This lacking is mainly due to the difficulty of defining self-organising solutions in the presence of a high rate of dynamism. The main contribution of this paper is DISCO, a distributed protocol for community detection and management in a Peer-to-Peer dynamic environment. Our approach is mainly targeted to Decentralised Online Social Networks (DOSNs), but it can be applied in other distributed scenarios. In the context of DOSNs, DISCO allows to discover communities in the local social network of a user, named ego network, and to manage their evolution over time. DISCO is based on a Temporal Trade-off approach and exploits a set of super-peers for the management of the communities. The paper presents an extensive evaluation of the proposed approach based on a dataset gathered from Facebook and shows the ability of DISCO to orchestrate a set of nodes to detect and manage communities in a highly dynamic and decentralised environment. The paper also proposes a comparison with a state of the art approach, showing that it is capable of reducing the number of critical community lifecycle events by over 25%, and reducing the average loading factor by up to 50%.


Introduction
Decentralised systems can be described as systems where a set of entities interact and cooperate for a common or shared goal. By their nature, they can be easily represented by graphs, where nodes correspond to the entities and edges to the possible relations that dynamically occur among them. The analysis of a graph representing a decentralised system can be used in countless situations, such as to detect malevolent nodes, hubs, or for network improvement. Community detection, in particular, can be applied to improve routing or for virus containment in mobile networks. Although graph analysis and community detection can bring benefits to numerous decentralised networks, they are even more important when we consider a social environment. For this reason, Decentralised Online Social Networks (DOSNs) can be considered one of the most interesting decentralised scenarios for this kind of analysis.
DOSNs have been proposed as an alternative to Online Social Networks (OSNs), fuelled by an ever increasing need for privacy by their users, trying to solve problems such as censorship, scalability, dependence on a single provider, and poor value redistribution [1,2]. A Decentralised Online Social Network [1], is an online social network whose services are decentralised on the nodes of an opportunistic, mobile or P2P network. While the new generation of OSNs took a giant step toward decentralisation, some challenges need to be faced to propose an effective implementation, ranging from ensuring that data is made available to the users, to enforcing that user privacy is preserved. One approach to these problems is to leverage the behaviour of the users to create effective and innovative solutions. Barbara Guidi and Andrea Michienzi have contributed equally to this work. Classical OSN can be described by the friendship graph, which is a graph where nodes correspond to human beings and links are built whenever two of them interact or become friends, and this graph can be studied through graph analysis techniques. However, when considering DOSNs, analysis techniques need to take into account their decentralised nature and must meet this scenario's features, most of all their dynamicity. In particular, there is the need to propose decentralised protocols to manage the network, and extract knowledge in real-time.
One of the graph structures which has been most investigated in the OSNs' scenario is that of communities. Community detection is a well-investigated problem in graph theory [3], and its study reveals interesting properties concerning the behaviour of social network users. While a widely accepted technical definition of a community is still lacking, intuitively a community can be considered as a set of vertices that are closely knit into a relatively sparse neighbourhood in a graph. Community detection has attracted more and more attention in many interdisciplinary fields [4,5]. Countless algorithms [6] have been proposed, mainly based on their definition of community or based on different detection processes. A large portion of these algorithms takes into account static or dynamic graphs, however, in the latter case, they consider networks as a sequence of snapshots, generated over time.
Detecting the community structure of the users' friendship graph of a DOSN may be useful for offering several services, including the definition of a data diffusion system or a community-driven data replication technique to guarantee a high level of availability of users' data. However, while several algorithms for community detection have been proposed, only a few proposals can be applied to DOSNs because they do not take into account the peculiarities of this application scenario. In particular, one key aspect that is often underrated is the fact that decentralised topologies are extremely dynamic and can change swiftly due to the effects of node churn on the underlying P2P network. This effect is even more evident in a DOSN scenario, which often includes mobile devices. Indeed, most of the relevant approaches only re-adapt existing community detection algorithms, such as the Label Propagation [7] or the modularity optimisation algorithm [8] to the distributed scenario. However, a key point is to consider not only the social properties, but also take into account the dynamic nature of the network supporting the DOSN to provide a concept of community in line with the scenario and a protocol that can manage the community structures. For these reasons, defining distributed and self-organising solutions both to discover and manage communities is the main goal of this work.
In this paper, we present a DecentralISed protocol for COmmunity detection and management (DISCO) targeted to a decentralised social environment. DISCO takes as the reference scenario a DOSN based on a P2P network where nodes know their direct contacts and the relationships between these contacts. We use the ego network structure to represent the network overlay, as described in [9]. DISCO takes advantage of this structure, to define a local approach, making it a decentralised protocol to manage local communities in ego networks. It does so by exploiting the local information of a user in a DOSN, detecting communities for each ego network, rather than considering the whole network at once. This course of action was decided because of multiple reasons. Firstly, obtaining a snapshot of the global graph to be analysed is extremely challenging and costly, from multiple points of view (computational, storage, time required to gather). Once a snapshot is obtained, a big effort to manage and analyse the graph is required, which has a serious impact on the choice of the algorithms for community detection. While the detection of the global community structure can still uncover important properties, we would like to have a much greater focus on the local properties of the analysed graph. Indeed, it is by considering local properties and local knowledge that privacy can be more easily taken into account and enforced. We also need to consider that a social graph is a very dynamic graph, in constant evolution, mainly in terms of the users, that can be online or offline, but also in terms of their relationships, that can form, dissolve, and change over time. Therefore, community detection should be an inexpensive task, where the detection of the community's evolution is local, restricted to the region where the graph changed [10,11]. Lastly, the decentralised nature of DOSNs imposes additional constraints concerning the resources available for storage and computation, further suggesting that a global approach is unfeasible [12][13][14].
DISCO is based on the definition of a set of superpeers that execute a sequential algorithm for detecting the communities and, periodically, synchronise among themselves to possibly merge them. It uses a Temporal Tradeoff approach [5] to manage the evolution of communities, which is well suited to discover and manage communities varying over time in a distributed system. The main novelty of our approach is that, while current approaches are conceived mainly in the field of data mining, our solution is better suited to a dynamic decentralised social system. Indeed, additionally to the aforementioned concept of the local community, which takes into account both the social features of users and the dynamism of the underlying network, DISCO also takes into account the scenario of the application. Nodes are, in fact, proactive and constantly monitor the community structure around them to be involved in at least one community at all times. Communities can also be autonomously created or dropped as needed by the nodes, creating a self-configuring system. Considering the nature of the application scenario can bring several benefits. Indeed, in this way, communities 1 3 detected by DISCO are intrinsically bound to the behaviour and the habits of the users and can be used to provide social awareness to the systems and applications that make use of DISCO. This fact can be used for many purposes, including for defining a data replication system in DOSNs, or even for setting up a social multicast system.
The main characteristics of DISCO can be summarised as follows: • DISCO adopts a three-tier DOSN reference architecture made of a low-level communication layer, a Distributed Hash Table layer and an application layer where the protocol is executed. • The core of the algorithm used to detect and manage dynamic communities is based on triangles and triads. The triangles are used to create a clusterised community, while the triads help lower the computational cost of the community detection and management process. • To stick to a local definition of community, and further reduce the computational cost and make DISCO scalable also for big communities, when a node leaves the network, the community is re-evaluated only in the neighbourhood of the leaving node. • A local and mindful management of nodes joining and leaving the network help to reduce the number of messages exchanged between the peers, which is a crucial trait in scenarios where nodes churn is a real challenge. • The community structure is detected by all nodes and managed by super-peer nodes, called moderators. Nodes are proactive and will try to always be part of at least one community. • The community structure managed by moderators is updated over time, rather than computed from scratch when needed. This ensures that a more meaningful community structure is defined because it takes into account the time dimension, so that the structure is constantly available and up to date. • We provide multiple moderator election strategies: one based on a random choice, and one taking into account load balancing, i.e. nodes that can manage higher traffic, are more likely chosen as moderators.
The paper is organised as follows: Sect. 2 contains works related to DOSNs, community detection in centralised and distributed environments. The reference architecture is presented in Sect. 3, while in the core Sects. 4 and 5 we present, respectively, the algorithm and the protocol we propose. Section 6 contains a comprehensive evaluation of DISCO and its comparison against an analogous approach, and, lastly, Sect. 7 draws conclusions and points out possible future works.

Related work
In this Section, we introduce the state of the art concerning the topics treated in this paper. We start by introducing the reference scenario and by giving an overview of current DOSNs applications. Then, we present the main concepts of Community Detection, and finally an overview of the current proposals in the research area of Decentralised Community Detection.

Decentralised online social networks
A Decentralised Online Social Network (DOSN) [1] is an Online Social Network implemented on a distributed information management platform, such as a federation of trusted servers, a P2P system, or an opportunistic network. The decentralisation is geared towards granting more control over private data. Indeed, there is no more a single service provider, but a set of peers that take over and share the tasks needed to run the system. During the last years, several solutions have been proposed by both academic researchers and open source communities [15]. One possible approach to DOSNs is represented by a social logical overlay [9] in which social relationship links between users are mirrored in the applicationlevel communication. Among the possible social overlay models, the Ego Network (EN) model [16] is one of the most important. The EN of a user is made of the user itself, which is also called ego, its direct friends, known as alters, and include the direct connections between the alters. The importance of the EN model comes from the fact that it is a social network model representing a usercentric view of the social network. Being centred on a specific user, it can be used to model the local knowledge that each user has of the network. These characteristics make this model suitable for the definition of DOSNs. Formally, given a social network modelled through a graph G = (V, E) , where V is the set of users, and E is the set of relations between the users, each vertex u ∈ V can be seen as an ego and is the set of adjacent nodes of u. Figure 1 shows an example of EN. On the left, a sample graph is shown. The networks A and B highlight the ENs of the ego nodes 10 and 8, respectively, which are represented by a red node. The ENs contain the alters of the ego node, represented with blue nodes, and the relations among them.
The main motivation that brought developers and researchers to create DOSNs lies in the numerous issues that characterise centralised OSNs, including scalability, dependence on a single service provider, and privacy [1]. In particular, in recent years, the rise and quick development of OSNs has led to two important phenomena: user privacy disclosure and the rapid spread of misinformation. OSNs have become the epicentre through which individual privacy is violated. Most of the current DOSNs proposals approach decentralisation through a P2P network. Diaspora 1 , with about 680,000 users, is one of the most successful DOSN currently active and deployed in a decentralised way, such as Mastodon [17]. PeerSoN [18] is implemented as a two-tier system in which the first tier is used for peer discovery and lookup, while the second tier is used for the communication between peers and the exchange of users' profiles. SafeBook [19] is a particular solution in which the P2P overlay network is modelled by Matryoshkas, which are composed of concentric rings of peers built around each peer. The social overlay guarantees trusted data storage and obscure communication through indirection. LifeSocial [20] is a plugin-based DOSN that proposes a solution to the privacy issue by using publicprivate key pairs to encrypt profiles. Private data are stored in a Distributed Hash Table (DHT). DiDuSoNet [9] is a trust-based DOSN in which the social overlay is modelled by a Dunbar-based social overlay, limited to 150 trusted users [21]. The proposal is mainly focused on the data availability issue by introducing the concept of Point of Storage (PoS). The peers organise in such a way that each profile has only two replicas set up in trusted nodes.

Community detection
Even if community detection is an important task in complex network analysis [4,5], there is no universally accepted formal definition of community. Indeed, a community can be defined as a graph with specific structural properties, or can even be defined as the result of a complex process. At a high level, however, a common notion in the community definition is based on the detection of a set of entities where each entity is closer to the other entities within the community than to the entities outside it [22]. While community detection has been widely studied in static complex networks, the interest is quickly growing also for dynamic networks. This is because dynamic networks better model the dynamic nature of current complex networks such as social networks, economic networks and many more. Indeed, the time-evolving nature of the social networks, especially when considering spontaneous networks arising from p2p/ opportunistic contacts makes it even harder to formally define what a community is. A first very abstract definition of dynamic communities has been proposed in [5], where the classical definition of a community as a set of closely correlated nodes is refined by taking into account that the relations between the nodes may change over time.
Dynamic Community Detection (DCD) algorithms can be classified into the following main classes [5]: Instantoptimal Community Detection, Temporal Trade-off Community Detection, and Cross-Time Community Detection. In the Instant-optimal Community Detection class, communities existing at time t are discovered by considering only the state of the network at time t. The network evolution is seen as a series of successive snapshots, each representing the state of the network at a particular instant of time. In the second class, Temporal Trade-off Community Detection, the communities identified at time t depend on the state of the network at all the instants of time less or equal t, possibly up to the initial known state. Finally, the Cross-Time Community Detection class includes all the methods that use all available information, i.e. past, current and future with respect to time t, to identify communities at the instant t. Several approaches concerning the dynamic community discovery have been proposed over the years. An exhaustive survey has been proposed in [5].

Decentralised community detection in P2P networks
Community detection in decentralised networks opens up numerous possibilities, countless scenarios, and multiple challenges to be taken into account. However, many On the left, an example of a graph representing a social network. In the centre, the ego network of node 10 and on the right the ego network of node 8. Node 4 belongs to the ego network of both nodes 10 and 8 approaches for decentralised community detection are merely just a re-adaptation, in a distributed setting, of the Label propagation [7] approach. For instance, in [23] authors propose a framework that allows an analytical study of the distributed community detection problem. A revised label propagation algorithm is proposed to model some features of opportunistic networks. A simpler approach is presented in [24], where the rule to update the labels of the nodes is based on a similarity metric. This approach seeks to achieve better results in terms of modularity, and to mitigate the wandering community effect. In [25], the authors propose a distributed approach for local dynamic community detection and three implementation variants. In this case, the distributed nature of the algorithm induces a very weak consistency among the nodes of the network. Another important contribution is proposed in [26], where game theory is applied to the problem of decentralised community detection in the scenario of social graphs. [23] proposes an approach, based on the Plant Bisection Problem, for distributed community detection in dynamic networks, targeting the scenario of opportunistic networks. Also, the node clustering problem has been tackled with distributed approaches [27]. A downside of this approach is the fact that it is difficult to deal with node dynamics, i.e. join and leave, because, due to the presence or absence of nodes, the clusters may differ a lot. A common technique to tackle dynamism is to add new nodes to existing clusters and to periodically run from scratch the distributed clustering algorithm. Other interesting approaches applied to DOSNs are proposed in [28][29][30]. In [29] authors study the problem of community detection as a binary classification problem, but they completely disregard the time dimension in their problem. The Propose-Select-Adjust framework presented in [30] is a 3-step framework where each node decides to which community it belongs to, and proposes to neighbour nodes to join it. The approach is suited to detect global communities, but the nodes are oblivious concerning the whole structure of each community, because they make a decision based on their local knowledge. In [28] authors propose a decentralised protocol to detect and manage community structures. Even if the authors say that the approach can be applied to smart environments and to mobile networks, the performances of the protocol show that it is not feasible in such scenarios.
In this paper, we propose an innovative, fully decentralised approach for local community detection in DOSNs called DISCO. Contrarily to other approaches presented in the literature, we take into account the possible presence of mobile devices, and for this reason, we consider a definition of community in line with the distributed environment. We also take into account the specific scenario of application of our protocol, by detecting a community structure that is local with respect to the users of the DOSN. DISCO also introduces a load balancing mechanism, to make sure that the community detection burden is almost uniformly spread among the nodes of the network. Nodes participating in DISCO adopt a proactive behaviour, meaning that they will constantly monitor the community structure around them, and make sure to set up or dismiss communities as needed.

DISCO: The reference architecture
In this Section, we present the reference architecture adopted by DISCO. The three-layer reference architecture is shown in Fig. 2. In our scenario, peers connected to the Internet organise themselves in a DHT to be able to discover and communicate with each other in a decentralised setting. Peer Fig. 2 The reference architecture: in the bottom layer, physical connections are supported by Internet. In the middle layer, the DHT supports the topmost layer. On the top, is the social overlay nodes also correspond to actual users of a DOSN, and are organised at the topmost level according to their social ties.
The lowermost level is the communication layer, and it implements the physical connectivity between the nodes of the DOSN. This layer is implemented by the Internet protocol stack. The middle layer is implemented by a DHT, used to supply a proper service for the topmost layer, and maintain information useful for the correct functioning of the upper-level network. The DHT offers several management services, which can be beneficial for multiple purposes, such as node bootstrap, node lookup and for the management of the communities. In our scenario, we used the Pastry DHT, because it has good performance and high reliability according to [31]. It is important to point out that the DHT is merely used as a support, while it is not used for any kind of application-level storage as, for instance, in [9,19].
Finally, the topmost layer is the Social Overlay, where users' personal data is stored and managed. The Social Overlay we use is described in [9], and it represents an instance of the most generic Friend-to-Friend networks (F2F). We focus on this model because, in a distributed environment, nodes have limited knowledge of the network, and a current trend in DOSNs is to use a user-centric approach [32]. The local knowledge of each user is represented by her/his own EN ( Fig. 1), as explained in Sect. 2.1.
In the remainder of this Section, we describe more in detail the Social Overlay layer, what is the role of moderators in the reference architecture, and how the DHT layer is included.

The social overlay layer
Above the communication layer and the DHT, we use a social overlay network to store private data. A Social Overlay, as introduced in [33], is an overlay where nodes are only connected to each other if a social tie exists between them. This kind of overlay can be considered a F2F overlay in which users only make direct connections with people they know. Our Social Overlay is structured by using the EN model, as explained in Sect. 2.1. For sake of readiness, each peer has its EN and the union of all EN composes the social overlay (see Fig. 1). Each peer maintains a local view, in which there is information about its direct social contacts. Indeed, nodes are connected to known nodes, and an edge between a pair of nodes indicates a social relationship between them.
The representation of the local knowledge through the EN model permits us to maintain information about all the social connections which can involve the ego: links between the ego and another user (alter) and links between alters of the ego node. Our network model is inspired by the Dunbar Social Overlay presented in [9].

Moderators
Our protocol uses a super-peer approach [34] where superpeers are in charge of executing the DCD algorithm. In DISCO, when the ego e is online, its node is responsible to manage the communities of its own ego network. Instead, when e is offline, the management of its communities is assigned to a set of super-peers, which are chosen from its ego network. In our approach, these super-peers are named moderators, and will be in charge of keeping communities updated as other nodes join and leave the network. Moderators, each time a node joins or leaves the network, reevaluate the set of communities they manage and, if certain conditions are met (explained in detail in Sect. 4), modify them, interacting with the nodes belonging to them.
To be sure that moderators can function properly, we assume that they know the EN structure of the egos on behalf of which it is moderating at least a community. We safely make this assumption because the ego network structure of a node can be easily retrieved by current community moderators. The EN structures can also be exchanged between two nodes when they first add to each other's EN, and can be cached and used when needed. Overall, each node has to store the subgraph that contains only their 2-nd order neighbours, which is a reasonably small portion of the whole P2P network. Knowing the EN structure allows moderators to efficiently evaluate whether a joining node can be part of the community, and to reduce the number of communication costs when a node leaves the network.
Each community has two moderators. Indeed, having a single moderator for each community has important drawbacks. The main drawback is connected to the nature of super-peer approaches, which are fragile in case the superpeer fails unexpectedly. For this reason, we manage communities with both a primary moderator and a secondary moderator. The secondary moderator acts as a common peer and, as the only addition, runs a ping-pong protocol with the primary moderator. Indeed, the secondary moderator is a backup moderator, taking the role of the primary moderator in case it detects that the current primary moderator of the community has failed (through the ping-pong protocol). When the secondary moderator detects the failure of the primary one, additionally to promoting itself as the primary moderator, starts a procedure to re-establish consistency, electing a new secondary moderator for that community, and updating the community metadata stored in the DHT. We do not consider using more than two moderators, because we suppose that the procedure of electing the secondary moderator is completed before a new failure happens.
In Fig. 3, we show an example with three communities in two different ego networks. The first ego network, whose ego node is represented by the blue node labelled as E 1 and whose members are blue, has two active communities ( C 1 1 , and C 2 1 ),

3
while the second ego network, whose ego node is represented by the red node labelled as E 2 and whose members are red, has a single active community ( C 1 2 ). Purple nodes belong to both communities. Each ego node is connected to the respective alters with dashed lines. In this scenario, the community C 2 1 has a primary moderator the node identified by the white letter 'M'. Communities belonging to different ego networks can have the same node as moderators, as the purple node identified by the black letter 'M', which is the primary moderator for both C 1 1 and C 1 2 . They are computed by considering the ego minus ego network (an EN where the ego node is removed). The ego node is not considered in the community detection task because it may collapse the community structure since it is connected to all its alters by definition.
Adopting a moderator approach can bring additional benefits. In particular, we can assign further responsibilities to a moderator. For instance, if we consider the privacy problem, the moderator can be the one that enforces the privacy policy assigned to that community. Furthermore, if we consider that information shared inside a community can be replicated in its nodes [12], the moderator may also decide the allocation of the shared information on the nodes of the community. Finally, the presence of super-peers simplifies the protocols to guarantee consistency in shared information.

The DHT layer
As presented in Sect. 3, in the reference architecture we consider the presence of a DHT layer implemented by Pastry [31]. Several DOSNs proposals use the DHT as the underlying layer, since it allows to retrieve information about the nodes in the network, and it can help to support data availability [18,20,35,36] and privacy.
In DISCO, the DHT is only used as a support layer for our DCD algorithm, while private users' data are stored using a different technique. One such example is to let the peers of the social overlay organise themselves to create social data replicas, as explained in [9]. This enables to keep a high level of privacy, without incurring in the usage of other techniques to enforce privacy, such as cryptography. In our approach, the DHT is used to store community meta-data, and as an entry point for the joining nodes to discover which nodes are the moderators of the communities. To let joining nodes easily discover the moderators of communities of an ego e, DISCO uses the id of the ego as the key of the DHT. The value corresponding to a key id is the set of moderators of the currently alive communities in the ego network of the ego identified by id.

Community detection: Our approach
In this Section, we firstly deepen the discussion of the approaches for Dynamic Community Detection (DCD), introduced in Sect. 2, by highlighting the pros and cons of the application of each approach in a distributed environment. Then, we present the DCD algorithm used by the moderators to decide the membership of a node in a community. The algorithm is used by the moderators to update community roles as nodes join or leave the network. The full DISCO distributed protocol will be presented in the next Section. DISCO adopts the triangle (a set of three nodes fully interconnected) and the triad (three nodes connected by two edges) as the basic building blocks for communities. The triangle is the basis for many other community detection algorithms [28,[37][38][39][40]. Triads are introduced to make the decision process for the community membership more lightweighted from a computational point of view. The final aim is to create a community detection protocol that can be easily adopted in highly dynamic environments, such as Wireless Sensor Networks, Mobile Social Networks, etc.

Community detection in dynamic ego networks: Our choice
As discussed in Sect. 2, DCD algorithms can be classified as: Instant Optimal, Temporal Trade-off and Cross-time. The three classes differ in the amount of information used to carry on the task, which deeply affects the usability in different contexts. Cross-time algorithms detect communities at a given instant of time t using all the possible information available, namely the state of the network at any point in time. The great limitation of this class is the fact that it requires to access future information, with respect to the instant of time t when the communities are detected. In DISCO, communities have to be computed online, in real-time, and information about events happening after t, is not available, like in an off-line system. This fact makes this class completely unfeasible in our scenario.
In the Instant optimal class, detection of communities at the time instant t only uses the state of the network at t. This class uses a minimal amount of information and the definition of the algorithms is, therefore, simplified. The problem with this class lies in the fact that communities must be detected from scratch each time they are needed, which is a limitation imposed by the information used to carry out the community detection task. Indeed, a snapshot of the network must be collected somehow in order to start the detection of the communities. And, while this doesn't seem a big problem in scenarios where powerful machines are employed in the detection task, it may represent a serious drawback in decentralised, P2P architectures with heterogeneous, low-end devices. The main problem comes from the fact that obtaining a consistent and updated snapshot of the network is a hard task in distributed systems, where each node has limited knowledge of the network and node churn is an impactful phenomenon. The scalability of the system may be highly affected by such an approach: in fact, it is not feasible to make one node collect the snapshot of the network and then detect communities in a large scale network. A mechanism that distributes the community detection ask, will introduce heavy synchronisation phases. For these reasons, the Instant Optimal class of algorithm is not well suited for our scenario.
Finally, the Temporal Trade-off class includes all the approaches that exploit present and past information to detect communities at a given time instant t. When we refer to "past information", we do not necessarily mean the "state of the network at past instants of time", but we may also refer to the communities detected in the past. So, starting from preexisting communities, a potentially scalable approach should keep these communities updated throughout time just by observing nodes joining and leaving the network. Beyond the fact that such an approach is more efficient because the detection of communities is not made from scratch each time they are needed, it is also potentially more scalable. Indeed, to carry out the task is not necessarily a complete snapshot of the network and communities can be reevaluated locally, so nodes that are not topologically close to the community can be simply ignored.
In conclusion, we decided to choose an approach belonging to the Temporal Trade-off class, because of the better chances to obtain an efficient and scalable solution. The two key features of our approach emerging from this choice, are the ability to update communities locally and independently to one another, and the possibility to update communities, rather than computing them from scratch each time.

The community life-cycle events
Dynamic communities are characterised by the so-called life-cycle events, which correspond to critical events.
We consider the following events: • Birth: we say that a community is formed when a node creates a new community; • Death: we say that a community dies if its structure is destroyed after a node leaves the community, thus making the community dissolve; • Merge: we say that we have a merge between two or more communities if all these communities are subsets of the biggest community. The biggest among the merging communities will be the only one surviving the merge, while all others will be dissolved (but will not count as death events); • Split: we say that we have a community splitting into two or more communities if, as a result of a node leaving the community, two or more communities will begin their own existence.

Computing communities
In this Section, we introduce the algorithm used by the moderators to manage the communities. It is used by each moderator when it receives messages from the nodes joining/leaving an EN, which are used to update the communities. The protocol executed by the peers will be described in Sect. 5. DISCO uses two structures for the definition of a community, triangles and triads. Let us consider a community C and a new node n. n can be added to C if and only if at least one of the following conditions is satisfied: • triangle condition. It is satisfied if n forms at least one triangle with two different nodes belonging to C. This situation is that of node c in Fig. 4c. • neighbour condition. It is satisfied when the number of neighbours of n inside the community is larger than a fixed threshold k This is the situation of node b presented in Fig. 4c.
The triangle condition aims at keeping a high level of clustering among the nodes inside the community. The neighbour condition aims at softening the triangle condition, making nodes that are well connected to the community join it, even if they do not close a triangle. What we expect is that a well-connected node n will close more and more triads over time, so defining more and more triangles and increasing the clustering coefficient of the community, even if the insertion of n has lowered it temporarily. This fact should also bring to a situation where the number of communities is sensibly lower because a node is more easily accepted into existing communities. Last but not least, the neighbour condition is also computationally less expensive with respect to the triangle one. Indeed, it only requires counting the number of neighbours of n that are inside C. Furthermore, in a DOSN scenario, it will often happen that whenever the triangle condition is satisfied, also the neighbour condition is satisfied.
Let us now discuss what happens when a node n is eliminated from a community. The very first step to handle the departure of n is to remove the node from the community itself and the following step is a check for membership for a subset of nodes inside the community which are involved in the departure of n. Rather than checking all nodes in the community which can be computationally very expensive even for small communities, the check is performed only for the neighbours of n, sensibly reducing the number of controls to be made. The procedure for node checking is as follows. The nodes to be checked are labelled as unconfirmed (Fig. 5b). Then, any unconfirmed node is considered, one by one, and DISCO verifies if either joining condition holds for that node, i.e. the triangle and the neighbour conditions. If either of the conditions holds, that node is labelled as confirmed and excluded from further checks. This verification process is repeated until no more nodes can be labelled as confirmed. At this point, all unconfirmed nodes are removed from the original community, while all confirmed nodes will remain inside the community (Fig. 5c).
After the check for membership process has finished, the original community can be split into several shards, where each shard may contain one or more nodes. To detect these shards, the connected components of the graph resulting from the removal of the leaving nodes are computed. Each of the resulting components is a new standalone community. As we will see in the next Section, if required, the moderator will notify the peers involved in the community update so that they can self-organise in new communities.

The DISCO distributed protocol
In this Section, we describe the phases of our protocol with respect to the main events of a node lifecycle, i.e. node join, and leave of moderators and of ordinary nodes.

Node join
In the case of a node n joining an EN of a node e as an alter, the aim of n is to get accepted into an existing community within the EN of e. In order to do so, it obtains the list of active moderators of the EN it is joining to from the DHT, and, upon receiving this list, it sends a join request to each moderator. Thanks to the fact that the moderator knows the EN of the ego for which it is moderating the community, it can check if the requesting node can join the community autonomously, without the intervention of the moderator. Moreover, the joining node pings all its alters to check which of them is online, in case a new community needs to be defined from scratch. Finally, a timeout is set to restart the joining procedure in case it fails. When the reply from the DHT containing the list of moderators for the ego network of e is received, the joining node contacts them to notify it is now online and to ask to be part of the communities managed by the moderators. A moderator, upon receiving a notification from a joining node evaluates the connections among the joining node and the other nodes inside each community managed by it, evaluating whether the new node may be inserted in that community. The set of conditions, defined to insert a new node in an existing community, are those described in Sect. 4. According to the results of this evaluation, a message is sent back to the joining node to notify it whether it can be inserted in the community or it cannot join the community because the joining conditions are not satisfied. In the first case, the moderator updates its community accordingly. In Fig. 4, we show the join procedure executed by nodes A, B and C, with the messages exchanged between each of them and the moderator of a community.
It may also happen that a node cannot join any community. This may happen if, for instance, up to now no community has yet been created, and therefore no moderator has been elected. In this case, the joining node can detect if a new community can be built around itself, collecting information about its neighbours through the ping process, as explained in the following section.

Community birth
As last resort, if a node cannot join any community, because no communities are defined or none of the existing communities can accept it, the node will try to create a community on its own with itself as a moderator. This corresponds to a community birth event. As explained in Sect. 5.1, when a node joins the network, it also pings its neighbours on the social overlay. Indeed, thanks to the information received from the online neighbours, a node is able to detect whether a community structure is forming around it. Upon receiving replies from its neighbours, the node checks if there is at least a triangle of online nodes including itself. After having detected all the triangles with the online neighbours, the node creates the communities, merging in the same community the triangles sharing at least an edge. Note that the triangle remains the basic structure to create a new community, while the triangle condition is relaxed in the join/leave operations. When the community has formed, the node that discovered a community structure around it becomes the primary moderator for that community. Right after, the newly self-proclaimed moderator elects a secondary moderator by choosing, uniformly at random, a node among the nodes belonging to the newly formed community. To complete the joining process, it also inserts in the DHT the information about this newly formed community, along with a reference to the two moderators, so that the nodes joining the network in the future, will be able to retrieve it, as explained in Sect. 3.3. As the last step, to complete the community birth, all the nodes inside the community are notified of its birth.
Note that this method can fail in the bootstrap phase, when there are no communities because the system contains less than three nodes or the nodes are not well connected. For this reason, if all previous procedures fail, the node set a timeout and, when it expires, it re-executes the whole node join procedure.

Node leave
A node voluntarily leaving the network should inform the primary moderator of the communities it is part of that it will be unavailable soon. Since each node stores a reference to these moderators, the overhead to leave the network is minimal.
When the moderator receives the message from a leaving node n, it has to reevaluate the roles of all nodes in the surrounding of the leaving node. The moderator removes the leaving node from the community, and then determines if its departure modifies the community structure, executing the membership tests explained in Sect. 4.3. Note that, since the moderator knows the EN n belongs to, no additional input is required. All nodes which are unverified (see Sect. 4.3) will be removed from the community and will get a notification from the primary moderator, while all verified nodes will remain inside the community (Fig. 5c). This notification allows the unverified node to try to join other communities if the unconfirmed node realises belong to any of the communities.
After this process, the community can simply shrink in size if the departure of the leaving node has not produced a split of the community. A more impactful scenario is when, after a node leaves the network, the community is divided into shards. If the current primary moderator still belongs to one of the shards resulting from the split, this shard inherits the original community and the corresponding primary moderator. All the other nodes will receive a message from the primary moderator stating that they are no more part of that community.
At the same time, each shard of the original community is now a community of its own and will have both primary and secondary moderators. To this aim, the primary moderator of the original community elects uniformly at random a primary moderator among all the nodes inside the new community (Fig. 5d). The primary moderators of the created shards, independently of one another, are in charge of notifying all the nodes in their respective shards about their identity, and adding a reference to their own shards in the DHT, so those other nodes can find and join the community of that shard. Furthermore, each newly formed community will be entrusted to the respective newly elected moderator which is now in charge of electing a secondary moderator for its community. Note that the original community can also be completely destroyed and this corresponds to a death event.
The departure of a node may cause more nodes to also be removed from the community and from each one of its shards. These nodes that end up being outside the community (as a consequence of the node leaving the network) will be notified by the primary moderator of this event. In particular cases, this may lead to a situation in which one (or more) nodes are still online and available but they are not inside any community. A node in this situation will try to reestablish a regular situation, trying to become part of a community as if it just joined the network. The fact that a node actively tries to always be part of a community is a peculiar property of our approach. Indeed, many DCD algorithms in the literature are just data mining tools in which nodes try to join communities only when they switch their status to online. Instead, our approach enables nodes to actively search for new communities when they don't have one. Although this is a parameter of DISCO, for the remainder of the paper we will consider that nodes will try to be part of at least one community.

Moderator leave
If a primary moderator voluntarily leaves the network, it also must take care of the communities it has managed up to now. Such communities need another primary moderator and the community must be updated according to the procedure we described in Sect. 4.3. We decide to perform the election of the new primary moderator in the old primary moderator, or rather, the node that is leaving the network, and we decide to perform the update of the community in the new primary moderator. The election of the new primary moderator can be performed rather quickly and each community must have one. On the other hand, the update of a community structure can be a quite lengthy process, and we do not want the old primary moderator to do extra work which can be done by the new primary moderator. The strategies we considered for the election of a primary moderator are presented in Sect. 5.4.1.
The case of a secondary moderator leaving the network is simpler. The primary moderator elects a new secondary moderator, updates the DHT, and finally manages the leave of the secondary moderator as a normal node. The strategies we considered for the election of a secondary moderator are presented in Sect. 5.4.1 as well.
Finally, a moderator can also fail unexpectedly. To cope with this possibility, as we introduced in Sect. 3.2, we suppose that each pair of primary and secondary moderators of the same community run a ping-pong protocol. Thanks to this approach, the two moderators can detect each other failure in a timely, and then perform the required actions to reestablish the optimal situation with the two moderators.

Moderator election strategies
In this Section we discuss two possible moderator election strategies and their implications on the protocol described in Sect. 5.
The first strategy considered is the random election strategy. In case a secondary moderator is needed, the moderator is chosen at random among the nodes inside the community, minus the primary moderator. This strategy comes in handy in the case where it is crucial to save all possible resources. Indeed it requires no additional storage, as the nodes are already stored in the moderator for the proper functioning of the protocol, no additional communication, and a negligible amount of computation, depending on how the node is chosen at random.
However having a different way to choose moderators can bring several benefits to the protocol, such as distributing more smartly the burden of being a moderator among the nodes. In particular, in this work, we try to define a strategy that is designed to optimise the communication resources of nodes, rather than computational or storage resources.
The approach we adopted involves the finding of the node, among the valid candidates, which minimises a measure. We define the load of a node u as follows: where M u is the number of messages received by node u, and B u is the bandwidth of node u. We add the constant term 1 to the number of messages received, so that if no messages are received, nodes with high bandwidth have a low load. When a new primary moderator is needed, among all the nodes in the community, the one with the lowest load is chosen. If a secondary moderator is needed, the node with the lowest load and that is not the primary moderator of the community is chosen. Thanks to this mechanism, we aim to choose as moderators the nodes that can handle a high amount of traffic. To implement this mechanism, we decided that each node needs to keep track of the messages it receives and send a periodic update message to the moderators of the communities it is part of. From the side of the moderator, it needs to keep track of the load factors of the nodes in the community using a data structure. Since the nodes send periodic updates about their load factor, but we do not expect a moderator election that frequently, moderators use a hash-addressed data structure for storing the load factors of nodes. This way we expect to pay constant time for the update of the load factor of each node, and the cost of sorting the load factors when an election is needed.

Experimental results
In this Section, we present the relevant experimental results obtained from the execution of DISCO on a dataset. Firstly, we present the dataset, its origin, and some preliminary analysis on both temporal information about the users and static community structure. Then we move on towards the evaluation of our implementation of Pastry, showing how much the DHT is impactful over our protocol for community detection. We continue by evaluating DISCO. The community structure detected by DISCO is evaluated in terms of number and average community size. The quality of the community is evaluated in terms of intra-community clustering coefficient, overlap coefficient, and F1 score. Lastly, community lifecycle events are reported. To assess the quality of the results, we compare them with the same results obtained from SONIC-MAN [28]. We decide to compare DISCO with SONIC-MAN because they work on similar assumptions and have an analogous application scenario, which can lead to a fair comparison. We also provide a detailed analysis concerning the messages used for the DISCO protocol and the underlying Pastry DHT. To conclude, we propose a comparison between the load balancing system introduced in DISCO, and the one adopted in SONIC-MAN.

The dataset
To have an evaluation that is the closest possible to a realworld scenario, we decided to use a dataset based on real users. The dataset was gathered on the popular OSN Facebook through an application called SocialCircles!. The application was developed and deployed in 2014, but is now under maintenance since the 1st of May 2015. This was because Facebook considerably reduced the size of its APIs, denying the necessary support for the correct functioning of the application. As presented in [41], the application was able to retrieve three sets of information: • Topology and profile information. For each of the registered users, we obtained its ego network and profile information. • Interactions. We also had access to the wall of the registered users, thus it was possible to obtain the interactions, such as posts, comments, likes, tags and photos, between him/her and his/her friends. • Online presence. An estimation of the online periods of the users. Indeed, the application was able to monitor the online status of registered users and their friends by analysing the chat status of Facebook every 5 minutes.
During its lifetime, the application was able to gather two datasets. In this work, we use the second one which includes 240 registered users, and 32 days of observation. The dataset is made of 240 registered users, for a total of 78.129 users observed, if we consider also the friends of the registered users. To execute our experiments, we used the topology information available, namely the EN of the 240 registered users, and the temporal information. The temporal observations lasted for 32 days, from the 9th of March 2015 to the 10th of April 2015. As result, we got a total of 9251 boolean observations for each of the 78.129 users: the value true in the i-th observation corresponds to the user being online during that observation.

Preliminary temporal information evaluation
The first preliminary observation concerns the temporal behaviour of users over the social network. Given the fact that we tackle the community detection problem in a temporal fashion, it is fundamental to have a deep understanding of the temporal information in our possession. We start by analysing which are the common trends of the temporal behaviour of all users both in terms of when to expect a large number of online users and which are the typical session of users.
Before presenting the results of our analysis, we briefly make an overview of the temporal information in our possession. In our dataset, time is discretised because of the restrictions imposed by the Facebook API. As described before, where s(u) i denotes the status we store for user u at time slot i, and observation is the value observed via the Facebook API.

Online users over time
The first analysis of temporal information aims to discover the general behaviour of users in terms of the typical time spans users connect to the OSN. What we expect is to see a periodic pattern following the day/night cycle with the rapid growth of online users early in the morning and a decrease somewhere in the evening. Figure 6 shows the number of online users over time. On the x-axis, we put the time slots and on the y-axis, we put the number of users such that s(u) = TRUE. As expected, by considering Fig. 6, we see that the plot can be divided into 32 parts with a quite similar structure. Taking a closer look at the arrangement of online users, we can see that the repeated pattern is made of one nadir and two peaks. The nadir, the time of the day where the amount of users is the least, is observed around 6 AM each day. The two peaks, which are instead the times of the day with the most online users, are observed around 12 PM (noon) and 9 PM each day. These observations follow a cyclic pattern of accesses to the OSN, most certainly guided by personal habits related to the day and night cycle. From the figure, we cannot ignore the fact that the fourth from the last day has a very different shape with respect to all the other days. This is because the fourth to last day of observations, the 6-th of April 2015, was Easter Monday, a holiday recognised in almost all of Europe. This surely had some impact both on the number of online users and therefore the community structure. Something we were not expecting to see so marked, is also a weekly pattern of accesses over the observed period. Considering that the observation started on a Tuesday, we can say that Fridays and Saturdays are the least crowded days of the week, while Monday is the most crowded day. Finally, analysing the number of online users time slot by time slot, we can see that there are at least 3,000 users online at the same time, roughly 3.8% of the total amount of users, Just from these observations, we expect the network to be very far from the static view given by the EN. This should reflect in a community structure where only bigger communities can survive, even if severely reduced in size. We also took into account this fact when we decided to make it easier for a node to join a community in DISCO.

Users sessions
Another relevant aspect of the preliminary study aims to understand the general pattern of access to the service by the users. To evaluate the pattern of accesses, we decided to study the online sessions of the users. An online session can be defined as the time span starting when a user goes online and ending when the user goes offline afterwards. In other words, a session for a user is a time span continuously spent in the OSN by that user.
The first measure we computed, related to the online session, is the number of sessions. The number of sessions gives us an insight into which is the typical pattern of access by the users. Figure 7 shows the Cumulative Distribution Function (CDF) of the number of sessions for each user. From the Figure, we can see that the number of sessions is rather high. In detail, more than half the users have more than 150 sessions which translates roughly into 5 sessions per day, on average. This Figure also shows that there is a small fraction of users which have no sessions, meaning that they were always found offline during the observations.
The second computed measure is the session length. Recalling the fact that time in our dataset is discretised, we assume that, if a user appears online during a time slot, it is online during all the duration of that time slot. This is the reason why here in this paper we measure the time in time slots rather than seconds (or one of its multiples). The CDF of the length of the sessions is presented in Fig. 8. Since the number of slots of the longest sessions is high, reaching 4,500 slots, here we propose a Figure showing only sessions with lengths less than 100 time slots. From this Figure, we can see, as expected, that sessions are not much longer. In fact, more than 80% of the sessions are no longer than 10 time slots, corresponding to 50 minutes, and half of the sessions are at most 3 time slots long. This is an extremely important fact to know because considering that nodes will not remain online for a long time, we can give up a bit on the community structure quality as long as the community joining process is fast.
The final analysis of the online session is the session inter-arrival time. The session inter-arrival time is the measure of how much time passes between two consecutive sessions of a user or, in other words, how much time a user is offline between two sessions. The CDF of the session interarrival time is shown in Fig. 9. Again, since for some users we had extremely long session inter-arrival times, here we propose a Figure showing only inter-arrival times whose length is less than 100 time slots. Session inter-arrival times are sensibly longer: 25% of the inter-arrivals are less than 5 time slots long, and over half of them are less than 15 time slots long. Nevertheless, they are short enough to expect a user splits his/her time spent on the OSN over many chunks throughout the day. In these preliminary temporal analyses, we showed that the network is highly dynamic and that node churn can be a real problem. We showed that the typical session of users is very short, around 15 minutes, and it rarely lasts for more than 1 hour. Session inter-arrival times are longer than session lengths, but confirm the fact that users tend to have many sessions per day, as already pointed out in the session count analysis.

Comparison between SONIC-MAN and DISCO
After the preliminary temporal study, we present a comparison between SONIC-MAN [28] and DISCO. The two protocols are simulated using PeerSim [42], an open-source P2P simulator written in Java. This choice was made because PeerSim is capable of simulating nodes with up to a few million nodes, network delays can be modelled easily, and it supports an event-driven simulation.

Number and size of communities
The first basic result we decided to investigate is the number and size of the communities at a generic level. Table 1 shows the minimum, maximum, mean and standard deviation of number, aggregated by ego network, and the size of the communities for the two approaches. In both cases, we observe a decent community structure, despite the heavy churn characterising the network. As we expected, DISCO has a slightly stronger community structure. This is because nodes can join communities more easily and get kicked out of them more hardly. A relatively negative result is the fact during some time slots some ENs have no community at all. This fact has to be taken into account when we will develop a system based on the community structure, because the absence of community structure can seriously hinder the quality of the service.
Another aspect worth investigating is the number of communities and the average size of communities through time. Figure 10 shows the total amount of communities, in green, and the average size of the communities, in red, for each time slot, of SONIC-MAN. The same information for DISCO can be found in Fig. 11. The plots confirm the intuition that the community structure is present, although quite fragmented. Comparing the two plots, we observe that SONIC-MAN has a more fragmented view of the community structure since it detects a number of communities that is highly irregular over time. This confirms that a triangle-only community definition, if the network is characterised by high churn, leads to a situation in which the community structure is not always reliable. As expected, the two measures tend to follow the day/night cycle already observed in Fig. 6.

Community quality evaluation
After evaluating the community structure in a general way, we move to the evaluation of the community quality in terms of several measures.
Since the definition of community in both proposals is heavily based on the triangles, the first measure we observed is the clustering coefficient. The clustering coefficient of a community is that of the sub-graph corresponding to the community. What we expect is that in SONIC-MAN the clustering coefficient is quite high because nodes must close triangles with nodes inside the community to be able to join it. Comparing it with DISCO we aim to show that with the relaxing joining conditions, the clustering coefficient does not drop dramatically. Figure 12 shows the evolution of some percentiles of the clustering coefficient of the communities found by SONIC-MAN over time. Figure 13 shows the same percentiles for the communities detected by DISCO.
Both the plots show that communities are well clusterised, thanks to the fact that they rely on the concept of triangle to build a community. In particular, as expected, communities detected by SONIC-MAN are more clustered because finding triangles in the graph is the leading idea of the approach. Results obtained from DISCO in terms of clustering coefficient of the communities are satisfactory, considering the relaxed join conditions. Indeed, even though communities can contain a very small number of triangles, the clustering coefficient is greater than 0.4 almost at all times. But we must keep in mind that join and leave operations are lighter.
A second measure we evaluated is the overlapping of the communities belonging to the same ego network and the same time slot. We say that two communities overlap if they share some nodes. For this evaluation, we introduce an overlapping index defined as: where c e t i denotes the i-th community of the ego network e at time slot t as a set of nodes. This formula returns 0 if the communities are completely disjoint, and it returns the number of the communities if all the nodes belong to all the communities. In both proposals, if the communities are made of the same nodes, the two communities merge, so we expect to achieve relatively low values of overlapping. Low values of overlapping are also expected because nodes seek to be part of at least one community, and they will not search for more communities to join. Figures 14 and 15 show the evolution of some meaningful percentiles of our overlapping index of the communities detected by SONIC-MAN and DISCO respectively. This effect was not fully expected, because nodes do not continuously try to join as many communities as they can. As explained in Sect. 5, nodes will try to join new communities built inside an EN only if they lack communities for that particular EN. Communities detected by SONIC-MAN show good overlapping, but the fact that nodes must be involved in triangles to join a community, makes the structure quite strict. With DISCO, we obtain a substantial increase in the overlapping thanks to the less strict join conditions which promote the joining of multiple communities and a more robust community structure. We can also see that the overlap follows a trend similar to the number of users online (Fig. 6). High values of overlap are obtained during the daytime time slots, while during the night the overlap drops drastically, reaching a situation where most of the communities are disjointed.
Finally, we evaluated the stability of the communities as they evolve through time in terms of communities and nodes making these communities using the F1_score [43]. This measure was originally proposed to evaluate community detection algorithms by comparing the communities detected by the evaluated algorithms with a given ground truth set of communities. In our case, since the aim is quite different, and since we do not have a ground truth, we evaluate the communities of an ego network e detected at time slot t using as ground truth the ones detected in the same ego network e at the previous time slot t − 1 . With this particular setup, we aim to give an evaluation of how much the main communities are stable over time. Figure 16 shows the evolution of some percentiles of the F1_score of the communities found by SONIC-MAN over time. Instead, Fig. 17 shows the same percentiles for the communities detected by DISCO.
Both the plots show that, despite node churn, the communities detected by the two proposals are quite stable, achieving F1 values almost always greater than 0.8. During the first time slots of the simulation, we see that the values are lower and more unstable. This is caused by a "bootstrap phase", during which there were no communities because the simulation just started. This situation is quickly fixed and it does not show up anymore during the simulation. Finally, the trend of the F1 is the opposite with respect to one of the numbers of online users shown in Fig. 6. This translates into the fact that communities are more stable during nighttime. This is a reasonable result since it is during these time slots that the churn is at its lowest effect.
In this Section, we analysed the community structure obtained by SONIC-MAN and DISCO. We observed that, despite DISCO using a more loose definition of community, it still obtained a meaningful community structure. In particular, DISCO obtained a lower clustering

Community life-cycle events
Lastly, since they characterise the community life, we decided to investigate the dynamic community events. We recall that, in our scenario, we decided to consider only 4 main events introduced earlier in Sect. 4.2: Birth, Death, Merge and Split. Table 2 shows some statistics of the number of events aggregated by time slot for the two versions of the algorithm. From the table, we can see that communities of SONIC-MAN are affected by a higher number of events, in particular Births. Also merge and events are sensibly higher in SONIC-MAN, which suggests that communities are much more prone to be merged together once they form.
Again, to have a temporal understanding of the community events, we made some plots. Figures 18 and 19 show the number of community events per time slot for SONIC-MAN and DISCO respectively. The two plots confirm the fact that SONIC-MAN is exposed to a higher amount of events and that, considering the fact that we used a different scale for birth events with respect to the other events, births are also the strong majority of the events detected in both cases. Nevertheless, the number of death, merge and split events is more balanced in SONIC-MAN, meaning that communities show a more complex lifecycle.
Another interesting aspect is the fact that the arrangement of the events follows, in both cases, a pattern that is quite similar to the one in Fig. 6. This means that also communities tend to follow a daily pattern and, most of all, that communities show more dynamism when more nodes are online.

Message showdown
As a final analysis, we made some analysis on the number of the messages exchanged by the two protocols used in the simulation: our implementation of Pastry, and DISCO. In this showdown, we will compare the number of messages for both the protocols, dividing each time these messages into three sets, according to their role in the protocol. We will also make some final considerations about the total number of messages.

DISCO messages
In this section we analyse the number of messages generated by DISCO. We decided to divide the messages into the three following sets:  • Generic node messages: in this set fall all the messages are exclusively sent by generic nodes to moderators. The set is made of three message types: join messages, sent when the node wants to join a community, the leave messages, sent when the node is going offline and wants to leave the network, and the load messages, which are the messages used to periodically update a node's load factor. • Moderator messages: in this set fall all the messages exclusively sent by the primary moderators to nodes inside the communities these nodes are managing. The set is made of four messages, all related to the life of the community. These messages are the core messages of the protocol. • Ping-Pong messages: in this set fall the messages used for the ping-pong protocol between nodes. Figures 20,21,and 22 show the number of messages that arrived at the destination for each time slot. The results were split into three plots for readability and are grouped following the three sets presented above. All the plots show a similar and expected arrangement, which is similar to the one in Fig. 6. We can observe an anomaly right before time slot 6000 at which the number of events drops dramatically to 0. By observing the log files of SocialCircles! we discovered that our application was not able to communicate with the Facebook servers at some point during the crawling process. This caused our application to record all users offline during that period of time. Since there was no way to recover, even partially, the information lost, we decided to "freeze" the network before they fail, setting the status of all users of all time slots during the failure to the same one preceding the failure. Freezing the network obviously led to a dramatic drop in the number of messages exchanged by all the nodes. Figure 23 shows a comparison between the contribution of the messages from the three sets. From the pie chart, we can see that almost 60% of the messages are for the core functioning of DISCO (the ones not belonging to Ping-Pong set). Nevertheless, the Ping-Pong set is the biggest one, having more than 40%.

Pastry messages
In this Section, we analyse the number of messages generated by our implementation of the Pastry DHT. Again, we decided to divide all the messages generated into three sets, according to their role within the protocol: to the joining operations, namely join requests and join replies. • DHT modification messages: in this set, we find all messages that are used to modify the contents of the DHT. Within this set we find three messages: add, add_all and remove. • DHT querying messages: in this set falls all the messages used for the querying of the contents of the DHT, namely query and query_hit messages. Figures 25,26,and 27 show the number of each message that arrived at the destination for each time slot. The number of messages was once again split into three plots for readability and are grouped following the three sets presented above. As expected, the general trend observed throughout all the analyses is confirmed, showing the intuitive fact that the number of messages is highest when more users are online. The effect of the freezing of the network status is visible also in these plots, just before time slot 6000, when the number of all messages drops dramatically to 0. Figure 24 shows the contribution of each set of messages to the total of messages generated by our implementation of Pastry. The pie chart shows that query and query hit messages are the vast majority of the messages generated by the protocol, being more than 95% of the messages.

Impact of load balancing
In this last Section, we analyse what is the impact of the newly added mechanism of load balancing. In order to make a fair comparison, we evaluate the number of messages moderators receive for the management of the communities. In the case of the older approach SONIC-MAN, which does not have a load balancing mechanism, we only consider the JOIN and LEAVE messages. Instead, in the case of DISCO, we consider not only the JOIN and LEAVE messages, but also the periodic messages node send to their moderators to notify their load factor. This set of messages was presented in Sect. 6.4.1 as the Generic node messages. This should help us to estimate the increased amount of communication required for the added mechanism to work. Figure 28 shows the average number of messages moderators receive as part of their duty, as discussed above, in reading for SONIC-MAN and in green for DISCO. Results are deseasoned showing aggregated average values for 288 timeslots, which is the number of timeslots in a day. From the plot, it emerges that until day 13 the two approaches put a similar burden on the moderators, but on average moderators in DISCO are slight more loaded. This is mostly due to the cold start of the load balancing mechanism which requires some more messages to start working properly. However, from day 14 and onward we clearly see that the burden of messages on moderators of SONIC-MAN is 25% to 50% higher. This difference is due to two effects: a steep increase in the number of messages handled by SONIC-MAN moderators starting from day 14 and a slightly decrease over time in the number of messages handled by moderators of DISCO. Taking a closer look at the logs, we observed that in SONIC-MAN, the number of JOIN messages heavily increased after day 13. Trying to understand what is causing this abnormal amount of messages, we looked at the overall community structure of the approach shown in Fig. 10. Indeed community structure is unstable in terms of the number of communities around day 13 (which is made of the timeslot from 3456 to 3743), and this effect is also present later on during the experiments. Further analyses of the logs, showed that in SONIC-MAN a lot of nodes were not able to join any community for several timeslots from day 13 and onward. Since nodes will actively try to be included in at least one community, this can cause a lot of messages to circulate at each time slot if multiple nodes are not able to find a community. In the case of DISCO, we do not see a similar instability in the community structure, nodes are not required to try again to send messages to join a community, and therefore moderators result in having to handle a smaller number of messages on average. The logs of the experiments uncover that in this case, nodes are usually able to join or create a community right when they join the network, rather than having to wait for several timeslots. Therefore we can conclude that the updated algorithm for community detection, and in particular the new condition explained in Sect. 4.3, resulted in an accidental optimisation of the communication required, despite the added load balancing mechanism.

Conclusion and future works
In this paper, we presented DISCO, a distributed protocol for local community detection and management. The protocol is targeted for decentralised social applications, and adopts the ego network to model the social overlay. DISCO follows a Temporal Trade-off pattern, meaning that communities are kept updated over time. The community structure defined by DISCO is based on triangles and triads which contribute respectively to create a clusterised structure, and in lowering the computational effort to carry out the detection and management task. Communities detected by DISCO are local to each ego network to take into account the application scenario and the potential usage of the detected structure in a DOSN. Additionally, thanks to a more mindful management of the nodes joining and leaving the network, communities are updated only locally to nodes changing their online state. Lastly, while the detection is carried out by all peers, the management of each community is charged to super-peer nodes, called moderators, which are elected through a policy that distributes the computational and network load among all peers. Results showed that DISCO creates a meaningful community structure, and by comparing it to a similar approach we observe a more complex and stable community structure with a substantial gain in the overlapping of communities. Thanks to a looser definition of community and localised management of the community structure, we observed a much lower time required to run the 240 simulations of one month each. Lastly, the load balancing mechanism introduced in this work is able to improve by 30% the average moderator loading factor with respect to a random election strategy.
As future work, we plan to study more advanced strategies for moderator selection. One possible direction is to integrate DISCO in existing services, such as a group communication service, to explore the possibility of creating socially-aware temporal communication channels. Considering that social networks can be highly contextual environments, we plan to explore ways to adapt DISCO to this scenario, for instance by detecting a different community structure in each different context. Another possible future work is to consider the EN structure as a weighted graph, where each edge weight corresponds to the tie strength (or other measures) between the pair of users connected by the edge. We also plan to investigate more on the elasticity given by the super peer approach, for instance letting moderators behave differently. Finally, we also plan to design a completely decentralised version of the algorithm, without the need of super-peers.
Funding Open access funding provided by Università di Pisa within the CRUI-CARE Agreement.

Conflict of interest The authors declare no conflict of interest/competing interests.
Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http:// creat iveco mmons. org/ licen ses/ by/4. 0/.