Remove required attribute from m.room.avatar url

[jplatte]

Might close #471 (that issue refers to "State events like m.room.avatar" but gives no other examples).

Preview: https://pr987--matrix-spec-previews.netlify.app

[zecakeh]

I agree with this clarification but it should be noted that for now Element Web (and maybe others) actually omit the field.

[jplatte]

Updated the PR to just remove the required attribute, to properly reflect reality.

(I initially tested the wrong thing, oops 😄)

[turt2live]

This opens a bit of a pandora's box on what "required" means. We also say that body is required for room messages, but if a message is redacted then it doesn't exist. Likewise, we don't actually say what a client should do if it receives a body-less message.

I think for this change to be accepted we'd need to figure out if this is actually what we want, and adjust the associated wording too. I've left this comment as a not-review to hopefully get other SCT members to take a look and form an opinion.

[jplatte]

IMHO redacted events are a red herring: They are already clearly marked as not the regular form of the event by having the redacted_because field which you can check for before looking at the event's content.

In multiple years of maintaining Ruma, this is the one and only event I've come across where the Required attribute is set but non-redacted events without the field are still (somewhat frequently) encountered by users. That's not to say there aren't any others where this could happen, but I don't see how this would be opening a pandora's box: I know of no other events I would care to apply the same kind of change to right now.

[richvdh]

I think I need more context here. If this is unrelated to redactions (which are indeed a separate case), can someone explain to me why clients are sending m.room.avatar without a url property? It seems like it wouldn't be much use.

[jplatte]

That's just what happens when you "remove" the avatar in Element Web and other clients. It sends a new m.room.avatar event without a url field to have the latest avatar be 'none' without actually redacting the information which avatar was used up until that point (which setting a new avatar would also not do).

[richvdh]

Right, I see. I think there's an argument that that would be better handled by setting url to the empty string, but otoh if the ecosystem is already doing it by removing url, that horse has bolted.

Just needs some clarifying text, imho.

[richvdh]

this lgtm but I'm going to hold off from merging it for now in case any of the rest of @matrix-org/spec-core-team want to veto it

[richvdh]

(and yes, my newsfragment CI check is broken. Fix in #993)

[turt2live]

(please do not rebase after review has been given - instead prefer merge commits. Those merge commits will disappear when we merge the PR at the end)

[jplatte]

Okay. Just noticed I force-pushed away the previous suggestion too. Will re-apply that.

[jplatte]

this lgtm but I'm going to hold off from merging it for now in case any of the rest of @matrix-org/spec-core-team want to veto it

How long is the veto timeframe? Can this be merged now?

[richvdh]

let's do it

[ShadowJonathan]

Might close #471

this did close that issue due to GitHub’s PR keywords, should that issue be closed in the end?

[richvdh]

think so

[jplatte]

See rest of the issue description, I think we don't need it anymore. Can always be reopened if other affected events are found.