Standard document/endpoint that defines how a Server federates

[ThisIsMissEm]

At present, the norm is to just send all activity and object types to all servers, which leads to software needing to ignore activities and object types that it doesn't understand, resulting in increased network traffic.

By defining a document such as /.well-known/federation that specifies what activities a server supports, what object types it natively supports, and what object types it'll convert (and to what), which is machine readable, this would allow servers to reduce the number of requests that are sent needlessly to servers that don't understand those activities.

[erlend-sh]

Related: https://socialhub.activitypub.rocks/t/fep-67ff-federation-md/3555?u=erlend_sh

[ThisIsMissEm]

Related: https://socialhub.activitypub.rocks/t/fep-67ff-federation-md/3555?u=erlend_sh

Yup, but Federation.md is designed to be human readable, not machine readable.

[silverpill]

We have two new FEPs focused on machine readable indicators:

• https://codeberg.org/fediverse/fep/src/branch/main/fep/6481/fep-6481.md (SocialHub topic).
• https://codeberg.org/fediverse/fep/src/branch/main/fep/9fde/fep-9fde.md (SocialHub topic)

[ThisIsMissEm]

@silverpill neither of these defines what Activities a server produces or handles, nor what Object types the produce or consume (or convert).

i'm also not sure we should be cramming everything into NodeInfo either.

[ThisIsMissEm]

This issue also came up, in a way, in a recent FediForum session: https://fediforum.org/2024-03/session/1-e/

[evanp]

We discussed this in issue triage. I am not crazy about this structure, since it makes the server supreme. I think that general-purpose AP servers should accept all activities, use a fallback representation for activity or object types it doesn't understand, and let client software decide what to do with activity types.

However, for AP servers that are special-purpose, like an IOT device or a video game, it may make sense to have a restricted set of activity types that are handled. We discussed using a accept/reject list format, as follows (just conceptual, not actual syntax):

- Activity types accepted:
  - Like
  - Create
  - Delete
  - `*` (some equivalent)
- Object types accepted:
  - Note
  - Image
  - `*`
- Activity types rejected:
  - Block
- Object types rejected:
  - Video
- Conversion type
  - Article -> Note
  - Audio -> Note

This should be implemented as a FEP. Probably a good idea to include it in the endpoints for an ActivityPub actor, as well as some sort of .well-known document. Could be nodeinfo.

[ThisIsMissEm]

There's another related proposal here: https://www.manton.org/2024/03/22/fep-for-supported.html

[ap-socialhub]

This issue has been mentioned on SocialHub. There might be relevant details there:

https://socialhub.activitypub.rocks/t/fep-eb22-supported-activitystreams-types-with-nodeinfo/4469/8

[github-actions[bot]]

This issue has been labelled as potentially needing a FEP, and contributors are welcome to submit a FEP on the topic. Note that issues may be closed without the FEP being created; that does not mean that the FEP is no longer needed.

[evanp]

So, we have a comment from @ThisIsMissEm , there is at least one FEP in process for this topic. So I think the next wtep is to close this issue.