silverpill
ba384adec6
Reviewed-on: https://codeberg.org/fediverse/fep/pulls/760 Co-authored-by: silverpill <silverpill@firemail.cc> Co-committed-by: silverpill <silverpill@firemail.cc>
4.3 KiB
slug, authors, type, status, discussionsTo, dateReceived, dateFinalized, trackingIssue
| slug | authors | type | status | discussionsTo | dateReceived | dateFinalized | trackingIssue |
|---|---|---|---|---|---|---|---|
| 0151 | silverpill <@silverpill@mitra.social> | implementation | FINAL | https://codeberg.org/silverpill/feps/issues | 2025-05-12 | 2026-03-07 | https://codeberg.org/fediverse/fep/issues/599 |
FEP-0151: NodeInfo in Fediverse Software (2025 edition)
Summary
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.
This document is a revised version of FEP-f1d5: NodeInfo in Fediverse Software, which was published in 2020.
Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119.
NodeInfo best practices
Servers SHOULD implement NodeInfo protocol version 2.1.
Privacy and security considerations
Some information contained in the NodeInfo document might be considered sensitive by server operators.
The NodeInfo endpoint could be disabled to hide that information.
Hiding usage statistics
Some softwares might wish to publish NodeInfo, but without revealing usage statistics. While the NodeInfo 2.1 schema specifies usage and usage.users as required properties, it does not require any additional properties within usage.users. Servers MUST NOT publish intentionally skewed usage statistics; instead, servers wishing to hide their usage statistics SHOULD publish an empty object:
{
"usage": {
"users": {}
}
}
Capability detection
Servers SHOULD NOT rely on NodeInfo data for protocol negotiation and capability detection, because server operators might intentionally disable NodeInfo.
Servers MUST NOT infer capabilities from the software field and MUST treat software.name and software.version values as opaque strings. Attempting to use this information is very difficult to do reliably, and often hinders inteoperability. However, software version information MAY be used to block instances with known security vulnerabilities.
Instead of NodeInfo, protocol-specific capability discovery mechanisms could be used. The capabilities of an ActivityPub application can be advertised using a server actor, as described in FEP-844e: Capability discovery.
metadata
Properties of the metadata object are not standardized, but some of them are widely used:
nodeName(string): The name of the server.nodeDescription(string): The long form description of the server.staffAccounts(array[string]): The list of staff account IDs (actor IDs for ActivityPub).federation.enabled(boolean): Whether the server is connected to other servers.
Example:
{
"metadata": {
"nodeName": "My server",
"nodeDescription": "My server",
"staffAccounts": [
"https://social.example/actors/1"
],
"federation": {
"enabled": true
}
}
}
Implementations
References
- Jonne Haß, NodeInfo protocol, 2014
- CJ, FEP-f1d5: NodeInfo in Fediverse Software, 2020
- S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, 1997
- silverpill, FEP-844e: Capability discovery, 2025
Copyright
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.