Visualizing Mastodon server moderation | InfoWorld

In Mapping the Wider Fediverse, I showed how a new table was added to the Mastodon plugin:mastodon_domain_block: allows queries that find which servers are moderating which other servers. For example, here are servers on the nerdculture.de offender list.

select
  server,
  domain,
  severity
from
  mastodon_domain_block
where
  server="https://nerdculture.de"

+------------------------+--------------------------------+----------+
| server                 | domain                         | severity |
+------------------------+--------------------------------+----------+
| https://nerdculture.de | roysbeer.place                 | silence  |
| https://nerdculture.de | *.10minutepleroma.com          | suspend  |
| https://nerdculture.de | *.activitypub-troll.cf         | suspend  |

...snip...

| https://nerdculture.de | shitposter.club                | suspend  |
| https://nerdculture.de | wolfgirl.bar                   | suspend  |
| https://nerdculture.de | www2.gabbers.me                | suspend  |
+------------------------+--------------------------------+----------+

I used the new query pattern to create a dashboard to report on, for each server in the home timeline:

The list of blocking servers.
the count of blocked servers for each lock server.
The blocking server list for each blocked server and the count of those blocking servers.

This was a good start, but I had a feeling the relationship graphs would reveal non-obvious connections between these servers. And indeed they do! This is a view of the new chart-enriched dashboard.

The left panel shows the blocked servers rejected by a lock server selected from those on the start timeline. The right panel has the reverse view: the blocking servers who shy away from a selected server crashed. These were the two categories I defined for the first iteration of these charts.

category "blocking_server" {
  color = "darkgreen"
  icon = "server"
}

category "blocked_server" {
  color = "darkred"
  icon = "server"
}

Here is the code for one of the charts.

graph {
   node {
    base = node.blocking_server
  }
   node {
    base = node.blocked_server
  }
   node {
    base = node.blocked_and_blocking_server
  }
   edge {
    args = [ self.input.blocking_server.value ]
    base = edge.match_blocked_server
  }
   edge {
    args = [ self.input.blocking_server.value ]
    base = edge.match_blocking_server
  }
}

Here is the definition of node.blocking_serverWhich refers to category.blocking_server.

node "blocking_server" {
  category = category.blocking_server
  sql = <<EOQ
    with servers as (
      select distinct
        blocking_server,
        blocked_server
      from
        blocking_servers(${local.limit})
    )
    select
      blocking_server as id,
      blocking_server as title
    from
      servers
    order by
      blocking_server
  EOQ
}

The FROM clause calls blocking_servers()a set return function defined like this:

create or replace function public.blocking_servers(max int) returns table (
  blocking_server text,
  blocked_server text
) as $$
with servers as (
  select distinct
    server as domain,
    'https://' || server as server_url
  from
    mastodon_toot
  where
    timeline="home"
  limit max
),
blocking_and_blocked as (
  select
    s.domain as blocking_domain,
    d.domain as blocked_domain
  from
    servers s
  join
    mastodon_domain_block d
  on
    s.server_url = d.server
)
select
  blocking_domain,
  blocked_domain
from
  blocking_and_blocked
order by
  blocking_domain, blocked_domain
$$ language sql

I thought these ingredients would be enough. But when I started poking around in the graphs made with these definitions, infosec.exchange he behaved strangely. Sometimes it appeared as a lock serverother times like server crashed. I was missing a category!

Also Read: Repatriating cloud apps and data? Think it through

category "blocked_and_blocking_server" {
  color = "orange"
  icon = "server"
}

As can be seen in the graph, infosec.exchange not only blocks 73 servers, it is also blocked by two servers: religion.masto.host and time.net. Because?

calls weatherishappening.net infosec.exchange a “BULLY DEATH SPIRAL FASCIST ORGANIZATION” and blocks it with a “Limited” severity.

religion.masto.host blocks infosec.exchange at the “Suspended” level, but does not explain why (“Reason not available”).

Although those servers could, in turn, be blocked by others, such blocks do not appear on the block lists for my immediate server neighborhood.

> select count(*) from blocking_servers(100) where blocked_server="weatherishappening.net"
+-------+
| count |
+-------+
| 0     |
+-------+

> select count(*) from blocking_servers(100) where blocked_server="religion.masto.host"
+-------+
| count |
+-------+
| 0     |
+-------+

However, there is another switch hitter in my neighborhood. c.im is blocked by me.dm and octodon.social.

Because?

i.dm (Medium) has “suspended” c.im for “hate speech”.

octodon.social has suspended” c.im for “Reason not available”.

When your server’s opinions and policies differ from mine, we see different realities through our respective lenses. Could such fragmentation drive curious fediverses into the arms of Big Social? I’m sure that will happen, in fact it is happening, to some extent.

But I hope that some of us, at least, learn to thrive in diverse networks of online communities, aware of the kaleidoscopic interplay of filters but not overwhelmed by it. That ability will serve us well in real life as well. To acquire it, we will need to visualize the operation of our filters. A great way to do this: SQL queries that generate graphs of relationships.