FEP-0151: NodeInfo in Fediverse Software (2025 edition)

Standards Fediverse Enhancement Proposals
1

Hello!

This is a discussion thread for the proposed FEP-0151: NodeInfo in Fediverse Software (2025 edition).

It is a revised version of FEP-f1d5: NodeInfo in Fediverse Software, which was published in 2020.

FEP-f1d5: NodeInfo in Fediverse Software
2

looking at you, gotosocial…

2 Likes
3

The FEP has been updated: https://codeberg.org/fediverse/fep/pulls/604

The section about capability discovery now says that servers MUST NOT infer capabilities from the software field

4

In the "Capability detection" section, it is written that "Protocol-specific capability discovery mechanisms could be used instead."

Such mechanism has not been proposed yet for ActivityPub, so I started to write a FEP about it:

https://codeberg.org/silverpill/feps/src/branch/main/844e/fep-844e.md

1 Like
5

Adding the "Implementations" section and a reference to FEP-844e:

https://codeberg.org/fediverse/fep/pulls/741

I'd like to finalize this FEP, so please send your Final Comments!

1 Like
6

I have noticed recently people are putting new links in their nodeinfo that are not nodeinfo. I wonder if the spec needs to be more clear that it is not ok to just add whatever you like?

Example: https://www.martijn.be/.well-known/nodeinfo

1 Like
7

I don't know, does it create problems for NodeInfo clients?

The additional relation type in this JRD was introduced in FEP-2677: Identifying the Application Actor. As far as I can tell, adding links is not against NodeInfo protocol specification, but if additional links cause issues, we can discourage that practice in FEP-0151.

8

It does, but I can certainly develop against it on my end, but that requires me knowing things change which do not most of the time. If the spec holds a standard then if and when that standard changes it makes it a lot easier to plan for re-development to meet the standard vs debug if something breaks.

9

Per NodeInfo there isn’t any specific requirement for ONLY certain link relations to be exposed:

Servers must provide the well-known path /.well-known/nodeinfo and provide a JRD document referencing the supported documents via Link elements.

Currently the following relations are known:

  • http://nodeinfo.diaspora.software/ns/schema/1.0. Referencing a JSON document following the NodeInfo schema 1.0.
  • http://nodeinfo.diaspora.software/ns/schema/1.1. Referencing a JSON document following the NodeInfo schema 1.1.
  • http://nodeinfo.diaspora.software/ns/schema/2.0. Referencing a JSON document following the NodeInfo schema 2.0.
  • http://nodeinfo.diaspora.software/ns/schema/2.1. Referencing a JSON document following the NodeInfo schema 2.1.

[…]

A client should follow the link matching the highest schema version it supports.

The client is free to follow any of the links with any rel that it understands.

A rough algorithm for clients understanding 2.1, 2.0, 1.1, and 1.0 is as follows:

  • Parse links as an array.
  • If a rel of http://nodeinfo.diaspora.software/ns/schema/2.1 is found, follow that link.
  • Otherwise, if a rel of http://nodeinfo.diaspora.software/ns/schema/2.0 is found, follow that link.
  • Otherwise, if a rel of http://nodeinfo.diaspora.software/ns/schema/1.1 is found, follow that link.
  • Otherwise, if a rel of http://nodeinfo.diaspora.software/ns/schema/1.0 is found, follow that link.
  • Otherwise, assume there is no NodeInfo.

Later, if NodeInfo 2.2 gets finalized, then the algorithm can be modified to check for 2.2 before 2.1, 2.0, 1.1, or 1.0.

If the client only understands up to NodeInfo 2.0, then it would skip over a 2.1 link and use the 2.0 link if found. Otherwise, it would look for 1.1 or 1.0 in that order.

If the client only understands NodeInfo 2.0 and NodeInfo 2.1, then it would skip over links to 1.1 and 1.0 and assume there is no NodeInfo.

You generally shouldn’t be following links whose relations you don’t understand, unless you are just browsing the web.

Generally speaking, the document at /.well-known/nodeinfo can be any JRD. This JRD can be served via /.well-known/nodeinfo, /.well-known/host-meta.json, /.well-known/host-meta with content negotiation to Accept: application/json or Accept: application/jrd+json, /.well-known/webfinger with an appropriate resource parameter, or any other arbitrary URI/IRI. To the HTTP server responding to such requests, the information may be coming from the same source, or they may all be aliases for the same document.

10

Yes you read the current spec just like we all did, this thread is about proposed updates not reading the current one.

11

If you’re proposing that it shouldn’t be okay when it already currently is, then you would need to justify that argument. It shouldn’t cause any problems to encounter extra information.

12

It is a loose spec, always has been that’s why they are adding the other proposed language with words like MUST vs saying nothing. Does not really matter to me, the ask was for comments, I made one.

1 Like
13

@observer Does this issue only affect your NodeInfo client, or all clients? I am not familiar with the challenges of developing a client, my software only publishes NodeInfo.

