Provide FEP process pathway to further W3C SocialCG formalization

Standards Fediverse Enhancement Proposals
,
1

Returning to the discussion on FEPs, it might be beneficial to consider a more structured process. FEPs could progress through stages such as proposal, implementation, and approval - or something similar that suits our workflow.

A proposed FEP could proceed if it garners at least 3 ACKs without any NACKs. Any disagreements could necessitate further discussions. A resolution team, primarily consisting of project and free software representatives and possibly some members from W3C SWIGC, could facilitate this process, given their availability.

Well-received FEPs could be elevated to the status of W3C Notes, assuming no complications. Ideally, these would have at least 2 implementations and wide acceptance.

For a more formal standard, we can draw inspiration from three notable documents, which offer a structured approach to creating standards:

  1. RFC 7282
  2. Rules for Standards-Makers
  3. Design Principles from W3C

This is just an outline of what something can look like. FEPs already have a system, a path towards becoming a a W3C spec with note status could be the icing on the cake.

Edit: we should not think about getting W3C REC status. That is a multi year process, and needs a charter and many hoops. The specs are already REC, but some bugs could be fixed. Notes however can happen relatively easily. We should establish the exact criteria for a note and then make one for the FEP process itself, then test it with a FEP that is the most popular and that is already in use, perhaps.

Edit2: There are also W3C Group Reports, which may be a good fit for adopted FEPs. I think it just needs to be proposed as a group work item, to start the ball rolling.

2

The whole point of the FEP process is that there are no gatekeepers, ACKs or NACKs. This is clearly stated in FEP-a4ed:

The editor checks if the proposal conforms to the required structure and fits the scope and objective of the FEPs. The editor may request the authors to clarify, justify, or withdraw the proposal. Such a request must not reflect the personal bias of an editor. Rather, it will be made strictly to maintain a high quality of submissions.

and on the main page:

Editors are neutral custodians of the FEP process, who merge PR’s, create tracking issues, and start discussion threads for each FEP in the SocialHub developer community forum.

1 Like
3

BDD solution:

  • FEPs provide test suites
  • Green implementations are endorsements

Of course, this probably forces my view what makes a specification good and software good on the world. So it’s a fantastic solution.

4

Perfectly valid, but then how do you differentiate those that are more serious from those that are more casual?

In particular, which ones would be on a track to be w3c work items, notes, or CG reports.

5

I don’t think W3C needs to be involved.

Everyone makes their own judgement. If proposal is technical in nature and has merit, developers may implement it, but as FEP-a4ed states, proposals are not required to be serious. Of course, if FEP author wants to suggest a work item for W3C, they can do it, but this is out of scope of the FEP process.

3 Likes
6

there is a possibility for an FEP or its contents to be adopted as an official w3c note or errata or whatever. say we wanted to define something that could fit either into the activitystreams namespace/context or into an fep-specific namespace/context. there are certainly advantages and disadvantages to each.

7

That may be the case, but it’s already involved

  • it published the latest drafts of AS/AP
  • it publishes the contexts
  • it can change the context

What I’m saying is that the FEP process needs to be able to guide FEPs through different stages of maturity on a par with how W3C does it. It’s common in free software to have a system like “2 ACKs, no NACKs”, for example. That is not about gate keeping, it’s about changes or proposal affecting developers that run the software. Have a look at that link I shared about humming (straw polling), rough consensus, and running code. FEPs need a way to reach consensus.

1 Like
8

@melvincarvalho By implying FEP needs the W3C to validate itself, you are doing a disservice to all the people involved in making FEP happen. They have created a process that can stand on its own. So big kudos to everyone involved :partying_face:

The real question (and original topic of this thread) is if the W3C will get its act together and before the HTML story repeats itself with ActivityPub. The jury is still out on this.

2 Likes
9

What I’m suggesting is not that FEPs necessarily require the W3C, but rather they should operate on an equal footing, transitioning specs from proposal to maturity, and acknowledging their intersection.

The W3C WG and FLOSS processes differ; entering a WG can be challenging and often depends on fee payment. This structure had political implications in the past and is not in line with the OSS approach.

