Mapping the wider fediverse | InfoWorld

I started this journey convinced that Steampipe could help fediverses evolve, but I wasn’t sure how exactly. My first thought was to use Steampipe’s API dispute superpower to study patterns of communication (and conflict) across the fediverse. But as one of the many fugitives from Twitter last November, I soon realized that the network I was joining reflected a culture that had worked very well for six years and did not want to be the subject of sociological study.

As I discussed in Range, Packet Size, Friction, Fanout, and Speed, Mastodon incorporates certain types of friction for reasons. You’ve likely heard of a lack of default search facility, which is both a technical environment and a cultural choice that privileges the current stream experience over past stream extraction. Even more fundamentally, the ID of a beep not only differs from server to server, but also obfuscates the date of the beep, another technical/cultural option that means you can’t randomly access history by date. None of these frictions is insurmountable. They will be defeated for good and bad purposes. I hope and hope that communities can choose the amounts and types of friction they want while still interoperating with others. But for my project it seemed that trying to survey the broader fediverse was not the right place to start.

So instead I began to explore a different way of reading my home timeline. The boards I’ve created and described in this series have become, at least for me, an effective way to scan Mastodon’s recent stream and then click into the stock client to post, reply, or boost. After getting over a few hurdles, things start to feel like the Bloomberg terminal for Mastodon I imagine.

One of those hurdles was the cumbersome copy/paste/lookup of foreign toot URLs required to interact with them. That is now surpassed with instance-qualified mastodon URLs. Another hurdle was the difficulty of effectively curating and reading subject lists of people. The strategies described in Lists and People in Mastodon and Working with Mastodon Lists have made things much better. And the relationship charts turned out to be a more useful alternate view of the current flow than I expected.

I think I’ve proven that a set of Steampipe boards, overlaid on a plugin that maps the Mastodon API to the tables that the boards query, can improve Mastodon’s ability to absorb and react to flow. An untested corollary: Steampipe’s boards-as-code system is just one of many potential customers for the Mastodon plugin. Any dashboard system, web app, or native app could take advantage of the same query capability to offer another way to experience the flow. But that’s a future episode.

In the meantime, with a decent reading experience in place, this seemed like a good time to get back to the question of polling the broader fediverses. To start enabling that, I added a couple of new tables to the plugin: mastodon_peer and mastodon_domain_block.

Here is a query that uses mastodon_peer.

with data as (
  select
    'https://' || server as server
  from
    mastodon_toot
  where
    timeline="home"
  limit 100
),
servers as (
  select
    server,
    count(*) as occurrences
  from
    data
  group by
    server
)
select
  s.server,
  s.occurrences,
  count(p.peer) as peers
from
  servers s
join
  mastodon_peer p
on
  s.server = p.server
group by
  s.server,
  s.occurrences
order by
  peers desc

In English: Collect the most recent 100 toots on my home timeline, count the occurrences of each origin server, then ask each origin server how many other servers it communicates with. As expected, my home server, mastodon.social, occurs more frequently. And because it is the marquee Mastodon server, it has the most peers.

Also Read: Databricks launches lakehouse for manufacturing sector

+----------------------------------+-------------+-------+
| server                           | occurrences | peers |
+----------------------------------+-------------+-------+
| https://mastodon.social          | 11          | 49732 |
| https://fosstodon.org            | 1           | 33973 |
| https://octodon.social           | 1           | 29983 |
| https://infosec.exchange         | 2           | 26833 |
| https://indieweb.social          | 9           | 26279 |
| https://hachyderm.io             | 3           | 19911 |
| https://social.treehouse.systems | 3           | 18110 |
| https://journa.host              | 1           | 18021 |
| https://nerdculture.de           | 9           | 17984 |
| https://werd.social              | 2           | 13792 |
| https://dan.mastohon.com         | 2           | 13351 |
| https://masto.nyc                | 1           | 10917 |
| https://mastodon.archive.org     | 1           | 9582  |
| https://social.fossdle.org       | 1           | 8343  |
| https://devdilettante.com        | 12          | 6898  |
+----------------------------------+-------------+-------+

Here is a query that uses mastodon_domain_block.

with data as (
  select
    'https://' || server as server
  from
    mastodon_toot
  where
    timeline="home"
  limit 100
),
servers as (
  select
    server,
    count(*) as occurrences
  from
    data
  group by
    server
)
select
  s.server,
  s.occurrences,
  count(d.domain) as "blocked domains"
from
  servers s
join
  mastodon_domain_block d
on
  s.server = d.server
group by
  s.server,
  s.occurrences
order by
  "blocked domains" desc

This one says: Once again, round up the origin servers in my recent startup timeline, but this time ask each how many other servers it blocks. Here we see that octodon.socialwhich appeared on my timeline when I ran the query, it blocks a lot more servers than mastodon.social does.

+--------------------------+-------------+-----------------+
| server                   | occurrences | blocked domains |
+--------------------------+-------------+-----------------+
| https://octodon.social   | 1           | 510             |
| https://mastodon.social  | 8           | 181             |
| https://hachyderm.io     | 4           | 125             |
| https://infosec.exchange | 4           | 66              |
| https://nerdculture.de   | 1           | 36              |
| https://indieweb.social  | 4           | 23              |
+--------------------------+-------------+-----------------+

One could, and perhaps at some point will, comprehensively acquire and store this data. But in the meantime, how could the experience of reading Mastodon’s recent stream be improved? This is what I have so far.

We’ve already seen the first table that answers the question: “How many servers are blocked by each of the origin servers in my timeline?” The second table answers a different question: “Which servers are most often blocked by the origin servers in my timeline?”

He list of blocked servers column shows an interesting combination of consensus and variation, and I think it will be something to explore extensively on fediverse. But for now I like how this view contextualizes what’s on my home timeline. Like relationship graphs, it is very dynamic because my immediate network environment changes all the time. However, whatever the current set of servers is, I now have some clues as to how connected each of those servers is, and how aggressively each is blocking the others. This feels like a good first step in mapping the broader fediverse.