GNUsocial and the evolution of Federation
I’m not going to go into detail (yet) about what GNU social is. If you’re reading this without knowing and still want to understand what I’m saying here a bit, it’s basically a federated twitter. But better. What is important here is that by design, all or most nodes communicate with each other. A post made on one node is available on another if any users follow each other between the nodes. This kind of federation allows a great strength of the network. No one node breaks the network if it’s faulty or compromised. But it’s also raising some questions. I myself think there’s a few simple technological solutions here.
So as I get into the details here, let me point out something that should be obvious and obviously unavoidable. Those who wish to impose or operate under strict control will find a way to do so, for better or worse. The best option for such cases is to entice less strict control by allowing for control measures only minimally restrictive but meeting the needs of the user. I think we can do that with GNU social.
So before I explain my ideas I should explain the driving ideas behind them.
- The user should be the primary authority on their experience.
- Site admins and owners should take measures only to the degree that is necessary to guarantee the user their desired experience.
- Tools should be as simple as possible while allowing the greatest flexibility in their application.
On account of the federated nature of GNU social we have a largely untackled problem. How to administer a site where most of the ostensible users aren’t under the authority of the site system admin? Existing options boil down to muting individuals and blocking entire nodes. With only a few more options I believe that all realistic cases would be covered.
For the user, and as part of the default frontend, I recommend a single option. Call it “privacy mode” or similar. The user will see only content posted by people they follow and will automatically set the option “only show my updates to followers.” Additionally, remove the options to see all “public” and “whole network” views. If a user wishes to use the platform exclusively to communicate with friends, family, and associates, let them. Everybody else gets the full experience, with only specific users muted. I believe this would cover the vast majority of users and is very simple. Should users desire a more sophisticated option there’s always the option of creating a new front end.
For admins things are a bit more complicated by the fact that there are users on remote systems who can potentially post to the local system. Current options are limited to sandboxing and silencing, the latter of which as I understand it doesn’t do anything to remote users other than not display their content. Sandboxing is a good start and with some small expansions should meet most use cases. The goal here is to make it easy for admins to select only the degree of filtering needed, which tends to move into two types, open and closed networks. One use case, say for a family, would restrict connections to all but a few specific nodes and users; it would be a closed network. Occasionally a few new nodes or accounts could be added to expand the network. For most nodes a social network experience would involve restricting only a few specific nodes (for reasons we don’t need to go into here). They’d be open as they allow connections by default.
An “allow” and “deny” list with wildcards should do the trick. An example will be more useful here:
A closed network
Say a family wishes to set up a few nodes, johnsonfamily.com and johnsonfamily.org. The allow list contains “*@johnsonfamily.*” and allows connections to all users on all nodes named “johnsonfamily” with any URL ending. Should “johnsonfamily.net” show up, but be run by somebody else, the admins just add “johnsonfamily.net” to the deny list, and no more access to that node, but it would still allow “johnsonfamily.xyz” should it be an available node.
An open network
Alice runs a node at alicesocial.com and allows signups to anybody. She likes cats and advertises her node as a place to share cat pictures. A lot of her users also like dogs, and her friend Bob runs bobsocial.com with a focus on dogs. Charley likes reptiles and has charliesocial.com. Users on charliesocial.com follow users on Alice’s and Bob’s sites and keep sending them iguana pictures. So does user Izzy on bobsocial.com Alice adds “charliesocial.com” and “email@example.com” to her deny list and no longer is there any communication between alicesocial.com and charliesocial.com, nor any communication from izzy. However, Charlie feels bad about it and she wants to talk with him and only him over GNU social. So she adds “firstname.lastname@example.org” to the allow list. Now ONLY charlie’s posts make it through. Alice has chosen to allow him but will miss out on most of the context of what he’s saying.
With this kind of setup, admins can choose a generally closed or open setup, tailored to their needs. A script on a server can automatically add all followed users on remote instances to the allowed file, if the admin wishes, so that even if all hosts are denied, local users can still follow whomever they desire (but again without seeing a lot of context). These are simple tools that would allow admins to set up their site as they wish. They should be easy to implement and easy to understand. Communication will be allow between parties IF a user is on the allow list AND the user IS NOT on the unallowed list.
As a final note, I’m curious about how federation is accomplished with data sharing. Some nodes will store content locally, others rely on it to be available remotely. The advantage of the former is performance for the local users. However it may also lead to hosting undesirable or illegal content. As social networks grow exponentially there may also be a data volume issue, especially for nodes running on cheaper servers. In addition to the controls above, I would recommend making a similar finer-grained control for caching content, with lists to either explicitly cache or leave remote content by users. The “whole known network” could become very large with a lot of useless data sitting around. Allowing optional, specific caching would allow the network to scale better and for admins to keep federation intact without the need to worry about the implications of hosting foreign content.