@nightpool ,I agree with these observations.
I think it is important to once more note that the current FEP Process was established the way it is, because in a time of a very small dev community with a lot of ‘app focus’ and waning attention for SWICG meetings it seemed the only thing low-barrier and informal enough for people to be willing to spend any time on. And even then it took a long time for FEP to get “under steam”.
That situation has changed significantly, and there is interest to evolve the Fediverse at all levels now.
The FEP was always set up to be “as simple as possible” and improve continually based on needs and requirements. When I mentioned “Leaving the FEP process almost as-is” that was in context to its relationship to W3C.
Over the years several times I posed on this forum a division of work into three parallel tracks that - while they relate to each other - are mostly independent. With a decreasing need for formality these processes are:
- W3C Standardization track
- FEP Protocol interop best-practices
- Domain-specific AS/AP (vocabulary) extensions
- ( Implicitly exists: App-specific AS/AP extensions )
The lower you get in this list, the more speed and ease of extension, at the cost of interoperability guarantees. These are like the 4 layers of a pyramid. The cohesion of these process tracks should only go as far as to address the need to identify those things that qualify to be further formalized in higher layers, and ‘lifted upwards’ in the pyramid.
My suggestion is that the FEP is merely informative to W3C standardization. Serving as input. A source of feedback. Yet an important FEP document may not make it into a vNext standard for a long while. So if the SWICG turns that into a W3C Note to have it as input on their ‘backlog’, it would be good to indicate the higher level of significance of the FEP document with a W3C Note status, imho.
For the layers 2, 3, and 4 the FEP list currently makes no distinctions… but it should; it is one messy list right now. We currently have FEP’s that make clear distinction possible. They are FEP-2e40: The FEP Vocabulary Extension Process and FEP-9606: Using w3id.org/fep as a namespace for extension terms and for FEP documents, and there may be a couple more. Such as discovery of the capabilities of an endpoint, and compliance profiles (i.e… “Mastodon profile: Implement [all of this] to interoperate with Mastodon”)
If ActivityPub extensibility mechanisms are sufficiently well-defined, then there is no need for layers 3) and 4) to be maintained under the umbrella of the FEP process. Anyone can now host work on extensions at their own favorite place, and decentralized hubs probably work much better for active communities to evolve domain- and app-specific functional areas.