A side note on Last Week in the ATmosphereWelcome to the weekly update:
That’s cool. Has there been any work done on defining NodeInfo as an FEP? I seem to remember @jaywink talking about an updated version of NodeInfo pre-pandemic, which suggests there are problems with the way it’s traditionally worked that could be addressed in an FEP process.
As pointed out, there is a FEP for it already, but it pretty much ONLY says “Fediverse software SHOULD implement NodeInfo”, while providing no other requirements, just a list of caveats and issues identified by the community.
I’m not sure what the justification is for using it on an atproto PDS. From the PR linked (“effort”), it seems the intent is to identify a PDS as a PDS, as well as expose the total count of records present across all repositories it serves? I have reservations about the specific PR and how it currently relies on the key usage.records."app.bsky.feed.post", but then again, I also have reservations about the general existence of NodeInfo in the first place[^1], so I’ll refrain from commenting about the value of using NodeInfo to expose statistics about a PDS or specifically about app.bsky records. As long as it’s not required, I suppose there’s no harm in it.
[^1}: To summarize briefly: it’s largely redundant with other mechanisms like host-meta and as far as I can tell, it mostly exists so that you can express statistics without being expected to use XML by defualt. Aside from that, the /.well-known/nodeinfo endpoint works identically to the /.well-known/host-meta.json endpoint, except it’s extremely limited by the expectation that the only links present are links to JSON documents that adhere to a specific NodeInfo schema. Aside from that, I personally don’t see a need to expose statistics about usage or users or any of the other things that NodeInfo can be used to expose. If you really wanted to, then you could expose those as properties of the host-meta document (and heck, you can even choose to publish it only as a JRD via the host-meta.json endpoint while completely neglecting the XRD expected at the host-meta endpoint!)
I suspect this has been discussed elsewhere, at great length (I’m sure I’ve seen a version of @trwnh’s critique of NodeInfo before), but it’s on-topic so…
My understanding is that NodeInfo began as a feature of Diaspora, and thus became part of the ad hoc Diaspora protocol. Allowing all instances of software that federated over it to be listed by sites like the federation.info (created by @jaywink ). It was then retrofitted to OStatus/AP software to allow instance monitoring sites to list all fediverse instances.
I agree that the collection of instance stats for this purposes (and any other) raises privacy issues. These need to be carefully considered in the design and use of NodeInfo, or any potential successor.
For example, it’s obvious that a stats collection standard must not be part of the expectations of vanilla AP, so an FEP is definitely the right place for it. I also think its better to make it as explicit and modular as possible. So I’m not sure about folding it’s functions into another tool like hosts-meta.
But to me, the instance mapping allowsed by NodeInfo continues to have the same obvious benefits it’s always had, including;
I’m pretty sure there are ways of improving NodeInfo so it does a better job of these things (and others), while also addressing any potential privacy risks we can think of. Also, where possible, reducing its server load and bandwidth use for both instances, and mapping sites.
Side note on terminology: the phrase “instance monitoring” (which I’ve used on the fediverse.party wiki, for example) is derived from the use of software and services that do realtime monitoring of uptime, traffic etc, on a server. But the word “monitoring” has some unfortunate associations in a social media context. I will be using “instance mapping” to describe this from now on.
What’s the difference between a NodeInfo object vs. just defining specific properties of the host-meta document?
“Part 1” of my critique is that .well-known/nodeinfo and .well-known/host-meta.json operate identically – the host meta could link directly to NodeInfo objects in the exact same way that the nodeinfo endpoint links directly to NodeInfo objects. So I really can’t find any justification for the existence of .well-known/nodeinfo as an endpoint, aside from the weak expectation that the XML version of the host meta is also available.
“Part 2” of my critique is that you could replicate every single piece of data exposed in NodeInfo objects as properties of the host. Because that’s what they are, conceptually. A “host” or “service” or “instance” or whatever, it’s all the same, isn’t it? Just about the only thing you get with it being a separate document is that you enforce a JSON-Schema on it, and if it returns HTTP 200 then you can assume that it will match that schema.
I think a new NodeInfo FEP is needed. In addition to discussing privacy and security risks, it should also discourage people from using this endpoint for publishing unrelated data (e.g. lists of supported AP extensions and features). Developers and instance operators should be able to turn off NodeInfo reporting without breaking anything else.
Where should features and extensions be published? I wish all servers told you if the supported client APIs like C2S, Misskey or Mastodon/Pleroma including streaming API. I have been using this information for a game project.
A good question, which is well above my paygrade. I suspect we’re talking past each other. I’m arguing for an FEP that updates the standard stats collection methods. Since NodeInfo is the traditional name for this function, that’s the term I’m using. But I’m not arguing for any particular detail of the existing NodeInfo way of doing things.
What I suggest is that you gather up some of these details of your preferred replacement, and post them as an issue in the Fediverse Ideas repo, as a first step towards defining a new stats collection FEP. Perhaps this could replace NodeInfo. Perhaps it could be considered interchangeable, with instance mapping supporting both if they want more complete stats. I guess that would ultimately be determined by what implementers do with them.
Ideally a method for signalling what FEPs are supported, and preferred, would be part of vanilla AP. But that would be a pretty major (possibly breaking?) change. For now, I guess it needs it own FEP. Anyone know if there is one?
There are 3 FEPs that describe signalling via NodeInfo:
One (unpublished) that describes signalling via server actor:
And another one describes the usage of DOAP:
For Mastodon API clients I prefer to signal support via Instance endpoint (/api/v1/instance). For example, Pleroma adds this information to .pleroma.metadata.features array, which is then used by some clients.
I think there shouldn’t be a need to signal supported AP extensions. Fediverse protocols should be designed in a way that enables organic interoperability without capability negotiation. However, in some cases implementation can rely on the presence of specific properties. For example, a followable actor can be identified by the presence of the followers collection.
It’s been a while since I tried it but I think I had a lot of difficulty with identifying Misskey client API. I had to to just query a couple published Misskey endpoints on a server and see if it responded in some valid way because at the time there wasn’t an obvious thing to query that just said “I support Misskey client API”. Part of the issue was that there was a new Misskey fork every fifteen minutes that changed the server identification, so if I didn’t recognize the server identification I had to start that exploration process to see what it supported, if any. In particular, streaming APIs. I canceled the project when Mastodon disabled streaming API access without warning (not a scraper or search engine, it was a game that dynamically generated player maps based on server activity.)