In reply to @xiretza:xiretza.xyz

is there any place in the spec that tells you to redact things in an attempt to fix invalid data? where is this idea coming from?

In reply to @xiretza:xiretza.xyz

is there any place in the spec that tells you to redact things in an attempt to fix invalid data? where is this idea coming from?

In reply to @gnu_ponut:matrix.org
Someone said earlier that this is what servers should do.

In reply to @richvdh:sw1v.org
Isn't this https://github.com/matrix-org/matrix-spec-proposals/pull/2801 writ large?

This MSC doesn't seem to touch on the main thing here. We currently use key names to namespace everything, that's why we have unstable prefixes. It is entirely reasonable to enforce the types of values for known keys. In this case the type was invalid, so it is correctly rejected. This preserves extensibility by ignoring unknown keys

Your point on "server that doesn't know of key X can't validate it so clients need to check anyway" is valid, but for servers this should not be an issue, the validation requirements are different imo

In reply to @reivilibre.element:librepush.net
is it considered acceptable that an old server that doesn't know about the key yet, would be able to join the room, but a newer one cannot?

In reply to @reivilibre.element:librepush.net
alternatively, the spec should define semantics in 'layers' — each layer is a JSONSchema that applies to portion of an event, e.g. there would be a 'm.room.create predecessor layer', which defines exactly how to validate the predecessor portion of the event, and every server agrees to only apply the semantic of a room predecessor if that layer validates

In reply to @neilalexander:dendrite.matrix.org
Layering like this is also a bit slippery. Take for example the difference in how Synapse decodes JSON (decoding into what is effectively a hashmap and tolerating whatever) vs how Dendrite does (decoding into a typed structure and erroring on type mismatches). Unless we're prescribing that JSON has to be decoded in multiple stages for specific event types, which might not be very feasible in some languages, we're not really getting to the root of the issue. The spec has ultimately told us that certain keys with certain names should be certain types, the bottom line is that is the rule everyone should be playing by

TBH I don't think decoding in multiple steps/layers is necessarily the worst idea. We already have to be able to 'decode JSON whilst ignoring unknown keys', you'd conceptually just sort of do that several times.

I agree that enforcing these things harder is the right way to do it, but you're still left with the question of how you apply semantics to mishmashes from before that validation was possible (and this sort of stuff also applies client-side in encrypted payloads I'd say)

In reply to @deepbluev7:neko.dev
And if people turn off that validation, it is fair if servers refuse to join those rooms, because nobody needs to respect tulir's experiments! :p

In reply to @cat:feline.support
Doesnt Tulir only turn of CS API level validation?