What we need to do in the future
The current situation for small social network sites is not even close to perfect. There is work that needs to be done to make this idea better and more viable for more kinds of people.

Places where we need better tech
Most of the problems that exist are social problems with social solutions, and I've tried to lay some of those out above. But there are still unsolved problems where better tech could really help, so I'll try to enumerate those here.

Fluidity of identity and the ability to migrate
The existence of a server and an administrator implies some local form of centralization. I think this is necessary because most people don't want to run their own network node, and there are fantastic benefits to having a trusted local administrator. That said, the drawbacks are also great and we need to be able to mitigate the drawbacks.

What happens if I, as the administrator, violate the social norms of my own community? In other words, what happens if the person with all the real power is the problem?

People need to be able to jump ship and migrate their accounts, seamlessly and wholly, to other servers. We do not have a good technical solution for this yet. In my opinion it is the one big area regarding federated social networks where we need to work on technical solutions.

If I decide that my values no longer align with a server, I need to be able to take that account to a new server. If the server decides to kick me off, that's fine, but I should in theory be able to set up shop elsewhere.

I know that people have been working on this issue, but as far as I'm aware it's nowhere near resolved. As it stands right now, the fact that you can't uproot and take your stuff with you from one site to another means there is a very real kind of lock-in. This helps with enforcement (as I said above) but is a huge liability when it's simply the choice of the individual to move.

Let people keep things in the community
Most open source social network software right now is designed to get your messages out to as many people as possible. We need support for private communities. For federated social networks this means support for messages that don't federate and can only be viewed by people with access to the server on which the message was posted.

Unlike the identity problem, this is a very easy thing to implement technically. It already exists on a minority of open source social network servers. But the big players don't support it and that's causing more harm than good.

There is currently a pull request open on Mastodon by Renato Lond that implements exactly this feature. It's derived from glitch-soc, a Mastodon fork.
Server forking should be easy
It should be easy for, say, 25 members of Friend Camp to pick up and start "Friend Camp 2". This could be because Friend Camp is getting too big, or it could be because these people don't like what Friend Camp has become and would like to move en masse.

As far as I'm aware there is no work at all being done on this issue, but I suppose a prerequisite to this is a solution to the identity migration problem above.

Lean software that doesn't have to scale
What if we built software to run on very low spec, low power machines, that was a federated social media server for 50 people but could never grow to support more than that? You could use something like SQLite instead of a "real" database because you'd never realistically have to support a lot of writes to the DB. You could run on a raspberry pi.

There are some federated servers that fit this bill already. Pleroma is a Twitter style server that extremely light on its use of resources. And Write Freely, a federated Medium-style blogging server, is incredibly lean as well.

But even Pleroma and Write Freely are built with thousands of users in mind. What kind of low tech solutions can we enable if we keep our communities intentionally small? This may open up more paths to equitable access by communities with different resources available to them.

More on scale
Any time I propose a new piece of software to a group of software engineers I'm asked the same question: how will it scale? We are trained as a group to ask this question. I think it's the software equivalent of in manufacturing when someone asks "What will it cost to produce?" Since the marginal cost of producing software is effectively zero, it's the scale, the ability for the software to be used by millions or billions of people, that becomes the limiting factor that everyone brings up.

Imagine two different software developers. One person writes a piece of software that makes the lives of one million people slightly easier. Maybe it's better routing for navigation software and it shaves 30 seconds off the commute of a million people. Another person writes a piece of software that only ten people ever use, but it tangibly changes their lives for the better in very material ways; maybe they learn a trade that becomes a career.

One of these outcomes is not necessarily better than the other, and yet due to myriad factors, only the software with a million users is likely to get funding from entities—whether the context is for profit or not for profit.

I'd like to advance the notion that software does not have to scale, and in fact software can be better if it is not built to scale. I hope some of the examples I've given above have illustrated what is possible when software is used by a small number of people instead of a large number of people.

Beyond local and public: the neighborhood
Right now on federated social networks you have a concept of people on your own "home" server (which I'll call local) and people on every other server in the world (which I'll call public). But we need concepts that are more fine grained than local and public.

I would like to see groups of servers that band together through a kind of mutual approval system. The group of people on Server A decide that Server B is to be trusted, and vice versa. They approve each other, in a manner similar to friending someone on Facebook, but for a whole server instead of an individual user. Now the 50 people on server A and the 50 people on server B are in a "neighborhood" together.

Servers that belong to the same neighborhood could share things with each other. For example, the servers could share access to posts that are tagged on either server as "available to the neighborhood". Servers could share block lists, since mutual trust between servers probably implies some level of shared values between the people on both servers.

A neighborhood would necessarily consist of two or more servers, and could in theory grow to be very large.

However, I don't think neighborhoods should be very big themselves. I think there should be a kind of mutual decision-making, so perhaps now that A and B are connected, both A and B have to agree that C is worth connecting to, and C has to agree that A and B are worth it. This makes every extra node you add more difficult, which is the point. Big "private" communities should be very very hard to come by — and "public" should be where the "broad" conversations happen.

I also think there shouldn't be concepts of overlapping Venn diagrams of multiple neighborhoods. I loved the concept from Google Plus of circles. The idea was that as a person you have friends, coworkers, college friends, family, IRL neighbors, etc. People you "know" on Google Plus could belong to none, one, or more than one of these groups. A childhood friend who you also work with would probably belong to "friends", "childhood friends", and "coworkers". This system sounded great to me… until I tried it in practice. And in practice it was so much tedious digital paperwork to keep it all fresh and updated. I didn't want to manage people into one or more of dozens of categories and in the end I just went for the default "mutual friends on the social network" and "public" circles.

I think many of us can hold three of these groups in our head though, especially if it's not the job of the individual user to constantly maintain it. I'm sure lots of people can hold more than three groups in their head at a time, but I'm picking the smallest useful number in order to reduce the confusion I experienced with Google's "circles" feature.

So for me an ideal network would be partitioned into three basic levels for posting:

local - just the people on my physical server
neighborhood - the concept I described above of people who belong to servers that have a mutual trust agreement
public - everyone in the world
This would be in addition to the usual layers of "followers only" and that kind of thing.

One way I see this breaking down is:

local - tin foil hat stuff, "I do not want this message to leave this piece of metal", or perhaps the very intimate like "only local mutual followers get to see my nudes"
neighborhood - most of your friendly chatter and ideological debate happens here
public - the place for things that are inconsequential (cute cats and jokes), or require signal boosting, or where you really want to put an idea in front of the public

