Our social networks are almost all entirely unbounded. Most are VC funded and aim to connect every human on the planet in order to maximize profits. Unfortunately, this unlimited growth has severe consequences which we are only just now starting to understand. But large networks have benefits as well as dangers. For certain applications, a larger network increases its utility. If I want to sell items to strangers, the more strangers in my network, the more likely I’ll make a sale.

Is there a way to get the best of both worlds? Is there a system that allows us to dial in the size of the network to reduce the risks and maintain the preferred function? I believe there is.

How it works

ten_cubed is an artificially restricted social graph that has three key concepts:

1. Users can have no more than 10 connections in their immediate network
2. Users have three levels of their network (1st, 2nd and 3rd degree) with a theoretical maximum of 1,110 total connections
3. Users can set the maximum degree allowed from within their respective apps/services

Let’s break this down to understand it further.

Maximum of 10 immediate connections

Users cannot have more than ten connections ever. Adding a new connection when you already have 10 connections means you have to remove an existing connection. This limitation mirrors our real-world intimate connections (close friends and family).

Users have three levels of their network

A user’s network breaks down as follows:

• 1st degree → 10 connections
• 2nd degree → 100 connections
• 3rd degree → 1000 connections

Max total connections: 10 + 100 + 1000 = 1,110.

Hence the name “ten_cubed”: (10 x 10 x 10).

These network limitations are similar to Dunbar’s Number and reflect how our social groups in the real world are managed. We generally have approximately ten immediate friends and family. One hundred people is around the size of a small village or town. Lastly, around a thousand people is the size of a small city or neighborhood within a larger city, and basically the limit of individuals our memory can track.

Users determine their max degree of connections

When a service or application uses ten_cubed, it allows users to control what data their connections can access. Those who value privacy may disable 2nd and 3rd degree connections, restricting their network to only 10 total connections. For others, they may default to 3rd degree for everything. The user decides. Regardless of choice, there will never be more than 1,110 total connections for any user.

An example of this in action: I built an application that allowed individuals to loan out items to their network. One of the features was the ability to set a specific item’s max network degree. This was useful for instances where a user wanted to offer an item that was potentially dangerous or expensive, but only wanted close friends to be able to borrow.

What are the benefits?

With these limitations in place, some interesting side effects occur. The first is that virality of content is immediately presented with friction: content can easily propagate across a user’s network (1st -> 3rd connections), but it must be “reshared” into other user’s core network before it continues its journey. Unlike TikTok or other networks which push content out across millions of user’s feeds, ten_cubed networks require much more manual intervention to keep content viral. This friction makes ten_cubed networks unsuitable for large and nefarious foreign state attacks. It’s too difficult to do widespread damage across the network; the attack doesn’t scale well.

Second, the value of a user’s connections dramatically increases. Due to the 10 connection limit, applications leveraging ten_cubed can lean into the value and high level of trust for those connections. In services like LinkedIn or Facebook, after years of use and accumulating connections, the value of one’s first degree network is virtually non-existent. Having 1000+ first degree connections means the user has no idea who most of those people are. In ten_cubed, the 1st degree is coveted and the user most likely knows and trusts each connection deeply. Applications can use this to build functionality that other hyper-scaled networks cannot.

Third, there are no influencers. A user cannot accumulate thousands or millions of followers. This prevents the “enshittification” that eventually affects all unbounded social networks, and dramatically changes the way users interact with the site. By limiting the network, users are simply not able to leverage their followers to generate money in questionable ways.

What are the drawbacks?

Any application that benefits from an unbounded network does not map well to ten_cubed. These applications are typically one-to-many communication platforms, like Twitter. This is because the connection limit means you can never grow your audience beyond 1,110 total connections. However, I’d argue that these platforms are fundamentally dangerous (to be discussed further in another article) and should be dramatically limited to special entities.

In addition, the network is somewhat more volatile. If a 1st degree connection is removed by the user, the user immediately loses access to the disconnected connection’s 2nd and 3rd degree connections. This means that as users add and remove connections, their network can grow or shrink in surprising ways. It’s up to the application creators to determine how to handle this volatility. Do you hide the content created by previous connections? Do you show it but label it? If some transactions are pending when a connection is lost, do you cancel it?

Example Postgresql code

Below is the simple code I use in my Rails apps to recursively navigate through the social graph. It checks to make sure the degree selection is within the bounds of the target users. Note that the code has Ruby symbols mixed in with it.

	
WITH RECURSIVE friend_of_friend AS (
    -- Initial selection of direct friends
    SELECT 
        connections.target_id,
        users.max_degree,
        1 AS depth
    FROM connections
    JOIN users ON connections.target_id = users.id
    WHERE connections.user_id = :user_id
    
    UNION ALL
    
    -- Recursive part to find friends of friends
    SELECT 
        connections.target_id,
        users.max_degree,
        depth + 1
    FROM connections
    JOIN users ON connections.target_id = users.id
    JOIN friend_of_friend ON connections.user_id = friend_of_friend.target_id
    WHERE depth < :max_depth
        AND depth < users.max_degree
)
-- Final selection with distinct users
SELECT DISTINCT ON (users.id)
    users.*,
    friend_of_friend.depth AS degree
FROM users
JOIN friend_of_friend ON users.id = friend_of_friend.target_id
WHERE users.id != :user_id
ORDER BY users.id, friend_of_friend.depth;
	

Conclusion

I’m looking forward to seeing what applications people develop with ten_cubed. There are many ideas that work incredibly well with the inherent limitations it provides.