If you hit https://mastodon.social/api/v1/instance/peers you'll be confronted with about 75,000 different peers.

These are federations, past and present, but not blocks. If a site is blocked, it eventually drops off of the /peers endpoint.

As such, we can create a sort of rough "allowlist" for Mastodon.Social by doing a liveness check on those 75,000 different peers.

To speed things up, I cross-referenced against FediDB and the nascent "Fedilist" to check their domains against mastodon.social's, in order to essentially mark them as "up".

After that, I was left with 30k or so unknown domains that I needed to crawl to do a sort of liveness check. I basically used a bevvy of nodeinfo requests (1-3 per host), starting with .well-known and working my way up to nodeinfo2.0 (for those of you who know what this means) and if at least one of them responded, site is up, if not, down.

The output is effectively the mastodon.social "allowlist" of 21,874 things here and the much larger list of 53,138 "dead" instances, once federated, but now long gone here.

Just in case you find this interesting. If you federate with mastodon.social, you should find your server in the allowlist.

(Note that mastodon.social is in denylist mode, so it doesn't really have an allowlist.)

Essentially, if you were to set up a new single-user server in allowlist mode and add every one of the allowed domains in the above list to your federation, you could migrate from mastodon.social to your own allowlist server and lose no followers in the process, in either direction.

Not that I'm recommending that.

Note that this just represents "instances mastodon.social knows about that it's not also blocking." It doesn't mean anyone on either server is necessarily following or communicating with anyone.

An alternative is running this python script to build your own allowlist, based on your current followers (and who you follow).

Credit goes to @burnoutqueen for this one: https://gist.github.com/coderamen666/a9c045a73fe49e365fb54f4d856f72e6

You'll get a much more condensed allowlist, based on who you actually "engage" with, and then you can allowlist "up" from there.

Part of the problem with not being a part of the fediverse in any real way is that all your nodeinfo endpoints are blocked and you appear on my crawler as a dead site.

There's no .well-known for threads, there's no nodeinfo v1 or v2. There's no peers endpoint. There's no /v1/instance, there's no /v2/instance.

Anyway, that's how it decided to take itself off of the allowlist.

@oliphant there should be those for Threads.. even if they don't expose stats.

@thisismissem There should be, but it doesn't appear there's any such thing at the moment.

@oliphant how odd!

@thisismissem @oliphant to be fair none of these things are actually in ActivityPub

It wouldn't surprise me if e.g. Kroeg failed those tests too

@erincandescent @thisismissem Yeah, it's just an FEP and there are probably a lot of 'homegrown' things or stuff like honk (I hadn't even heard of Kroeg) that probably doesn't do this at all.

@oliphant @erincandescent @thisismissem NodeInfo afaik *requires* exposing stats, it was developed for that purpose. see http://nodeinfo.diaspora.software/ and especially https://github.com/jhass/nodeinfo/blob/main/schemas/2.2/schema.json

in any case, nodeinfo isn't required for federation and probably isn't an ideal "liveness check". but then again, there isn't really a better way that I can think of -- checking the root domain for a 2xx response might introduce false positives.