To build apps like https://the-federation.info, https://podupti.me, https://www.hello-matrix.net/public_servers.php, https://fediverse.network/ and others, application builders need to somehow get information about servers.
Different platforms have had different ways to provide metadata about themselves.
- Diaspora initially offered a HTTP response header indicating the version of the software
- Diaspora and compatible platforms later implemented a
statistics.jsonroute which was a simple JSON document listing version and usage information
- This evolved into NodeInfo which is currently used there and in compatible networks, and additionally on many ActivityPub platforms.
- I forked NodeInfo into NodeInfo2 to provide a more flexible metainfo document.
- Mastodon offers an API endpoint for both server information and user activity.
- Matrix offers an API endpoint for version information of the server.
I’ve voiced criticism before my fork of NodeInfo regarding the problem of hardcoding Enum values for protocol and services into the specification. This means for example the current NodeInfo is incompatible with many platforms like Matrix and if a new version is implemented, every single platform needs to update their NodeInfo version, keeping backwards compatibility forever to the old ones. Additionally the specification requires using a
.well-known path but still needing a separate lookup, due to the versioning scheme.
The lack of flexibility in NodeInfo means that some platforms “fill what they can” in the given keys and then fill “the real information” in the freeform
My opinion is that the versioning is unnecessarily complex, making the lookups complex and changes to enum values is not possible without releasing a new backwards incompatible version.
NodeInfo2 did not go far enough in rethinking what platforms would need to export as information. The name and usage metrics is too tied into how NodeInfo is doing things.
Platform specific API endpoints
The Mastodon API endpoint is Mastodon specific but platforms which have also implemented the Mastodon API (to make use of Mastodon mobile clients) look like Mastodon servers to apps reading information about the servers.
The Matrix API endpoint has a server software name key, but lacks all other metadata and metrics about the server.
I would like to propose a new specification under Feneas or some other (neutral) organization namespace to collect the good parts of the previous metadata specs and learn from the bad parts, creating something that has support from a wide range of the federated web developers. This specification should be able to cover the common needs across the federated web, independent of protocols used, and also be flexible enough for platforms to offer more detailed information about server capabilities or platform specific information that might not interest other servers.
I have a personal strong interest in getting this done, if for nothing else then allowing https://the-federation.info to build a better view of the federated web, so am happy to collect discussion and sync comments to the specifcation, from here and other sites I will be spamming this call out to.
The current draft, which is a fork of NodeInfo2, can be found here:
Comments, discussion, proposals, etc welcome here, on the issue tracker and anywhere you can reach me I will try to sync comments outside of here and the issue tracker to here. I’ll be contacting various developers in the federated web directly to try and get as much cross-platform support as possible for this specification.
A follow up post to this will explain a few of the reasons for the changes between ServerInfo and NodeInfo2/NodeInfo.