@silverpill I agree, huge parts of the spec don't have enough interoperable implementations to justify them. However, this rule also means it's super hard to 'upstream' a FEP into the spec because it's hard to count implementations that do exactly what the FEP says.

@silverpill @julian @slyborg Those are really good. I'm going to see what I can do to collect some of these concerns before we get started with the WG.

@doctormo@floss.social

Yet, given major #ActivityPub implementors don't give a shit about #W3C standard, the only way a working group can produce any protocol change is on sound technical merits.

Otherwise the standard will say irrelevant.

And on a deeper look, despite the huge limits of #Mastodon gmbh, so far it's still better then W3C.

@julian@activitypub.space

@evan@cosocial.ca I also agree with @silverpill@mitra.social that complexity is the enemy of progress.

I've seen firsthand good ideas that wither on the vine because they're too complicated to implement. Partly it could be because they're complex ideas that require refactoring or abstractions of existing code, or straightforward ideas couched in complex language.

The latter is especially unfortunate, because the solution is just good plain technical writing.

I like to think I'm a fairly good technical writer, although that hasn't been empirically proven

@silverpill I think you're talking about documenting existing practices rather than making new standards. The point of the two implementations rule, I think, is to show that the new standard is feasible and implementable. Feedback from that implementation stage informs the final standard.

@evan@cosocial.ca @silverpill@mitra.social fwiw (sorry to butt in), "most implementations" is hard to prove... where do you draw the line, by software MAUs? Down to the instance (% of active fediverse)? Gut feeling (vibes!)?

One could also argue that Mastodon alone qualifies