Conversely, while FEPs are relatively new compared to W3C’s 30-year history of technical consensus, both could learn from each other. However, decision-making may need to transition towards an FEP-like process. Questions still remain, such as how would the FEP process handle hosting a vocabulary, a context, etc. These are aspects we still need to clarify.

1 Like
10

IF there is going to be normative changes to the specs, I cant see how the W3C will get to a REC under its current fee model and also be fully inclusive of FLOSS.

Edit: caveat this important rule change may be relevant too : https://beta.w3.org/2021/Process-20211102/#revised-rec-editorial

11

There’s two ways of looking at the proposal:

  1. Extending the FEP process with more formality to align more with W3C.
  2. Leaving the FEP process almost as-is, but allowing a follow-up / integration with a formal W3C extension process.

The FEP was made KISS-as-possible to lower the barriers for anyone to create them. Any added ceremony adds maintainance overhead, more dedication of volunteers, more authority bestowed to select no. of people.

But I guess @trwnh’s mention that FEP’s can become formal W3C Notes, makes sense. That can easily be seen as a process that follows after the FEP process. FEP gets status FINAL? Hey, this looks it should be universally adopted, core functionality
 start W3C process. Once a W3C Note is published the FEP’s status goes from FINAL to W3C-NOTE.

3 Likes
12

+1 to both, that makes sense

While acknowledging the need for process robustness in Codeberg that aligns with established standards bodies, it’s essential to remember that there are various models to draw inspiration from, including the IETF and lighter open-source methodologies like PIPs and BIPs.

Currently, it appears that the W3C community group lacks a formalized procedure for issue closure, and is not consistently adhering to certain commitments, such as providing appropriate context for closed issues. The current state could be described as somewhat chaotic, with a risk of inadvertent normative changes being introduced.

Given these circumstances, Codeberg might be a suitable parallel platform to consider, with the understanding that it would need to adopt an issue management process that is at least on par with, if not superior to, what is currently used by the community group. Of course, the preferences of other significant stakeholders like Mastodon should also be followed.

There was chatter in the call this week about a new charter. At this point, it would favour the fee paying membership who have automatic access, and prevent a diverse open source participation. So in the longer term I think an open source fork offers the best possibility of diverse participation.

Edit: encouraging comments from @nightpool regarding guiding implementers, and interop:

nightpool: yeah, this is somewhat a contentious topic in socialweb spaces in general – it’s important to ground our discussion of implementers in terms of the audiences they represent. Internet today is successful because of the users who choose their software and why they choose to use it. Nobody in the socialweb space is a monopoly on the grounds of vendor lock in, we have interoperable specs, self hosting, etc. Most important to think of when guiding implementation - priority of constituencies and users. Implementers important as well, but we should be cognizant of users.

a: in order for those potential implementers to become real implementers - the reason anyone might be holding off on any of these specs is just the confusion around some of them. Lot of things that need to be clarified/addressed. Obv they’re not perfect, they’re good, but room for improvement. E.g. why hasn’t C2S spec not taken off, things like that. Needs guidance and clarification. People read the spec, don’t understand part of it, don’t get vision or motivation, they just look at dominant implementations, and follow suite. At the end of the day interop is what we’re after, here. Work will be best served by improving the specs, making sure they’re clear, actionable.

13

Yeah, I personally think this is the most helpful approach the community can adopt.

Use the FEP process as a low barrier to entry first incubation level. And then, if a particular FEP proposal gathers implementation and momentum, and if there’s interest from the authors or the community, it can be proposed as a Work Item for the SocialWeb Community Group for further development (with more eyes and a more structured process on it).

2 Likes
14

I think this is an important point going back and forth and I want to make my position on this extremely clear: I don’t think a “lightweight” process is the end-all-be-all goal of standardization. I think lightweight processes are an important component to protocol exploration and development, but I think as changes and proposals mature they need to go through a process that involves consensus-based standardization and a more in-depth discussion period. The FEP process right now is designed around a “many specs means everybody can be right from their own point of view” design philosophy, which is a really difficult and dangerous process when we’re talking about . There’s no way to prevent overlapping FEPs in different topic areas, or to allow different implementers to come to a consensus about the right way to handle a topic area, just a single proposal. The FEP process explicitly allows for no editorial judgement about the way a protocol is designed, which means that every proposal stands on its own instead of building towards a unified system

