NodeInfo is a protocol intended to standardize upon a way to provide server-level metadata to the public. This enables tools and clients to utilize this metadata to assess server health or facilitate end-users choices about servers and software to use on the Fediverse.
NodeInfo was developed prior to the ActivityPub protocol targeted for use by diaspora, friendica, and redmatrix software. Some of the original protocols it encapsulated include diaspora, pumpio, and gnusocial.
The NodeInfo specification is incredibly strict in its schema, often requiring regex-validation and a closed set of enumerated possible values. As an objection to this, the NodeInfo2 fork was created as a form of criticism by removing some validation of fields and with some logical restructuring of the metadata. Building off of NodeInfo and NodeInfo2, ServiceInfo was briefly explored.
This FEP does not attempt to document the specific protocol details. For that, see the NodeInfo and NodeInfo2. It attempts to clarify the history and identify shortcomings with the current approaches, to bring context to developers of Fediverse Software.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this specification are to be interpreted as described in RFC-2119.
Fediverse software SHOULD implement NodeInfo.
At the time of this FEP’s writing, the current objections to the current state of NodeInfo that have been identified by the community are below. Note that any technical alternatives identified are meant to be illustrative and not prescriptive:
software.name regex is unnecessarily strict. For example, no uppercase
letters, no spaces, no non-English-alphabet, and no special characters besides
hyphen are permitted.software.version field is required, which is unnecessarily strict.
Forcibly requiring software to divulge version information is potentially a
security issue.inbound and outbound elements are specified as a closed set of enums
instead of a simple string. Protocol versioning manifests as renaming, having
to add a new enum, which results in unclear version management.openRegistrations concept due to it
being required.metadata is too lax.usage.users is not denormalized, such that implementations can provide
custom pairs of (activity counts, time period in days) that make sense for
the software.usage.users assumes that user identity is tied to a specific instance of
running software. It is unclear how to count total users when user identity
is: spread across multiple servers, spread across multiple groups, or present
within multiple collections of users. Multiple software instances could each
have a reasonable claim to counting the user as “using” their software, which
globally results users being counted more than once.usage.users activity counts likewise assume that user identity is tied
to a specific instance of running software. For the same reasons above, where
the total user counts may result in duplicate counts of the same user across
all software running, the activity counts activeHalfYear and activeMonth
may also result in a globally inflated count.activeHalfyear and activeMonth are ill-named properties for describing
the time periods of 180 days and 30 days, respectively. A “half of one year”
is 180 days 0% of the time and roughly 182.5 days only 75% of the time. A
month is 30 days only 33% of the time.localPosts and localComments are not denormalized into pairs of
(kind, counts) for software that, for example, hosts audio files, hosts
videos, or software that does not have comments, or does not have posts.localPosts and localComments are required, which is problematic for
software that does not have comments, or does not have posts.This list is not comprehensive:
CC0 1.0 Universal (CC0 1.0) Public Domain Dedication
To the extent possible under law, the authors of this Fediverse Enhancement Proposal have waived all copyright and related or neighboring rights to this work.