Networks Of Trust: Dismantling And Preventing Harassment

Purism’s David Seaward recently posted an article titled Curbing Harassment with User Empowerment. In it, they posit that “user empowerment” is the best way to handle harassment. Yet, many of their suggestions do nothing to prevent or stop harassment. Instead they only provide ways to allow a user to plug their ears as it occurs.

Trusting The Operator

David Seaward writes with the assumption that the operator is always untrustworthy. But, what if the operator was someone you knew? Someone you could reach out to if there were any issues, who could reach out to other operators? This is the case on the Fediverse, where Purism’s Librem Social operates. Within this system of federated networks, each node is run by a person or group of people. These people receive reports in various forms. In order to continue to be trusted, moderators of servers are expected to handle reports of spam, hate speech, or other instances of negative interactions from other services. Since the network is distributed, this tends to be sustainable.

In practice, this means that as a moderator my users can send me things they’re concerned by, and I can send messages to the moderators of other servers if something on their server concerns me or one of my users. If the operator of the other node breaches trust (e.g. not responding, expressing support for bad actors) then I can choose to defederate from them. If I as a user find that my admin does not take action, I can move to a node that will take action. The end result is that there are multiple layers of trust:

  • I can trust my admins to take action
  • My admins can trust other admins to take action

This creates a system where, without lock-in, admins are incentivized to respond to things in good faith and in the best interests of their users.

User Empowerment And Active Admins

The system of trust above does not conflict with Purism’s goal of user empowerment. In fact, these two systems need to work together. Providing users tools to avoid harassment works in the short term, but admins need to take action to prevent harassment in the long term. There’s a very popular saying: with great power comes great responsibility. When you are an admin, you have both the power and responsibility to prevent harassment.

To continue using the fediverse for this discussion, there are two ways harassment occurs in a federated system:

  1. A user on a remote instance harasses people
  2. A user on the local instance harasses people

When harassment occurs, it comes in various forms like harassing speech, avoiding blocks, or sealioning. In all cases and forms, the local admin is expected to listen to reports and handle them accoridngly. For local users, this can mean a stern warning or a ban. For remote users, the form of response could range from contacting the remote admin to blocking that instance. Some fediverse software also supports blocking individual remote accounts. Each action helps prevent the harasser from further harming people on your instance or other instances.

Crowdsourcing Does Not Solve Harassment

One solution David proposes in the article is crowdsourced tagging. Earlier in the article he mentions that operators can be untrustworthy, but trusting everyone to tag things does not solve this. In fact, this can contribute to dogpiling and censorship. Let’s use an example to illustrate the issue. A trans woman posts about her experience with transphobia, and how transphobic people have harmed her. Her harassers can see this post, and tag it with “#hatespeech”. They tell their friends to do it too, or use bots. This now means anyone who filters “#hatespeech” would have her post hidden – even people that would have supported her. Apply this for other things and crowdsourced tagging can easily become a powerful tool to censor the speech of marginalized people.

Overall, I’d say Purism needs to take a step back and review their stance to moderation and anti-harassment. It would do them well if they also took a minute to have conversations with the experts they cite.

The Paradox of Tolerance In Online Spaces

Author’s Note: I have never felt uncomfortable contributing to GNOME. This is a more general post about online communities, and targeted at some of the other FOSS communities I’ve been interested in contributing to or have contributed to in the past.

In certain online spaces, the idea that not including people who are intolerant of others is itself a form of negative intolerance has gained traction. This would be excluding those who post white supremacist content, misogyny, homophobia, transphobia, etc. A common argument against excluding these people is the “slippery slope” – if you exclude these people for hate speech, soon you’ll try to exclude any people for anything.

In reality, this slope does not exist. In healthy online communities, these people are kept out and the community continues to move forward. How? Well, it’s because these communities could not be healthy and safe without the exclusion of harmful elements. This is where we hit the paradox of tolerance.

What Is The Paradox of Tolerance?

…if a society is tolerant without limit, its ability to be tolerant is eventually seized or destroyed by the intolerant.

In online spaces, “tolerance” refers to who you allow in the community. To be tolerant means to allow people from all walks of life into your space, regardless of race, sexual or gender identity, or other factors used to marginalize people within society. To go further, a good community should do more than tolerate them, but let them know that they are welcome and that they will not be marginalized within the community.

