In decentralized networks, whether federated or p2p, there is often no global search functionality, as no node has a unified view of the network. This section covers methods of content discovery in decentralized social networks.
Data availability in decentralized social networks can be discussed in terms of the [CAP theorem](https://en.wikipedia.org/wiki/CAP_theorem), which states that a distributed data store can only provide two out of the three guarantees: Consistency, Availability, and Partition tolerance. Centralized social networks are consistent - all users see the most recent state of the network, or an error. Decentralized networks often sacrifice consistency for availability and partition tolerance. Networks that prioritize availability over consistency will always process a query and return the most recent version of the information even if it can’t guarantee that it’s up to date.
Mastodon servers store content from users followed by members of the server. Users are presented with three timelines: a home timeline with posts from accounts the user follows, a local timeline with posts from the local instance, and a federated timeline with all posts that have been retrieved from remote instances. There is no global search functionality. This issue being discussed in Mastodon: https://github.com/tootsuite/mastodon/issues/9529
Mastodon has [public relays](https://source.joinmastodon.org/mastodon/pub-relay) which rebroadcast anything sent to it to anyone who subscribes to the pub.
To overcome the difficulties of new users finding people to follow to get connected to the network, [Trunk](https://communitywiki.org/trunk/) is a community-built tool that helps users find and follow people by category. Users have requested a global directory for [importing friends from other networks](https://github.com/tootsuite/mastodon/issues/11886). Mastodon users used to be able to find their Twitter friends using `bridge.joinmastodon.org`, but the service was shut down after the developer lost access to API keys and was not granted another set.
All conversations on Matrix take place through rooms, which people either join (if public), peek into (if viewable), or are invited to. Because of its focus on conversations in rooms, there is no focus on having globally discoverable content.
Matrix [optimizes for Availability and Partition Tolerance](https://matrix.org/docs/spec/) at the expense of Consistency. Homeservers model communication history as a partially ordered graph of events known as the room's "event graph", which is synchronised with eventual consistency between the participating servers using the "Server-Server API".
Content is propagated and discovered through follow relationships in the ssb network. When a follow relationship is initiated, the posts of the user being followed begins to be synced to the follower's node. Those messages and files are stored locally on the user's computer, indefinitely, for applications running ssb to read.
Ssb prioritizes Availability and Partition Tolerance over Consistency. No node has a global view of the network, but can sync data with any other node it is connected to. Ssb applications can be used locally or offline, and the append-only log ensures that data will be ordered correctly, even if it is not up-to-date. Once synced to the network, a user will always see content when they open an ssb application.
### Blockchain social networks
Blockchain social networks essentially treat the blockchain as a distributed database guaranteeing global availability of content, prioritizing Consistency. Applications that store data on chain usually do not have Availability, as the user cannot get the most recent state unless they are connected to the blockchain. Tradeoffs of storing social network data on a blockchain include making the data public, immutable, and adding performance overhead for full-node servers that must sync the full state of the chain and perform mining or validation functions.
