-
-
Notifications
You must be signed in to change notification settings - Fork 97
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
Fix definition of response of POST /_matrix/federation/v1/user/keys/claim
#1559
Conversation
…laim Also fixes the rendering of nested OneOf. Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
- type: string | ||
- type: object |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm unconvinced this is correct. Is it true that a string can be returned here? The description doesn't seem to say anything about that being permissible.
@KitsuneRal you seem to have suggested this is correct at #1351 (comment), but I don't know why you said that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question - might very well be a copy-pasta on my end. Can one-time keys be unsigned - guess not? If not, my suggestion is incorrect and there should be KeyObject
here, without alternatives.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, so it's not a copy-pasta on my end at least. The alternative between string
and object
has been here since the very beginning, even though undocumented. My comment in #1351 referred to the correct nesting level and I mentioned that string
has to be returned only because it has been there before. If it hasn't been correct from the beginning then I'd rather we fix it in a separate PR but I'm fine either way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I think I've figured this out!
Before we invented the signed_curve25519
key algorithm for one-time-keys, we just used curve25519
keys. These, not being signed, can be represented just by a string.
The curve25519
algorithm should no longer be used here, but removing them from the spec sounds like a different job.
So, 👍 to this fix.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes to the layouts
files look good, but I remain unconvinced about the change to the endpoint definition.
As discussed in #1351 (comment) and #1310 (comment).
The rendering of the type now looks like this (to compare with current state in the spec in the response of the endpoint):
Also fixes the rendering of nested
OneOf
s, so it has the added bonus of fixing the rendering ofm.room.encrypted
.ciphertext
:CiphertextInfo
:cc @KitsuneRal to make sure I got it right this time.
Preview: https://pr1559--matrix-spec-previews.netlify.app