A person is marginalized when they are abused for their identity, or made to feel less important because of it. In real life, this manifests as workforce discrimination, housing discrimination, police brutality, and many other forms of oppression that make it so that the value of a victim’s life and livelihood are less important than the oppressor’s. In an online space, marginalization is more subtle. It would be if a black person saw someone use the “n word” – or worse, is called one – without reprucussion. It would be if a trans woman had to deal with someone saying that they are “men trying to invade women’s spaces”. It would be if a woman in general had to deal with men making sexual remarks and unwanted advances. These things all make the victims uncomfortable, and the lack of action taken can make them feel unimportant.

Some communities like to think of themselves as “perfectly tolerant”. This means that they would tolerate people that take actions to make marginalized people uncomfortable. When a community does this, they are actually being intolerant, and enabling abusers.

Isn’t It Intolerance To Keep Out The Intolerant?

Yes. In a very literal sense, it is intolerance to keep these people out of communities. However, the effect of this intolerance is that people who face real intolerance in their day-to-day lives feel safer in those communities. So it comes down to what you think is important. Do you think it’s more important to let people abuse others, or to have a safe and productive community? If you want to run a community, you have to make that choice.

What is a Platform?

Often when looking for apps on Linux, one might search for something “cross-platform”. What does that mean? Typically it refers to running on more than one operating system, e.g. Windows, macOS, and GNU/Linux. But, what are developers really targeting when they target GNU/Linux, since there’s such diverse ecosystem of environments with their own behaviors? Is there really a “Linux Desktop” platform at all?

The Prerequisites

When developing an app for one platform, there are certain elements you can assume are there and able to be relied on. This can be low-level things like the standard library, or user-facing things like the system tray. On Windows you can expect the Windows API or Win32, and on macOS you can expect Cocoa. With GNU/Linux, the only constants are the GNU userspace and the Linux kernel. You can’t assume systemd, GLib, Qt, or any of the other common elements will be there for every system.

What about freedesktop? Even then, not every desktop follows all of the specifications within freedesktop, such as the Secrets API or the system tray. So making assumptions based on targeting freedesktop as a platform will not work out.

To be a true platform, the ability to rely on elements being stable for all users is a must. By this definition, the “Linux Desktop” itself is not a platform, as it does not meet the criteria.

Making Platforms Out of “The Linux Desktop”

It is possible to build fully realized platforms on top of GNU/Linux. The best example of this is elementary OS. Developers targeting elementary OS know that different elements like Granite will be present for all users of elementary OS. They also know elements that won’t be there, such as custom themes or a system tray. Thus, they can make decisions and integrate things with platform specifics in mind. This ability leads to polished, well-integrated apps on the AppCenter and developers need not fear a distro breaking their app.

To get a healthy app development community for GNOME, we need to be able to have the same guarantees. Unfortunately, we don’t have that. Because GNOME is not shipped by upstream, downstreams take the base of GNOME we target and remove or change core elements. This can be the system stylesheet or something even more functional, like Tracker (our file indexer). By doing this, the versions of GNOME that reach users break the functionality or UX in our apps. Nobody can target GNOME if every instance of it can be massively different from another. Just as no one can truly target the “Linux Desktop” due to the differences in each environment.

How do we solve this, then? To start, the community idea of the “Linux Desktop” as a platform needs to be moved past. Once it’s understood that each desktop is target that developers aim for, it will be easier for users to find what apps work best for their environment. That said, we need to have apps for them to find. Improving the development experience for various platforms will help developers in making well-integrated apps. Making sure they can safely make assumptions is fundamental, and I hope that we get there.

Developing GNOME: The Basics

I’ve been working in the GNOME community for a little under a year and a half now. During my time contributing to the project, I’ve seen a lot of misunderstandings from the community about how we work. So, I’ve decided to write a multi-part series on how development on GNOME works.

This first post will cover the basics. In future I’ll explain our tooling, how apps are created, and how changes happen across the ecosystem.

The Release Cycle

At the center of GNOME development is the release cycle. Every 6 months we put out a major release, with patch releases in-between. Major releases typically happen in September and March, and are named after the city of the most recent conference. GNOME 3.30 was named after the city we held GUADEC in, and 3.32 is named after where GNOME.Asia took place.

