@julian @silverpill @slyborg it's also worth noting that all discussions of the WG will be on a public mailing list. People can join the meetings, comment on drafts on GitHub. People interested in making more substantive contributions can become invited experts, even if they're not from a member organization.

@julian @silverpill @slyborg most importantly: no protocol is mandatory. No protocol revision is mandatory. If the work the WG does isn't useful, nobody has to implement it.

@julian @silverpill @slyborg the issues I have marked for the next version are here.

https://github.com/w3c/activitypub/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22Next%20version%22

I know there are some on there that Silverpill won't like, such as supporting IRIs for object IDs. I think it's worth having that conversation.

@julian @silverpill @slyborg I wonder, though: what would be some changes that would worry you? I'm having a hard time imagining what they would be.

The best I can come up with are features that are too complex for small development teams (e.g. oodles of mandatory APIs), or too resource intensive for small instances to support (e.g. required to handle terabytes of big data).

@julian @silverpill @slyborg

The only other thing I can think of are forced anti-features, like mandatory advertising, mandatory algorithmic feeds, or forced participation in LLM training.

Are there other things I'm missing?

@julian @silverpill for you two especially, I wonder if you think there could be Trojans inserted into the ActivityPub 1.1 spec -- something that seems innocuous on the surface, but would actually EEE the Fediverse? I just don't think the standard is complex enough that anyone could hide anti-features in it that you and I couldn't find. Maybe, I dunno.

@julian @silverpill I think a heaping dose of skepticism is healthy for standards efforts. I'm glad to know you're keeping your eyes open.

@evan @julian @silverpill @slyborg What about "breaking" bug fixes in the spec? Many parts of spec are used by ~0 people on ~0 servers so the impact is only positive to do those fixes. Required properties is an interesting topic. Adding a required property beyond `id` (conditionally), `type`, and `input`/`outbox` for actor types *would* be breaking and potentially have a large negative impact (unless they are only associated with optional new features).

@slyborg I think this is a great point.

@evan @julian @slyborg

The best I can come up with are features that are too complex for small development teams

This is probably the biggest risk.

Another risk is changes that prevent the development of important features in the future.

@jupiter_rowland The two-implementation requirement sounds totally inadequate to me. Does it really work like that?

I think nothing new should ever be added to the core spec unless it is supported by 51% of implementers.

@fediversereport @alexchapman @ArneBab @evan @slyborg

@silverpill 'Implemented' is not boolean, some FEPs have partial implementations, implementations of a prior draft or implementations that do the opposite of a MUST

@eyeinthesky One of such "bug fixes" has already been proposed:

In section 4.1 "Actor objects", the definition of "inbox" uses the imprecise term "reference" and is different from the definition of "outbox", giving the false impression that the range of the "inbox" property is different than that of "outbox". A possible correction is to make the definition of inbox parallel with that of outbox: "An OrderedCollection comprised of all the messages received by the actor; see 5.2 Inbox."

-- https://www.w3.org/wiki/ActivityPub_errata

Previously, inbox was a reference, but now an embedded inbox collection will be considered valid:

{
  "type": "Person",
  "inbox": {
    "type": "OrderedCollection",
    "items": []
  }

It's a breaking change. I don't actually mind the change itself, but the way it was made. When I pointed out that this change affects existing implementations and asked to amend the erratum, other participants literally started to gaslight me with "there is no change" and completely ignored my objections.

@evan @julian @slyborg

@dimkr I mean implementers of ActivityPub specification. I think if a feature doesn't rise to the level of "most projects should support it", it shouldn't be included in the specification.

FEPs are a different story, In many cases 2 independent implementations of a FEP is enough.

@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