FEP-f1d5: NodeInfo in Fediverse Software

source: https://git.activitypub.dev/ActivityPubDev/Fediverse-Enhancement-Proposals/src/branch/main/feps/fep-f1d5.md

@cjs the draft is now available in the FEP Index.

Smithereen also implements NodeInfo :eyes:

(partially — I don’t keep track of account activity, at least not yet)

However. The concept of posts and comments fits my presentation nicely because I have both and they are very distinct in the UI, but what if there are different kinds of content? For example, what if I add photo albums? How would I count these and photos within, or would I ignore them entirely? The idea of “kind, count” pairs does indeed feel like the way to go.

Thanks @grishka, I’ll update the FEP to add Smithereen – an oversight on my part (sorry!). Hopefully the bullet in the FEP that reads…

  • The 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.

…captures your comments around photo albums. You’re correct that ideas like (kind, count) I’m trying to not be too technically prescriptive/dictatorial in solutions, just give a general sense of what alternatives could look like. I can update the FEP to make that clearer.

Additionally, Mike provided the following feedback to me here:

  • Providing the version should never be mandatory (this is potentially a critical security issue).
  • Count of “users” should likewise not be mandatory, and if it is, the concept needs to be better defined.

In my projects, a single user can be the controlling party behind an unlimited number of communication channels which may or may not be related. The same account registrant can also create groups and “collections” (aka sub-channels). They can also clone any of these communication channels to multiple servers. It isn’t always obvious what percentage of that user’s overall activity was actually carried out on a different website. Should they be able to claim this as some percentage of a single user’s activity? If not, the counts will be wrong. Either one site will claim 100% of the user and the others will have to remove that user from their own tallies (resulting in a fictional total for any of these sites), or they will each claim 1 user and the tallies will likewise be fictional.

I’m inclined to disagree on the first bullet, but fully agree on the rest.

My disagreement on the first bullet rests on the assumption that the “critical security issue” is disclosing of a software version number that identifies software as having a vulnerability (that may be patched at a later version). Simply removing the version number is obscuring the problem, not solving it, and is security-by-obscurity. Adversaries will simply try the exploit on a server that hasn’t disclosed a version anyway, and I would argue now non-malicious users and developers alike would have less information available to themselves to identify how many servers are still vulnerable, and contact admins to upgrade ASAP. Which is a net detriment, in my opinion.

As such, I’d like to avoid putting the first bullet in the FEP.

Mike’s second bullet and elaboration I agree with and would like to modify the FEP to include.

To update: I agree with Mike that software.version should not be a required field. It is unnecessarily strict. I just was hoping to avoid citing “potential security issue” as the specific reason. I don’t feel that strongly about it as others, so I’ve gone ahead and included it with that specific rationale.

I guess software.version is required as a way to ensure compatiblity. If it could be replaced with some protocol or API version, it might alleviate the security issue, i.e., by telling machines : expect this API, instead of telling attackers: I’m running that vulnerable version. Since AP has a stable version, indeed, this field is currently unnecessary in AP context.

And this is how we come to the need to have some sort of capability negotiation between servers :wink:

Imagine people hardcoding checks for software names and versions. This can’t end well.

1 Like

Another interesting thing about instance metadata — Mastodon’s /api/v1/instance has kinda become the de-facto standard for whatever isn’t representable in nodeinfo.

I’m not sure this is the right place to discuss this, but how fixed is the list of elements that would be made available in NodeInfo?
Where should I discuss potential addition of new entries?

I have been wondering about how to decrease the incentives for various people to use the APIs or to scrap Fediverse platforms to get information about the network structure (or specific subparts of it).

I wrote about this a bit on Mastodon, including a specific proposal for server information that would complement Mastodon’s “peer” and “activity” information in the API.

Basically the idea would be to provide a privacy-preserving method to show an instance’s connectivity / the Fediverse structure, without accessing individual information.

1 Like

If I remember right, NodeInfo’s author seems particularly keen on making all fields closed bounded enumerations instead of free field text in the specification. Hence the (temporary) NodeInfo2 fork.

Probably the NodeInfo repository. But once that is completed, then to get fediverse software to adopt it, the appropriate software repositories possibly.

1 Like

Also, the above deserves its own topic.

1 Like

I remember that the name of the software was specified as an enum. Obviously, that one was never respected.