Mastodon is less discoverable than Twitter, particularly because it doesn’t have full-text search, and because it has multiple instances. How do we know what’s going on, or which instances are particularly active?
There is a webpage of instance data somewhere. That is a good starting point.
But what about propagation of individual posts? How do they get seen, how quickly do other instances pick them up, which other instances? Here I summarise a quick experiment that exploits a feaure of mastodon software’s behaviour to map out some details of how a post is seen by other instances.
It appears that as soon as Mastodon instances see a post containing an (as yet unseen) URL, they pre-fetch it. This has been causing a certain amount of controversy over the past few days as website owners have seen unexpected bursts of traffic.
My small experiment: I a sent out test post from my account on mastodon.social, every 3 hours over 18 hours, each time with a fresh URL, and watched my web-logs. What did I learn:
- Yes, there is an immediate flurry of GET requests
- Of the order of 60 instances respond to any one post
- 54 instances respond to every post
- No instance responds twice to the same URL
- If someone from another instance responds to the post (hi, @reliablyjeff) all bets are off
- Some instances are very slow to respond: possibly because it is the originating host, mastodon.social responds within a minute to the first post, but takes several hours for the rest
Excluding the two waves where there people responded to the test posts, and mastodon.social, mean delay is 151 seconds, median 34.
Apart from mastodon.social, there are a few instances (mastodon.sdf.org, mstdn.ca, nonexiste.net) that sometimes take more than an hour to respond.
When people reply to a post, there is a new flurry of GET requests. These are presumably from instances that are checking out the replier’s instance, but not mastodon.social. I had one reply from mastodon.online, which triggered requests from the following list of instances:
- mastodon.coffee
- amastodon.uk
- post.lurk.org
- jamesgallagher.social
- mastodon.gamedev.place
The reply from sciences.social provoked more requests (either it is a lot better connected than mastodon.online or its network overlaps with mastodon.social’s a lot less than mastodon.online’s does; my bet is more the former than the latter):
mastodon-belgium.be, sigmoid.social, social.tchncs.de, historians.social, social.anoxinon.de, digitalcourage.social, saturation.social, social.bigger6.com, bhre.social, mastodon.nz, social.kiesow.net, h-net.social, freiburg.social, sfba.social, mstdn.dk, m.cmx.im, zirk.us, awscommunity.social, chaos.social, lile.cl, mastodon.lawprofs.org, ruhr.social, social.brimstor.me, libretooth.gr, todon.eu, lipn.info, mastodon.nl, mindly.social, edumasto.org, links.potsda.mn, union.place, mastodont.cat, det.social, data-folks.masto.host, writing.exchange, ravenation.club, federate.social, aleph.land, octodon.social, medibubble.org, mastodon.energy, hci.social, ursal.zone, mastodon.lol, ohai.social, twit.social, mastodon.com.py, masthead.social, glammr.us, m.sclo.nl, social.cologne, hcommons.social, uddannelse.social, norden.social, bildung.social, masto.es, sueden.social, towns.gay, fandom.ink
At the end of all this I feel I understand a little bit more about Mastodon networking and how posts might propagate. Nothing, perhaps, that couldn’t be inferred from a knowledge of how the software is written, but now from observing the behaviour I understand a little bit more about the software.
The one thing I haven’t yet done is check out the size of the instances: many of the requests, and perhaps disproportionately many of the “unique” requests, will be from very small instances. On the TODO list.