We’ve seen this same pattern repeat time and time again with XMPP, IRC, and others, and every single time it leads to a spec that is too scattered across too many small “extension” documents with too many ill-defined interaction points to be able to understand. I do not think that a “spec microservices” architecture is good way to design a spec and I do not think the SocialCG should attempt to formalize the FEP process as is, because it is fundamentally, heavily designed around that sort of approach.

I believe very strongly in the consensus based standardization working modes of the W3C, and I believe that editorial judgement in combination with a tight prototyping loop and close collaboration with implementers is the right way to develop a spec. The FEP process is almost the exact opposite of that approach.

The vast, vast majority of issues closed are simple editorial and implementation questions. No issue closed so far has had a major impact on the spec. ActivityStreams 2 and ActivityPub are finalized specs, and while we have a lot of space to scope out extensions, the issue closure process for mature, finalized specs looks very very different then it does. I think Evan has been doing a great job handing issues, closing them, and working this knowledge of where people get confused and the questions they have into a supplemental Primer document. It is incorrect to expect that any issues in the ActivityStreams or ActivityPub repo at this point will continue to stay open unless they represent a new, feasible, well-scoped extension to the spec that we think the CG is likely to work on (and in that case I would suggest a transfer to swicg/general would still make more sense. Happy to follow up off-list or in DMs about any specific issues you think have been inappropriately closed.

100% agree with this. If and when we feel like we have significant enough changes that have built up and cannot be handled as extensions—changes that require a full new revision to the ActivityPub or ActivityStreams specs—then we can consider a new working group. Not before.

Note, just for clarity: this paragraph is quoting @trwnh (also known as a), not me. The first quote, attributed to nightpool: is mine, the second is not.

4 Likes
15

@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:

  1. W3C Standardization track
  2. FEP Protocol interop best-practices
  3. Domain-specific AS/AP (vocabulary) extensions
  4. ( 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.

2 Likes
16

this is correct but imo not a strictly bad thing. there is a distinction to be made between protocols and profiles i think – i’d warrant that most FEP stuff deals with payloads and patterns. whether this is part of a “protocol” or not depends on your viewpoint. if you take “protocol” to include all this stuff, then we might say that the Mastodon Protocol is a thing that exists, while the ActivityPub Protocol does not exist. this is a criticism that has come up several times regarding the “fediverse” and how fragmented it really is, despite largely sharing the “activitypub” branding.

now, here’s where we may disagree: i think that it might be a good thing to have FEPs serve as the “building blocks” to construct profiles of FEPs that might form a “protocol”. it’s a level of minimal formalization that allows clearly setting the expectations of how a software like mastodon might differ from a software like lemmy or funkwhale. given an expansive enough library of FEPs, it becomes possible to define each software’s “protocol” as a composition of FEPs, which i would refer to as a “profile”. it behooves us all to root out and identify and document all the undocumented behaviours, quirks, etc. that our softwares have, and to allow for common patterns and practices to converge over time. i think having this happen through FEPs is a vast improvement to having it happen only in codebases via each project’s decision-making process. because that’s not a “standard”. it might end up being a de facto one, if everyone copies those decisions, but that’s not a good outcome.

a big part of the problem is that they are not. extensibility in activitypub and activitystreams can be summarized as “idk, just use LD lol”. and then most people don’t actually use LD at all. and the ones who do use LD don’t always use it properly. and even if they did, you have to be aware of all those extensions that might be relevant to you, so that you don’t reimplement basically the exact same thing. so it’s a mess.

seems to me like there is room for FEPs or W3C Notes or whatever to attempt to clean this up? like a “best practices for extensibility” FEP that explores all the LD-like options and tries to figure out which ones can be best approximated in “plain JSON” land. i’ve mentioned before that the requirement in AS2-core to use only compacted form is
 especially unfortunate, because “plain JSON” extensibility is now a nightmare of trying to establish shared context in a system where you fundamentally don’t understand context. i’m not fully aware of all the pitfalls and gotchas this creates, because there could be so many of them and you’d only catch them if you either ran into them yourself or if you had a deep enough knowledge of the codebases for each project you cared about interoperating with. at least something ought to be done to improve this at whatever level of standardization is appropriate.

yes hi i am a

a is the name i go by in local contexts, trwnh is what i usually use for global contexts (where a might either be already claimed, not a valid option, or ill-advised due to irc-like mention pings). you can probably read more about that on my website, assuming i don’t completely move everything around in some future redesign of the info architecture

2 Likes
17

to expand on this part:

  • we might look at the base “status federation” and “profile federation” as similar to the “group federation” described in FEP-1b12 and implemented by lemmy and friendica. imagine an FEP for mastodon’s core “federation”, which fully details expectations like prioritizing Notes and requiring actors to be one of the “five types” and all the other similar decisions that mastodon’s codebase enforces on “posts” and “profiles”. i realize this will probably have to have some “living elements” or otherwise allow for overriding it with a newer version of the FEP as some of those requirements change, but there’s mechanisms and prior art for this. xmpp has annual compliance suites for instant messaging and whatever. FEPs have a “replacedBy” metadata that could be used to model this.
  • we might also look at every single extension under ActivityPub - Mastodon documentation as potentially its own FEP. i also expect that the standardization discussions around such FEPs would lead to some changes being made, or at least different choices that are more respectful of the standards rather than deferring to whatever unilateral decisions were made in the past. see for example FEP-fb2a “actor metadata” which is intended to formalize the “freeform bio/profile/user metadata field” pattern while not relying on the schema dot org vocab (with the wrong IRI, to boot!) or mixing as2 and schema vocabs haphazardly.
3 Likes
18

“We reject kings, presidents and voting. We believe in rough consensus and running code.” – IETF

Proposal : Social Web Standards Principles

  1. Collaborative Effort
    Respectful collaboration among open source standards organizations, each acknowledging and respecting the autonomy, integrity, processes, and intellectual property rules of the others Standards work should be free from fees or financial barriers to entry.

  2. Commitment to Foundational Principles
    Adherence to the five fundamental principles of open source standards development:

    • Due process: Decisions are reached equitably, ensuring fairness among participants. No single party dominates or drives the development of standards. Processes are transparent, with clearly defined opportunities for appeals. Standards review and update procedures are well outlined and routinely undertaken.

    • Broad consensus: Processes are designed to consider and address all viewpoints, fostering agreement across a diverse range of interests.

    • Transparency: Standards organizations provide public, advance notice of proposed standards development activities, detailing the scope of work and conditions for participation. Records of decisions, including the materials used in making those decisions, are easily accessible. Public comment periods are provided before final approval and adoption of standards.

    • Balance: No individual, company, or interest group holds exclusive dominance over the standards activities.

    • Openness: Standards processes are accessible to all interested and informed parties.

  3. Collective Empowerment
    A shared commitment from the open source standards organizations and their participants towards collective empowerment, striving for standards that:

    • are selected and defined based on technical merit, as judged by the expertise contributed by each participant;

    • enable global interoperability, scalability, stability, and resilience;

    • foster global competition;

    • serve as the foundation for further innovation; and

    • contribute to the formation of global communities, benefiting humanity.

  4. Availability
    Standards specifications are made freely available to all for implementation and deployment. The organizations affirming these standards have well-defined procedures for developing specifications that can be implemented under equitable terms. Taking into account market diversity, equitable terms may vary, but the commitment is to ensure base protocols are royalty-free, which also safeguards against charging royalties through the pre-sale of author minted tokens.

I’ve proposed a set of principles to guide social web standards work. Open Stand Principles are signed up to by the W3C and IETF. I’ve updated it to align to free and open source software, and the modern climate of royalty free, open standards. The final paragraph may need some work to ensure open, royalty-free standards. I used to believe standards bodies stuck to these principles. But far too often they are ignored. I believe socialhub can not only match existing standards bodies, but go further and better. With this structure it could be possible to improve activity pub, create drafts for new work, while respecting the autonomy of existing bodies, and the ongoing issue tracking and documentation.