Fediverse Extension Discovery via NodeInfo — Complete Reference

Servers expose /.well-known/nodeinfo containing a JRD document:

{
  "links": [
    {
      "rel": "http://nodeinfo.diaspora.software/ns/schema/2.1",
      "href": "https://example.social/nodeinfo/2.1"
    }
  ]
}

Schema Versions

• 1.0 / 1.1 — initial versions
• 2.0 — significant revision
• 2.1 — current most widely deployed version

Key Properties

The metadata field is deliberately unstructured. The spec says: "Clients should not rely on any specific key present." This is where extension discovery proposals place their data.

FEP-6481: Extension IRI List (WITHDRAWN)

FEP-6481 proposed the simplest approach: an array of IRIs in NodeInfo metadata declaring which ActivityPub extensions a server supports.

Wire Format

{
  "version": "2.1",
  "protocols": ["activitypub"],
  "metadata": {
    "activitypub": {
      "extensions": [
        "https://w3id.org/manyfold/3dModel#v1",
        "https://joinbookwyrm.org/ns/activitypub#Review"
      ]
    }
  }
}

Requirements

• Extension identifiers MUST be valid IRIs
• IRIs SHOULD include version information via fragment identifiers (#v1)
• Once defined, IRIs cannot change while maintaining compatibility
• Long-term persistent URI services (like w3id.org) are recommended

Why It Was Created

James Smith ("Floppy") created Manyfold, a federated 3D model manager that extends ActivityPub with the f3di namespace (http://purl.org/f3di/ns#). When Manyfold sends activities with custom 3D model types, servers like Mastodon silently discard them. There was no way to discover in advance whether a remote server would understand the custom types.

Why It Was Withdrawn

Floppy withdrew FEP-6481 on 2024-10-31 in favor of FEP-9fde (by nikclayton), which covers the same use case with broader scope. FEP-9fde can express everything FEP-6481 proposed while also addressing client APIs, federation features, and arbitrary server operations.

Community Objections

nightpool's strong objection: "I strongly, strongly object to this FEP." The argument:

• ActivityStreams 2.0 is designed to be extensible via JSON-LD — add extra properties to standard types (Note, Article, etc.) and servers that don't understand them simply ignore the extra fields
• Custom types (BookWyrm's Review, Manyfold's 3D model types) break graceful degradation because standard servers discard unrecognized types entirely
• Capability-based routing (sending different formats to different servers) fragments the ecosystem, increases complexity, and multiplies the testing surface

stevebate's concerns: the definition of "extension" was too vague; fragment-based URI versioning (#v1) doesn't work with HTTP (fragments aren't sent to servers); dereferenceable URIs should use path or query parameter versioning instead.

nutomic's reinterpretation: saw it as a traffic filtering mechanism — Lemmy could use it to tell servers "don't send me Like activities, I use voting."

FEP-9fde: Operations Map (Successor)

FEP-9fde (by nikclayton, DRAFT) extends NodeInfo with a standardized operations property using reverse-FQDN identifiers and semantic versioning.

Wire Format

{
  "operations": {
    "org.joinmastodon.api.statuses.post": ["1.0.0", "1.1.0", "2.0.0"],
    "app.manyfold.activitypub.accept.3dmodel": ["1.0.0"],
    "io.github.glitch-soc.api.statuses.bookmark": ["1.0.0"]
  }
}

Key Differences from FEP-6481

Design Rationale

FEP-9fde explicitly rejects several alternatives:

• OpenAPI definitions — too complex for clients
• Hardcoded version mappings — maintenance burden and version-locking
• Capabilities flags — combinatorial explosion as features interact
• IRI identifiers — case-sensitivity issues; reverse-FQDN avoids this

The Broader Capability Discovery Landscape

Multiple proposals address the same fundamental problem:

FEP-eb22: Supported ActivityStreams Types

Lists which Activity and Object types a server handles:

{
  "activities": ["Create", "Update", "Delete", "Like", "Announce"],
  "objects": ["Note", "Article"],
  "properties": {}
}

Focuses on describing the standard ActivityStreams vocabulary a server supports, rather than arbitrary extensions or operations.

FEP-844e: Capability Discovery via Actors

Instead of using NodeInfo, attaches capability information to the ActivityPub application actor itself. Based on FEP-aaa3 (listing implemented specifications on the application actor). This keeps capability data within the ActivityPub protocol rather than relying on the external NodeInfo protocol.

FEP-67ff: FEDERATION.md

A human-readable approach: servers include a FEDERATION.md file documenting their federation behavior. Status FINAL. This solves the documentation problem but not machine-readable discovery.

Comparison

The Custom Types Debate

A fundamental philosophical question underlies all extension discovery