FEP-6481: Specifying ActivityPub extension support with NodeInfo

Standards Fediverse Enhancement Proposals
, ,
1

This is a discussion thread for the proposed FEP-6481: Specifying ActivityPub extension support with NodeInfo.
Please use this thread to discuss the proposed FEP and any potential problems
or improvements that can be addressed.

Summary

Many FediVerse services extend [ActivityPub] and [ActivityStreams] to add their own behaviour, such as custom object types. In order to interoperate with other servers running different software, the service needs to know whether or not the remote server supports these same extensions.

This FEP defines a standard method of specifying support for particular extensions in the server’s [NodeInfo] file (as described in [FEP-f1d5]), so that compatibility information can be automatically discovered.

2

Oh thanks, this is exactly the FEP I needed for FEP-54af!
But maybe we should also add an fep: [ ] array?
I.e.

{
  ...,
  "metadata": {
    "activitypub": {
      "extensions": [
        "https://joinbookwyrm.org/ns/activitypub#Review"
      ],
      "fep": [  "6481"  ]
    }
  }
}

And another concern — maybe the FEP should explicitly mention said extension URI must/should be usable as JsonLD @context?

3

Not all extensions will require new JSON-LD terms to be defined.

(Actually this is one argument in favour of a mechanism like this, as opposed to using the @context to indicate extension support, which I’ve seen suggested elsewhere.)

4

You may need to describe the meaning of an “extension” more clearly in the FEP. Is it a reference to a version of a specific AP/AS2 type, a JSON-LD context document URL for a collection of terms, or just an opaque identifier that references nothing, etc.? What about purely behavioral extensions (no new types or properties)?

The following example from the comments is interesting. Is Review an Activity or a non-activity Object? As a server developer, how would I use this information?

Can you explain your rationale for recommending fragments for URI versioning? Is there any expectation that these URIs can be dereferenced to get more information (e.g., the JSON-LD context document, JSON Schema, LinkML schema, OWL Ontology, and so on using context negotiation)? If so (and I think that would be useful), the fragment may be a problem. HTTP can only retrieve the base URL and then the client must somehow find the fragment-referenced information from the resource. I’m not sure that would work at all if the URI is referencing a JSON LD context document. For schemas or other information, the URL would return the information for all versions, and then the client would need to determine how to extract the version they wanted. Assuming the fragment structure of the full resources is not defined in the FEP, this would be impractical in general.

1 Like
5

Based on the examples this seems like a way to filter the sorts of activities an instance can receive. Because the other direction, using unsigned fetch there is no way for an instance to exclude any extensions from the response. Am I understanding this right or can extensions change anything else besides which activities to receive?

If this is correct then I would instead suggest an allowlist eg Create,Like means that you can only receive these two types of activities and nothing else. In this way it could actually reduce federation traffic for unused types, also those defined in the standard.

Though in Lemmy the main problem we have is the massive amount of simple Like activities for votes. So we are actually thinking about batching multiple activities in a single /inbox request.

6

I strongly, strongly object to this FEP and I discourage anyone from sending different versions of activities or objects to different servers. It goes counter to the fundamental design of ActivityPub. Instead, I recommend that you use extensions of the core vocabulary types when backwards compatibility is desired, and use additional properties to enable additional extended behavior. The AS2 core spec lays this strategy out in detail.

2 Likes
7

For some time I advocated some mechanism to convey Compliance Profiles (or whatever name to give them). I agree with @nightpool that they should be used primarily to discover what extensions an endpoint supports. It is not enough to just hyperlink a JSON-LD context document here. In order to learn how to integrate with the extension (message formats, msg exchange, business logic) a pragmatic way would be to include a link to where the extension’s specifcation docs are hosted. These can be in FEDERATION.md, but that is not a universally followed practice, nor does it scale well to complex AP designs (many actors / services, many repo’s / large monorepo’s).

See also: Initiative: ActivityPub "Step On Board" Integration Guide - #19 by aschrijver

8

Hi folks! Thanks for the feedback, and sorry for my delay in replying, I had some trouble signing up to socialhub.

First off, to respond to @nightpool, I’m entirely open to the idea that custom types aren’t necessary or desirable; if I can avoid making one for my application, I will, and I’ll have a deeper read of the activitypub spec to look at how to do that. However, there are already applications doing this, so perhaps there is some need. I’m no expert though.

So far I’ve avoided specifying exactly what the IRIs should be, beyond that they should be something, in the interests of keeping it as simple as possible. But, if people think that for instance, the IRI MUST resolve to the documentation or spec of the extension, that could be added.

I did consider that another list could be added for accepted parts of the core standard, alongside the extensions one. Could be added, or could be a followup FEP.

@stevebate the FEP tries to say that some sort of version is recommended in the IRI, but not how. The fragment is just meant as an example, there could well be a better idea. I wasn’t intending the IRIs to be necessarily resolvable, just a nice standard way of providing an identifier. Could be more tightly specified, certainly, or as laxystem says, making it so the IRI should be usable as a JSON-LD @context.

@stevebate Also the general idea of “what is an extension” is, I agree, vague; the idea was to have a very flexible way of detecting these things that doesn’t overload other fields like software. But maybe something more tightly defined is better?

Thanks for all the feedback, and for taking the time to read it - I’m new to this world of AP and FEPs, and learning on the go, so it’s all very much appreciated :slight_smile:

2 Likes
9

Welcome to SocialHub :wave: Glad that you managed to sign up… it indeed comes with issues sometimes.

I think that can be a SHOULD. We can’t require folks to document their own stuff, but it would be highly recommended.

1 Like
10

The XMPP Community has done related work that may be worth reviewing:

2 Likes
11

FEP-9fde: Mechanism for servers to expose supported operations (author here) has some overlap with this.

1 Like
12

I got swerved onto other work after proposing this, and am only now getting back to it. I think that @nikclayton’s FEP-97de covers what I was trying to do here, and is much more recently active, so I’m happy to withdraw this FEP in favour of that one.

2 Likes
13

I opened a pull request: #443 - Withdraw FEP-6481 - fediverse/fep - Codeberg.org
Let me know if you change your mind.

1 Like