At different intervals in the cycle we have freeze periods, after which no changes can be made to certain parts of the code. Core apps, such as Web, Files, and Settings all strictly follow the release cycle and freezes. Apps outside of the core set like Polari, Builder, and Fractal can follow their own schedules or versioning schemes, but tend to put out releases alongside the GNOME core.

The freeze deadlines often determine what contributions make it into a release. For example, if a UI change is submitted after the UI freeze, maintainers need to seek approval from the Design and Release teams before the change can be merged. Freezes are staggered, and come in the following order:

  • UI, Feature, and API/ABI Freezes
  • String Freeze
  • Hard Code Freeze

The hard code freeze ends once the major release for the cycle is out. If you want to apply a change that violates the other freezes, you need to create a branch for the latest stable release. So, if I need to merge a UI change after the 3.32 release is out, I need to first create a gnome-3-32 branch before I accept the change onto master. This branch will then be used to cherry-pick changes for the 3.32.X releases.

How Apps Are Maintained

Each project within GNOME has its own developers. The Music developers aren’t necessarily the same people working on the Shell, and the Shell developers generally aren’t the same people working on GTK. While many developers work across the ecosystem on different projects, there is no one team of developers. This is why “GNOME decided such and such” is often inaccurate.

The maintainers of a project have full say over what contributions are or are not accepted. While certain things can be proposed, maintainers have the right to reject proposals. This is, for example, is why Terminal did not have a HeaderBar until 3.32 and doesn’t enable it by default. Nobody is forced to do anything, but often developers and designers will agree on a direction for an app, or the ecosystem at large.

Contrary to popular belief, most maintainers are not paid by Red Hat although some core components like Files and GNOME Shell do have Red Hat employees employed to work on them. Other companies such as Canonical, Purism, and Endless employ developers to work on the parts of the stack that matter to them. That said, most contributors are not on company time even if they are employed by the likes of Red Hat. And of course those that are employed to work on GNOME still aren’t paid for all of their work on GNOME. Most of our work is done on our own time, as limited by the rest of our lives.

It’s also worth noting that GNOME is built with a wide range of technologies; while GTK is written exclusively in C, Music is a Python project and Calculator is implemented with Vala. The Python developers working on Music are great with Python and GStreamer, but they aren’t going to be much help fixing a rounding error in Calculator as a general rule, and as volunteers it wouldn’t be fair to expect them to be, either.

tl;dr: GNOME is a community of individuals each with their own motivations and vision for their own part of the project doing their best to build a great platform for users.

Announcing my Contract with Purism for an Adaptive Fractal UI

Over the past year or so I have been a regular contributor to Fractal, a Matrix chat client for GNOME. My contributions have allowed me to take on a bigger role in the GNOME community, including the maintainership of a few apps. I am pleased to announce that over the next week I will be working to make Fractal’s UI adaptive for the Librem 5’s launch. This contract began last week, and I already have some results to show off.

The Main View

Fractal has used a split window pattern since it’s inception. With HdyLeaflet apps that use this pattern can adapt their size to fit different widths. Once !363 is merged, Fractal will use HdyLeaflet to adapt it’s main view.

The Dialogs

In combination with HdyLeaflet, HdyDialog allows us to have dialogs that grow to the full size of the window at smaller sizes. I changed most of the instances of GtkDialog into HdyDialog and made sure each one would fit into the Librem 5’s constraints.

The Room Details

The room details view was something started a long while ago by Julian Sparber, made before HdyColumn was a thing. HdyColumn allows widgets to expand up to a certain width, while still being able to size appropriately on smaller screens.

Login

Our on-boarding process is in need of a redesign in general, so while redesigning it we can design for mobile as well.

Mapping Clicks To Touches

Currently we have a context menu that is accessed by right clicking on a message. This will need to work for long press on the phone, since there’s no way to right click on a touchscreen.

The Image Viewer

The controls of the Image Viewer’s headerbar are too large for it to shrink to the Librem 5’s constraints. We’ll need to make sure these controls are re-arranged in order to allow the viewer to fit correctly.

The Room Directory

The room directory is another view with controls that will need to adapt to small sizes. It has a searchbar, a back button, the items in the list don’t shrink enough for the rest of the window.

Overall, I’m very excited that Purism accepted my proposal and that I get to work on this. I have been looking forward to the day where I can run Fractal on my phone, and I’m glad to be bringing that closer.