If it affects all clients, then we certainly need to add a warning to the FEP. If it only affects your client, then it would be better to work around that.

14

I can not answer that by any means, no idea who uses the data point. Fine to move on, I have adapted.

1 Like
15

Alright, I am changing the status to FINAL

https://codeberg.org/fediverse/fep/pulls/760

16

sorry for last-minute comments, but 2 things:

Servers MUST NOT publish incorrect usage statistics.

what defines “correct” here? also, is a SHOULD NOT here sufficient?

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.

these requirements read as redundant, and also the 2nd requirement is more restrictive than the 1st which is weird. i would drop the 2nd sentence (the MUST NOT and MUST) and merge its reasoning with the 1st requirement because the 1st sentence is already saying you SHOULD NOT do this (and i believe it is a SHOULD NOT and not a MUST NOT – it is likely a bad idea but doesn’t carry any critical constraints or hard requirements)

otherwise the FEP is fine.

1 Like
17

what defines "correct" here?

Inflated or randomized stats, for example. I don't like "incorrect" here, but haven't found a better word yet.

also, is a SHOULD NOT here sufficient?

No, I think data aggregators like fediverse.observer are useful services, and there is no good reason to disrupt their operation by poisoning data.

these requirements read as redundant, and also the 2nd requirement is more restrictive than the 1st which is weird

I think these should be separate requirements.

The first one is about any NodeInfo parameters, including metadata. There is a FEP about advertising capabilities using metadata (FEP-9fde), I want to discourage this practice, but this method is already used in the wild, hence a SHOULD.
On the other hand, I can't think of any good reason to rely on software. This is a discriminatory practice, because as a developer you can easily add a feature flag to your NodeInfo metadata, but you can't change software to e.g. mastodon.

18

suggested language re: “correctness”

this is kind of tricky to word i guess, but for conformance (to the extent that any software “implements” this fep and would be listed in the “implemented by” section) i am not sure how you would really detect “incorrect” usage.users numbers. you can maybe guess that the number is too high or too low, but a valid number is a claim like any other – it can be untrusted, trusted, or distrusted. i think maybe you could include a section or note or something about it instead of making it a requirement because it is mostly unenforceable. from what i can read of the nodeinfo 2.1 schema the example codeblock you give is valid:

"usage": {
  "users": {}
}

since usage requires usage.users, but usage.users doesn’t require anything. but this is also valid, due to declaring minimum values of 0:

"usage": {
  "users": {
    "total": 0,
    "activeHalfyear": 0,
    "activeMonth": 0
  }
}

so maybe some language like this?

Hiding usage statistics

Some softwares may 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 SHOULD NOT publish false usage statistics; instead, servers wishing to hide their usage statistics SHOULD publish an empty object:

"usage": {"users": {}}

suggested paragraph break re: metadata and software.name / software.version

the first requirement i think is missing the “unintentional” case where nodeinfo is simply missing or the software is unaware of nodeinfo for whatever reason. given that, maybe the following wording could work?

Capability detection

Servers SHOULD NOT rely on NodeInfo data for protocol negotiation and capability detection, because server operators might not publish NodeInfo.

Servers MUST NOT infer capabilities from the software field and MUST treat software.name and software.version values as opaque strings. Other mechanisms could be used instead […]

since you said the two requirements should be separate, they are now separated into different paragraphs, and the bit about other mechanisms could be appended to the 2nd paragraph.

suggested expanded reasoning re: software.name and software.version

i can think of a reason it might come up for not-exactly-capability reasons. assuming it’s accurate, a tuple of (software.name, software.version) does signal a set of semantics and an implied context for term definitions. there are better ways to deal with this problem (like ideally having softwares use terms correctly according to their definition), but there is an issue with different softwares using the same terms with different meanings, so it can be helpful to know “this is mastodon 4.x, so the as:attachment array is implicitly ordered even though the term is defined as unordered”, or “this is akkoma 3.10.2, so i am going to assume the litepub 0.1 context and not fetch the context document”, or other compatibility hacks reliant on implementation-specific quirks. what we want to avoid is the discriminatory practice you describe where software might feel pressured to declare itself as mastodon, just like http User-Agent strings all contain mozilla/5.0 to this day. but more importantly, i think the other flaw with this kind of sniffing is that it’s incredibly fragile – you have to be aware of all softwares ahead-of-time in order to work around them, which is a fool’s errand. this could be mentioned explicitly:

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 is often a cause of bugs due to fragile parsing of these strings. Other mechanisms could be used instead […]

19

suggested language re: "correctness"

This is much better, thanks. I also changed "incorrect / false" to "intentionally skewed" (as @phnt suggested in another thread).

suggested expanded reasoning re: software.name and software.version

Added that too, and mentioned a valid reason for checking software version: security vulnerabilities.

PR: https://codeberg.org/fediverse/fep/pulls/761

2 Likes
20

FEP-0151 is now FINAL, with 5 implementations: https://codeberg.org/fediverse/fep/pulls/760

1 Like