dariusk
commented
1 year ago NOTE: This was copied by me from my own Patreon backer blog, for outside reference.
This article is something I would call maybe a design journal. A little bit of a rant into the void. I do not take my usual care to explain what concepts like "fediverse" mean, so you should already probably be somewhat aware of decentralized social media if you're going to understand this. I can recommend reading https://runyourown.social if you haven't, as that will cover a lot of these ideas and in fact was the genesis of this concept in the first place.
So, on to the rant.
What is a Neighborhood?
Hometown's most distinctive feature that makes it different from Mastodon is that you can make local-only posts. That is to say, if you and I are both members of coolpeople.social and I post something "local-only", you will be able to see it along with any other people who have accounts on coolpeople.social. But someone on regularpeople.social will not be able to see it. This allows for two layers of communication: a high-trust local layer where you are only talking to people in your own vetted server who all abide by the same rules as you (if the server is being run well), and a low-trust "federated" layer that is more like a public, world-readable post you would put on Twitter.
I am now working on a third layer of communication: a medium-trust layer. This layer (which is actually pretty high trust as far as these things go) is called a "neighborhood". Let's say that the users of coolpeople.social have decided that the users of awesomepeople.social are really amazing and they want to share more with them. The coolpeople and the awesomepeople mutually decide to join a "neighborhood", which means that neighborhood-level posts on either server can be seen by everyone on both servers.
This means that when you make a post on Hometown there will be three choices in a little dropdown toggle:
- local (just the people on your server)
- neighborhood (just the people on your server and a small group of other servers)
- federated (the whole world)
Here's a tricky thing that I think is key to the whole feature: any server can only belong to one neighborhood. What this means in practice is that if coolpeople.social wants to add radpeople.social to the neighborhood, they can't just create neighborhood2 and then add them. Instead they need to check with awesomepeople.social and everyone needs to mutually agree to add that new server to the neighborhood they already belong to. This means that every additional server added to the neighborhood takes more social effort and mutual agreement than the last.
(While I want neighborhoods to be high-friction to join, I want them to be low-friction to leave. Ideally if coolpeople.social decide they want to abandon the neighborhood they have spent time building up, they can simply choose to leave. There will also need to be a mechanism for consensus to remove a server from a neighborhood if they suddenly start acting in bad faith.)
The limitation to a single neighborhood means there is only one "neighborhood" that a user has to conceptually keep in their head. I keep thinking back to the concept of "circles" from Google Plus, where you could have potentially infinite little groups of people who represent different pieces of your life (work, family, soccer league, etc) and thus get to see different things you post. It was great in theory but in practice it was enormous cognitive overload even once you hit two or three different circles. What this does is basically give you three high-concept circles to choose from, as listed above: people very close to you, people pretty darn close to you, and everyone else.
The everyone-needs-to-agree part makes neighborhoods extremely high-friction to join and makes them really special and scarce. If there are 300 Hometown servers, and the average neighborhood has 5 servers in it, then there are only about 60 neighborhoods between those servers. The number of neighborhoods will always be less than the number of servers. This will prevent any given neighborhood from ballooning and becoming, essentially, Fediverse 2. It means that neighborhoods will pretty much have to be grown with care, because there is such a high cost to growing them. People will take pride in their neighborhoods and also be jealous of other people's neighborhoods. When they aren't grown with care, they will socially fall to shit pretty fast. Neighborhoods will be difficult to manage, and large ones will be a pretty big feat of meta-moderation... just like in real life. It's why I like the metaphor.
This is all to say that I am building what I think is a socially useful feature that will be no easier than its irl counterpart. This is kind of the opposite of technological solutionism: I am say, no, I do not have clever answers and solutions. I think you need to do the hard work of building your community, and I am giving you a tool to do that hard work. But I'm not making it any "easier". I'm just making it possible for you to do it in a federated social media context.
As a technical aside, I do plan to publish neighborhoods as a specification, so that it's not just a Hometown feature. If some other federated social media software wants to join a Hometown neighborhood, they should be able to (if everyone agrees).
justjosias
marrus-sh
Pitch
I'd like to propose a concept of neighborhoods (name subject to change) that would add features that better-integrate cross-instance communities.
This would include federation privileges that are normally reserved for single instances, including:
I'm not sure what level of integration we'd want, but it's possible some instances would prefer to avoid yet another post visibility option and automatically integrate the instances as if they were one.
Adding new instances to a neighborhood can be done by consensus, as @dariusk mentioned, where each new instance added must be confirmed by every other instance in the neighborhood.
Motivation
Many instances are focused on a particular theme or geographic location. They may wish to federate more intimately with like-minded instances. This would make it easier for individuals to find others who share certain interests or tendencies.
For example, instances in a local area can all be a part of the same neighborhood in order to share information and recruit volunteers for ongoing community projects.
This can also encourage the starting of new instances, to avoid the fear of losing connection with old communities when launching new ones.