Open justjosias opened 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.
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:
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).
I also should mention that Akkoma (a Pleroma fork) has a similar feature called "Bubbles" already implemented. They might be interested in the standardization of this feature.
@justjosias Great to know.
- Neighborhood-only post visibility
You would need to federate this in such a way as to fallback to followers‐only for instances which don’t support neighbourhoods. This might be the default behaviour if you just replace the “public” audience with some other neighbourhood audience, so this may actually be pretty easy. (Can’t we just ensure that only instances which support neighbourhoods are actually in them?? I·d·k, I don’t like making that assumption.)
The hard part is synchronizing across instances who is in a neighbourhood, especially when you consider that some instances may have other instances blocked, some instances may leave, instances may go down for a time, etc. The consequence is that if instance A doesn’t recognize instance C, but instance B does, instance B might boost instance A’s post somewhere users on A don’t expect. It’s easy to say “consensus” solves this, but on a federated platform my feeling is actually that consensus is not good enough because it is easy for messages to get lost, etc…
What I think would actually be the “best” solution from a protocol standpoint would be if the neighbourhood were a third‐party service which communicated with instances and kept track of who belongs to it, and offered a public group consisting of various instances’ shared inboxes which is used to signify “neighbourhood‐only” posting, and which can also work somewhat like a Mastodon relay to ensure posts sent there federate out to everybody involved.
This is still going to be complicated with respect to federation because, again, I don’t think one should trust or require instances to know themselves who is in a neighbourhood or not. So instead of federating posts out to the audiences themselves, as they would normally, they would be sending the post to the neighbourhood endpoint and trusting it to filter the audience so that only those people actually in the neighbourhood receive the post, and then forward the message accordingly. This means that neighbourhoods might be receiving a lot of traffic (if there is a lot of neighbourhood‐only posting going on) although they‘re not actually storing these posts hopefully.
And that’s potentially just the tip of the iceberg! Because a neighbourhood‐only post can’t actually be verified by another instance in the neighbourhood (because, again, what if it left the neighbourhood but that activity got lost during downtime), it would also need to trust the neighbourhood server to do that verification for it (essentially trusting that the neighbourhood saying “this post exists and is at this location” is as good as the server who actually controls that URL saying that). This has, uhhh, probably some security implications. That or, potentially, the server could ask the neighbourhood “hey do you contain this other server” every time a request is made, but that sounds expensive??
And of course the biggest downside to this approach is that it requires spinning up said third‐party service, maintaining it, etc. in addition to the costs of running an instance itself. But the alternative is never having a single source of truth regarding neighbourhood membership and also having no administrative contact to fix any issues which arise in federation (any problem would need to be solved individually by potentially every single instance admin in the neighbourhood), which I would consider very not ideal for something which is supposed to be as tightly‐integrated/trustworthy/accountable as this.
(Can’t we just ensure that only instances which support neighbourhoods are actually in them?? I·d·k, I don’t like making that assumption.)
With @dariusk's design concept, this would be a safe assumption.
Yes, it would only be possible for servers that support neighborhoods to join them.
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.