Personal ramblings about diaspora*, my work on it, and mistakes I made
Diaspora* has always been a project that cares about all its users, not about the people working on it. Our project discussions and decisions do not happen inside GitHub issues but instead are made on our Discourse instance. We not only welcome everyone there, we actively invite non-technical users of diaspora* to join our discussions, because we always get valuable insight from opinions outside our bubble.
Quite often, we make our decisions not based on the question of “what is easy to implement?” but rather on “what makes the most sense to our users?”. This, sometimes, puts us in a spot where we cannot have things we want because they make no sense for non-technical people, and sometimes, we have to do extra work just to polish an idea before it can be shipped.
I think this paid off. Even though there are a lot of options to choose from when it comes to federated social networking, diaspora* is still very solid, even after all these years. Because of how we approach problems, we have a fairly nice mix of people inside our network. We have our fair share of tech folks, but there are a lot of non-technical people on diaspora* as well, and that is one of the reasons why I like it so much. Diaspora* unites people with a shared interest about privacy, not people with the same level of technical knowledge.
The bad side
Unfortunately, with a broad mix of people, there is no way to avoid the occasional jerk. Diaspora*, like every other place in the history of the internet, has its own share of neo-nazis, antisemites, misogynists, and pretty much everything else you usually do not want to deal with.
As a project, we maintain network-wide community guidelines as well as a Code of Conduct that applies to all our communication channels within the project. And while I think the project is doing fine, I cannot comfortably say the same about the network as a whole.
Due to its federated nature, there is no central instance, and there is no place where we, as a project, could actually enforce our rules in any meaningful way. The software running a diaspora* pod is free and open-source software, available to anyone. Some people run nodes where the rules are more strict than what we enforce within the project, but obviously, other people run nodes where they do not care at all.
This is an issue, but the nature of diaspora* makes this a tough problem to solve.
In recent time, diaspora* has been in maintenance mode, where we used a lot of time to clean up old design mistakes, make the application and federation run more reliable, spend time reimplementing essential bits and pieces to reach a state that is easier to maintain, … you get the idea. While there have not been significant changes in how diaspora* looks and feels, we made huge steps in improving our backend implementation and even managed to ship a couple of new features that have been requested for a while. Less than we wanted to, but any progress is good progress.
Everyone working on diaspora* has their own set of goals, and while there is consensus on what the core team feels like everyone should be working on, there is no central management to tell people what to do. This has been working fine for us, especially as everyone currently working on diaspora* is contributing completely voluntary in their free time. There is no point in making actual plans if you have no people who will reliably work on those, and I think that is just fine for a project like diaspora*.
Plans for the future
Personally, I have two broad goals I want to achieve within the project at the moment. After moving the project from Loomio to Discourse a while back, we have all our infrastructure in our own hands, but our current documentation and our website are a bit lackluster, both in terms of contents, and in terms of maintenance. Since I am responsible for keeping the project’s infrastructure alive, I feel the pain of having a MediaWiki, a website, and a bunch of hacks around, so I decided I wanted to bring all those things together.
Since I love automating things and diaspora* lacks a proper API, I wanted to work on that as well. A team of contributors has made some impressive progress here, but it needs more work to be ready for production. Funny enough, the API was one of the things we announced in our very first blog post as a community project back in 2013. And that is about how long this task is in my mind.
As you can see, I am excellent at finishing things.
Even though I have plans for what I should be doing, and I always felt comfortable that these were the right things to do, I am having a hard time motivating myself to actually doing it. Some people may say I am lazy, and while that is absolutely true, I do not think this is the cause for me not working on diaspora* as much as I would like to do.
In 2018, I almost stopped working on the project for good. I was going through a bit of a rough time personally, and some folks formally active inside the diaspora* project made the whole project an unwelcoming environment to work in. I felt like I was wasting my time in discussions because the people I was discussing with had their opinions made up as soon as they saw my nickname. I decided to take a break from the project, and that was a truly fantastic idea.
When I came back, I wanted to continue the tasks I started. However, something felt off. I was unable to describe what was wrong, so I ignored it and just kept working on the relaunch of our project’s website and all the documentation.
Early 2019, we decided to hold a little diaspora* hackathon in Berlin, where a couple of the active diaspora* contributors were invited to join and hack together on some things that were on our plates for a long time. I made some significant progress on the website there, and other folks made considerable progress on their ideas as well. Overall, while we achieved less than I had hoped for, but we had a good time.
But I still felt like something was weird. I was unable to focus on the things I wanted to focus on entirely.
This state of “not quite feeling it” continued for quite some time. In fact, I just now realized what was wrong all along.
Over the last couple of years, I drastically changed the way I use diaspora*. While previously, I was okay with using it as my primary platform to share pretty much anything and maintain contact with friends, I stopped doing that. The jerks I mentioned earlier made my diaspora* stream an occasionally very uncomfortable place to be in, as I was unable to go on a content discovery tour or even post publicly without being confronted with someone who knows how to live my life better than I do, or to see some nazi bullshit some people post using hashtags I care about. In addition, diaspora* is, if you have an old database with lots of posts in it, really slow. Loading the general stream/timeline can take 15 seconds or more if you are unlucky, and if I am on a mobile device in need of some funny cat pictures, Twitter is better at satisfying that urge.
Diaspora* lacks good options to filter the contents you are exposed to. While we have a basic “ignore” feature that also blocks people from commenting on your posts, there are many instances where you will see interactions and contents from people you have blocked. There are absolutely no mechanisms for people to customize their own experience above what we implemented a long time ago, and that is not much. There is no switch to hide your profile by default; there is no switch that only allows whitelisted people to interact with your posts, … basically, diaspora* lacks a lot of really important things.
We have known about these requirements for a long time, because many users frequently complain about missing them. I am aware of several groups inside of diaspora* caring for themselves by warning each other whenever there is a new account from one of the known abusers. Not because they want to attack those accounts, but rather because they have no better way of protecting themselves. As a project team, we even agree that these “features” are essential, and should be essential in any social network, but we did not implement them. We did not implement them, because our current performance was already horrible enough, and adding more content filters would only make things worse.
This area, abuse prevention, is one of the few areas where we considered our technology more critical than our users.
I am no stranger to criticizing others for making bad decisions. Just recently, I commented on Twitter wanting to work on decentralized networks with
[…] decentralization is a quick and easy escape for when you don’t care about hate speech and harassment and are looking for a new excuse to care even less.
And I truly meant that. No project, regardless of its size and technologies, should get away with sacrificing users’ ability to protect themselves online. Doing so is stupid, and hiding that obvious issue behind “we cannot work on that, our tech stack does not allow us to do so” is incredibly lazy. Every tech stack can be adopted if you deem these changes important enough.
So, here I am, finding myself in a position where I criticize others for the same things I do. And here I am, suddenly realizing what made my motivation to work on diaspora* suddenly vanish: diaspora* no longer felt like a safe place to me. It felt like something I actively have to put care into whenever I post something, just to not touch any of those ugly corners by accident.
My behavior probably would be fine if I were just a random diaspora* user or an occasional contributor. But I am not. Quite some time ago, the project pushed me into a de-facto project management role because I was the one who stood up when the project needed it. And I was quite happy to take over that role.
This role is not a joke. There is responsibility attached to it. I get a lot of praise when things occasionally do go right, and that is a really pleasurable experience. However, having this role also means that I have to be the one putting myself out there in case things do go wrong. I cannot take all the praise while delegating all the blame to someone else. Life does not work that way. I am responsible for the things I do, but I am also responsible for the things I did not do, and for the consequences those decisions had.
Even if I cannot implement those things myself, I should, at least, have made sure that those issues are high on the lists of priorities of all the project members. Attempting to ignore the problems until they go away is not a good option.
I goofed up, and I am sorry about that.
If I am frank, I still do not quite have a plan for what to do next.
I no longer feel like the project site relaunch is top-priority, and I also do not feel like the API is worth my attention right now. I cannot work on implementing proper blocking mechanisms right now, simply because adding anything would result in all larger pods becoming completely unusable. We need to find a way to increase our server-side performance first, or otherwise, this would be the inevitable death of a project. The good news is that I already started exploring some ideas into bringing diaspora* up to speed, and we will see where those things end up.
Maybe this will help a bit. Maybe not. Maybe, we will figure out diaspora* is the wrong approach entirely, and we should focus on something different instead. I simply do not know the answers to all the questions yet. But it looks like this year’s result is either succeeding at bringing diaspora* to a point where I am happy with it again, or deciding that I am not up for that task, and take appropriate consequences. We will know at the end of 2020, I guess.