Initiative: ActivityPub "Step On Board" Integration Guide

ActivityPub
19

@trwnh mentioned:

@ashrijver: Core FEP’s might be chronologically numbered, and other FEP’s have their generated ID’s.

@trwnh: this is a statement that needs more explanation – what happens to the old generated id? what determines if an FEP is “core”? and “core” to what and whom?

And my take on this is:

I don’t know if “core” is the correct name, hence the scare quotes. There are some things in the specs that any AP impl for any type of app must minimally take into account to be compliant. The MUST’s in the spec, if you will, but also some additional stuff. The holes in the spec around security, etc. Other stuff that’s still unspec’ed ‘tech debt’. Must-haves to securely exchange msgs between endpoints (actors) on the Fediverse.

This “core” may also include some new stuff we add in order to provide a stable, comprehensive foundation. More stuff around security most likely, nomadic identity maybe, and possibly also ‘compliance profiles’ that allow devs to build heterogenous integrations on top of the core. Define the extension mechanism of the pluggable AP protocol, if you will. As said, that can be very minimal at the start… I just want to find the specs for your list of supported use cases.

Then there are those things - many of them also ‘tech debt’ - you must do to interop with a subset of app-types / domains. Here’s where many very specific have organically grown over the years, and they involve the Mastoverse and increasingly the Lemmyverse/Threadiverse. This stuff is either Compliance Profile scoped, or they may be optional “core” FEP’s, for instance.

If you look at the XEP’s like XEP-0060: PubSub they don’t just have a status going from ‘Experimental’ to ‘Stable’, but they also have a version field.

If we’d go with a similar scheme for AP, then in the Integration Guide we get something like:

Steps to Join the Fediverse with ActivityPub

  1. Implement FEP-0001, FEP-0002, FEP-0003 (MUST)
  2. Select other protocol extensions to implement (MAY)
  3. Find compliance profiles to support (SHOULD)
  4. Create your own compliance profile. See Integration Guide: Part 2 (MAY)

As for the existing FEP’s and their numbering… they are kind of all over the place in subjects they address. We defined a very loose, informal process. At least for “core” FEP’s we should go more formal. Some current FEP’s may be candidates to become core, or have part of the info to be moved to a core FEP. The remaining FEP’s can continue to use their generated ID’s.

So a Compliance Profile might be something like this (just brainstorming):

- name: Microblogging Profile
- id: PROF-ad3cf
- description: This profile encompasses a minimal feature set for Microblogging apps on the Fediverse.
- supports:
    - FEP-0001, FEP-0002, FEP-0003
    - FEP-0006, FEP-0009
- specification: https://activitypub.rocks/profiles/microblogging/latest/

--------

- name: Mastodon Profile
- id: PROF-13af5
- description: This profile offers the full range of features that Mastodon provides.
- supports:
    - PROF-ad3cf
    - FEP-874aa, FEP-6bf31
- specification: https://docs.joinmastodon.org/spec/activitypub/

Just to sketch the idea. Idk if profile dependencies are a good idea, and maybe there should be an extends property or whatever. And instead of PROF-xxxxx the ID’s could be just FEP’s too.

1 Like