Tomorrow's social networks

Dhananjay Tanikella

— 6 min read
Tomorrow's social networks
Photo by Alina Grubnyak / Unsplash

Today's average internet experience is dominated by centralized experiences. Depending on the app/service you're using, it's very likely that one entity controls the infrastructure, rules, and the data that you interact with. But is this our only option?

When you pull up your TikTok feed, scroll through Reddit, or even when relatives are posting on Facebook, we're all interacting with centralized infrastructure. These applications let you send and receive content with your friends and let you browse other content they host on their server (your feed). In exchange for hosting your content, and allowing you to continue using the app, they use your data for targeted ads, learning your habits, etc. Lately, these applications have also started closely controlling what you see when you're browsing these feeds (possibly influencing elections, etc. etc.).

The alternatives to a centralized application are a fully decentralized experience, or a federated experience.

Think of a decentralized experience as one where there is never any one single owner. In the same way that Bitcoin is a completely peer-to-peer currency through its distributed ledger, or BitTorrent is a decentralized file-sharing network. There is no singular owner, and everyone contributes to the network.

Federation is the middle. You can stand up an email server today, and be able to send/receive emails from any email address. As long as you follow common protocols (iMAP, POP3), you are able to communicate with gmail, hotmail, yahoo, etc. accounts. A non-digital example is actually physical mail. Each country has its own postal authority that operates independently. They set their own rules, and own their own infrastructure. But they all agree to a common set of protocols (administered by the Universal Postal Union). We'll be talking about a Federated Social Networking option in this blog.

Federated Social Network

In short, this is how the concept works:

  • You own a federated social network account (either hosted on your own server, or with a company you trust)
  • You can send content to anyone (even the public)
  • You can receive content from anyone (that you chose to receive content from)
  • There is no longer a difference between content hosted on TikTok vs Instagram
    • Your account can send messages/content in both
    • Your account can receive messages/content from both

Pros

  • You have one feed that you control
  • You own your own identity/data, and control when they are shared and with whom

Cons

  • Curation becomes a larger problem - You have to be active in choosing what shows up on your feed. Whereas in todays world, it's almost a passive action (your social media app usually does this through a proprietary algorithm)
  • Content moderation - Now it's each server's responsibility to moderate the content that's being hosted on it. Whereas in the centralized model, it's those companies' responsibilities.
  • Economics and load - It's a heavily technical task to stand up and maintain your own federated server. It also costs money, whereas joining a large social network oftentimes is free.
  • The two popular protocols are not fully mature, and a lot of work is left to bring them to parity with current social networks (see the nerdy stuff below for more details on this)

Today vs Tomorrow

We can break down the responsibilities of a social network in the following ways:

  • Identity management: Allow users to manage, and control their own identities
  • Content management: Allow users to create, read, and manage content
  • Content interaction: Allow users to interact with content (comment, vote, like, etc.)
  • Content curation: Personalize the content that is displayed to every user. Help users discover new content.

In a federated ecosystem, users own and control their own identities, content, and actions. Because of universal protocols (ActivityPub, ATProtocol, etc.), these concepts are universal, and act the same no matter what social network you're in. Some of these universal protocols enforce a chronological feed, others give the server freedom to determine its own algorithm. This is the key differentiator for social networks in a federated ecosystem. The Reddits, Facebooks, and TikToks can focus on curation. They can provide custom algorithms to users who can use them in their own applications.

Federated Options

