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