Clarify room version requirements on MSC3381

[Johennes]

I believe #3381 is erroneously blocked on the extensible events system and its room version requirements. Polls don't exist in the current spec. Poll events, therefore, cannot conflict with any other events in existing room versions. Additionally, the only extensible events building block that polls depend on is m.text. This has already entered the spec in v1.15 via #3765, however.

Process note: MSCs can receive clarification changes post-FCP, but anything materially different requires a new MSC. I believe this qualifies as clarification because the room version restriction for polls does not appear to have any practical uses and arbitrarily prevents us from adding them into the spec.

[turt2live]

It's intentional that implementations are forced to use unstable event types in existing room versions, as polls use a different event structure than is currently found in rooms.

This would qualify as a major change and require its own MSC.

[Johennes]

It's intentional that implementations are forced to use unstable event types in existing room versions, as polls use a different event structure than is currently found in rooms.

Yes, but I'm not sure what problems this creates. Clients that don't support polls would probably not render poll events. It seems like we would have the same issue with a separate room version because we cannot exclude clients that don't support that version from such a room?

[turt2live]

Polls leverage the full extent of the extensible events system, which is completely incompatible with how events work today. Removing the room version requirement means sending events which are not using the same event system in rooms that aren't expecting that, potentially creating assumptions within clients that they can be compatible with extensible events when they aren't.

We also want to retain the ability to change how extensible events works still. By specifying polls, we'd be locking ourselves in to that system - a thing we don't want to happen. This is part of the reason why the MSC forces unstable prefixes to be used: clients are required to accept the fact that polls can and may still change in incompatible ways. The MSC acceptance here is more or less to say that the core semantics are present, but the dependency on extensible events keeps the representation unstable.

The JSON objects are compatible, but that's not the conflict: it's the definitions and semantics applied to those JSON objects.

[Johennes]

Thanks for explaining. I have to admit I'm still struggling a bit to follow these concerns. Polls appear to use the same parts of extensible events as #3765. Yet they are blocked (for close to two years by now).

Anyway, my intention was to helpfully progress something that I thought was unblocked by the acceptance of #3765. If you don't concur though, that's fair and I think we can close this then. I didn't mean to put up any argument.