A Bloomberg terminal for Mastodon

As I mentioned last time, the Steampipe board for Mastodon has evolved in unexpected ways. I envisioned that the components, a plugin that maps Mastodon APIs to external Postgres tables, and a set of views that query the APIs, would combine to allow a broad overview of activity in the fediverse. That didn’t work for two reasons.

First, I learned that the Mastodon community did not appreciate the type of surveillance required for such an analysis. That was the original community, I must emphasize, and things have changed drastically, but I want to respect the original spirit. Lots of people, however, will crawl and index the fediverse, but I don’t need to put my shoulder on that wheel. And if you did, you’d be taking Steampipe out of its sweet spot: real-time acquisition, query, and visualization of API source data.

Second, the Mastodon API allows 300 requests every five minutes. You can use Steampipe in batch mode to get past that limit, and you can store data permanently in your Postgres database, but that’s cross-sectional with respect to Steampipe and Mastodon. All Mastodon clients are subject to the same API rate limit. If you’re using the web app or one of the phone apps, you’ve probably never seen a message saying that you’ve reached your limit and that you should wait a few minutes. I never saw that message until I started querying the API with Steampipe while using the web app.

So if Mastodon’s culture and technology resists deep data mining, and the system is optimized for clients living within an API budget of 300 requests every five minutes, what kind of Mastodon client could enable Steampipe? It would not be a conventional client because Steampipe is a read-only system. The way forward would be some kind of reader or browser that augments interactive applications.

The result, so far, is a set of panels showing tabular views (along with some graphs) of local, local, and federated timelines, my beep history and favorites, my followers and followers, my notifications , from searches for terms, people and hashtags, and from the timelines formed by the lists to which I have assigned the people I follow. These are all the HTML tables presented by the Steampipe control panel server. All columns can be sorted and table cells can only contain links or plain text.

Since the login content returned by the Mastodon API is HTML, the plain text-only restriction was initially felt like a blocker. No images? No links in toot content? How good is that?

However, some restrictions are worth accepting, and that may prove true here. Views created this way put a lot of information on the screen. Here is my default view in the stock client.

At a glance, I can see three items on the start timeline, and if I want to scroll through 100 items, I can only do so clumsily in small gulps.

Here is the timeline of my house on the Steampipe dashboard. I can see a dozen items at a glance and can easily scan 100 items in gulps that size.

When I described this effect to Greg Wilson, he gave me the title of this post: “That sounds like Bloomberg’s terminal for Mastodon.” I’ve never used one, and I’m aware that its design is often derided as a UX disaster, but as I understand it, the product is designed to allow merchants to scan fast-moving data feeds from many different sources. In that sense I think it is an interesting and useful comparison.

Also Read: Mastodon relationship graphs | InfoWorld

The underlying principle is one I learned from Edward Tufte: present information with maximum density. Our brains are designed to take in a lot of information at a glance, and if it’s well organized, we can do this very effectively. I feel like that’s happening to me when I scan these densely packed views of Mastodon activity.

To enhance the effect, I have started applying filters. In a Mastodon timeline, for example, a talkative person can dominate what you see at a glance. When we participate in social networks, we are always making offers for the attention of others. As feed publishers, it’s wise to consider how a flurry of items can overwhelm a reader’s experience. But it’s also useful to consider the ways that feed readers might filter out a chatty source. Steampipe’s SQL database offers an easy and natural way to do this. This is part of the query that drives the list view.

select distinct on (list, user_name, person, hour) -- only one per list/user/hour
  person,
  url,
  hour,
  toot
from
  data
order by
  hour desc, list, person

It was easy to implement a rule that limits each person to a maximum of one touch per hour. The next steps here will be to apply this rule to other views, show the number of collapsed toots, and enable said rules per person.

There are always links to the Mastodon web app, and I follow them when I want to see images, boost someone, or reply to someone. Dashboards help me quickly scan a lot of Mastodon activity and decide which elements I want to interact with. Your 500 character toot is all you have to get my attention, and I’ll just see it as a piece of plain plain text. That’s a pretty severe restriction, and not everyone will want to accept it, but it’s working pretty well for me so far.

I expect our panel system to support formatted text and images in HTML table cells. When it does, I’d like it to be an option that you can toggle on or off in Mastodon’s control panels. What should be the default value? I suspect I’ll want plain text and no images, especially if image captions can appear alongside the toots text. Some of Mastodon’s original cultural norms don’t survive the onslaught of new people, but writing image descriptions has stuck to this day, and it’s a wonderful thing. So write a short, thoughtful post, write a caption for your image if you include one, and if you catch my eye, I’ll click to view and interact.