Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support strings as power levels under feature = "unstable-synapse-quirks" #346

Closed
jplatte opened this issue Nov 11, 2020 · 3 comments · Fixed by #350
Closed

Support strings as power levels under feature = "unstable-synapse-quirks" #346

jplatte opened this issue Nov 11, 2020 · 3 comments · Fixed by #350

Comments

@jplatte
Copy link
Member

jplatte commented Nov 11, 2020

Some older rooms have power level events with string power level rather than integers. To work around this:

  • Add an unstable-synapse-quirks feature to ruma-events and forward it from dependent crates

  • Create a deserialization function in ruma-serde that accepts both integers and strings

  • Add

    #[cfg_attr(feature = "unstable-synapse-quirks", serde(deserialize_with = "ruma_serde::deserialize_int_or_string"))]

    to all power level fields

This still might not handle all existing broken power level events though, since there might also be ones out there that use power levels > MAX_SAFE_INT.

CC @aledomu

@aledomu
Copy link
Contributor

aledomu commented Nov 11, 2020

This still might not handle all existing broken power level events though, since there might also be ones out there that use power levels > MAX_SAFE_INT.

That would not be broken, but neglectful. The defacto max power level is 100, we should not prevent anyone in their quest for absolute trouble and destruction by going higher than that.

@aledomu aledomu self-assigned this Nov 11, 2020
@jplatte
Copy link
Member Author

jplatte commented Nov 11, 2020

No, that would be broken. Canonical JSON, which has to be able to represent any event, explicitly disallows larger values (and values smaller than MIN_SAFE_INT):

Numbers in the JSON must be integers in the range [-(2**53)+1, (2**53)-1].

https://matrix.org/docs/spec/appendices#canonical-json

Side note: If that wasn't the case, js_int would not exist

@aledomu
Copy link
Contributor

aledomu commented Nov 12, 2020

I should have phrased it better: it would not be just broken, but even neglectful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

2 participants