There are two popular protocols that align with a federated model. Those are ActivityPub, and ATProtocol. The common user is probably more familiar with their most popular implementations in Mastodon and BlueSky respectively. We'll dive deep into the technicals of both options below, but roughly what you should know:

  • ActivityPub
    • Your identity lives on a specific server. If you want to move servers, you start a new identity
    • There is no global index, and it's intentionally harder to crawl. This makes aggregation, and search across all ActivityPub servers much harder
    • Chronological-first feed by design. Your feed is no longer determined by an algorithm
    • No standard for moderation. It's left up to individual servers to implement their own
  • ATProtocol
    • Portable identity. Your account isn't tied to any one server
    • Makes it easy to build search/aggregation across multiple servers
    • Supports swappable/customizable feeds. The user can choose, or build their own feed algorithm
    • Separates moderation into a composable, third party service
    • Almost entirely owned, operated by a private company (BlueSky)
  • Both
    • Open, decentralized protocols
    • Support common social primitives (posts, follows, likes, etc.)
    • Designed to enable independence from singular servers/services
    • Very young protocols that are still growing. Lots of questions unanswered on both:
      • identity & security concerns
      • account management isn't fully matured
      • e2e encryption support
      • content moderation & safety is very immature

Some nerdy details below. Feel free to skip to the end :)

ActivityPub

Concepts
  • Actor
    • user's account on a server
    • entities that are capable of carrying out an Activity
  • Object
    • An object of any kind
    • Note, Video, Article, Profile, etc.
  • Activity
    • provide information about actions that may, in the process of, or have already occurred
    • the type field determines the type of action. Some common types include:
      • block
      • follow
      • like/dislike
  • Collection
    • Serves as a container for other Objects or Links
    • Common collections are:
      • Outbox: outbox stream contains activities the user has published
        • contents of outbox are filtered by permissions of the person reading it
      • Inbox: stream contains all activities received by the actor
        • should filter content according to requester's permission
        • server performs de-duplication of activities returned by the inbox
      • Followers: list of everyone who has sent a Follow activity for the actor
Missing Pieces

In the base implementation of this protocol, you can tell there are a couple of things missing in the spec. Namely, user discovery, auth, and a way to expose instance information. There are various solutions that are popular to fill these gaps. The most popular implementation of ActivityPub is Mastodon. They use WebFinger for their user discovery. ActivityPub remains the open-ended, less opinionated protocol of the two popular protocols.

AT Protocol

Concepts
  • DiD Identifiers (Identity)
    • account control is rooted in stable DiD identifiers in the form of:
      • did:web: W3C standard
      • did:plc: Bluesky method
    • while DiDs are the long-term identifier for accounts, handles are the less-permanent identifier
      • generally a handle is expected to resolve to a DiD
      • DNS TXT example: DNS TXT record is registered for the _atproto sub-domain, with the handle as the hostname
  • Repositories (Data)
    • collection of data published by a single user
    • repositories are self-authenticating, meaning each update is signed, and can be verified by anyone
    • content of a repo is laid out in a Merkle Search Tree (MST)
    • a Relay is an aggregator of data repos. BlueSky is considered a centralized ATProto relay. When you create a BlueSky account, your repo will be a part of the BlueSky relay's firehose
  • Network
    • client-server and server-server API definitions
    • AT URI Scheme
      • uri scheme makes it easy to reference individual records in a specific repo
      • uris can also be used to reference a collection within a repo (or an entire repo)
    • Personal Data Server (PDS)
      • acts as an account's trusted agent in the network
      • routes client network requests
      • hosts repositories
    • Syncing
      • Realtime
        • Firehose relay
        • Repo event stream broadcasts
          • updates to repositories (#commit events)
          • handles and DiD documents (#identity)
          • account hosting status (#account)
      • Batch: repo export CAR files
Missing Pieces

In practice, BlueSky runs the only major Relay that's being used. So the implementation is very centralized to BlueSky. Self-hosting an ATProto instance is possible, but complicated, and not easily accessible. Unlike ActivityPub's ActivityStreams, the Lexicon of ATProtocol is not governed by a clear independent body.

TL:DR

I'll admit, we've lost our way a little bit through this blog. What I hope you walk away with is:

  • There are alternatives to a centralized social network
  • These alternatives give users much more power over their own identity/data
  • It is possible to reduce the impact that our algorithms have on our social network experience
  • The alternatives in question are still very young, and require a lot more support/development

References