Supporting other platforms that offer Mastodon API compatibility

[bocops]

As mentioned in #225, it wouldn't be much work to enable some sort of detection of servers that offer a Mastodon API with different server software. For example, Pixelfed does, and it would be as easy as storing the whole software object returned by NodeInfo to be able to detect what server software we're dealing with, like so:

val server = NodeInfoClient.retrieveServerInfo(instanceName)
    server.software?.let { software ->
        when (software.name) {
            "mastodon" -> {
                // interpret software.version as a Mastodon version
             }
            "pixelfed" -> {
                // interpret software.version as a Pixelfed version
             }
            // other server software
        }
    }

It might be a bit early to do this already, but I think it is worth discussing right now, because it could also inform our decision how to deal with different versions of the Mastodon API. Right now, our idea is to grab the (Mastodon) software version, and then for each of the methods we implement compare that version string to some value stored in the method to see if the necessary endpoint would even be available and with what restrictions.

The problem with that, if we ever want to support other platforms, is that these platforms might come with wildly different versioning schemes - for example, Pixelfed 0.11.8 is implementing some of Mastodon's 4.0+ API (and a platform might not have the intention to ever implement all endpoints, if they aren't sensible for that platform).

Since we still need to implement the whole version logic anyway, we're in the best position to do it in a way that works well with other software. Instead of adding some min_version to every method we have, we could have a central JSON asset like this:

[
    {
        "software" : {
            "name" : "mastodon",
            "version" : "4.1.2"
        },
        "api_path_prefix" : "",
        "supported_endpoints" : [
            {
                "endpoint" : "/api/v1/statuses",
                "method" : "POST",
                "since_version" : "0.0.0"
            },
            {
                "endpoint" : "/api/v2/filters/:id",
                "method" : "GET",
                "since_version" : "4.0.0"
            }
        ]
    },
    {
        "software" : {
            "name" : "pixelfed",
            "version" : "0.11.8"
        },
        "api_path_prefix" : "",
        "supported_endpoints" : [
            {
                "endpoint" : "/api/v1/statuses",
                "method" : "POST",
                "since_version" : "0.4.2"
            }
        ]
    }
]

This JSON consists of a list of platform elements, each of which has a software (structured just like what NodeInfo already returns) and a supported_endpoints list that enumerates all available endpoints with a minimum version that supports it. Having api_path_prefix would take care of platforms that offer the Mastodon API under a different path prefix.

In our MastodonClient, we already have endpoint and method (and could add software) as separate values, so we could have checks comparing with this JSON asset in the few relevant methods of our client. If the check fails, we could throw some UnsupportedVersionException - and even have a way to build our client with this check disabled, to allow for library users to perform it themselves if they want to try it on different server software.

Would this be worth doing?

[andregasser]

Thanks for bringing this up. I'll get back to this asap.