-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Support MSC3814: Dehydrated devices v2 aka shrivelled sessions #13581
Conversation
Some differences: - We use GET instead of POST for the events endpoint. - We don't delete the device implicitly when fetching events. - We allow the fetch device messages endpoint for both dehydrated and the current requesters device. Signed-off-by: Nicolas Werner <n.werner@famedly.com>
d397077
to
49f892d
Compare
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.
Some comments for you; no particular complaints from me but I'm very out of the loop on dehydrated devices.
It looks like this MSC is quite early; are you expecting to have this merged or is this more a proof of concept at this point?
synapse/rest/client/devices.py
Outdated
super().__init__() | ||
self.hs = hs | ||
self.auth = hs.get_auth() | ||
self.device_handler = hs.get_device_handler() | ||
|
||
self.PATTERNS = client_patterns( | ||
"/org.matrix.msc2697.v2/dehydrated_device" |
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.
"/org.matrix.msc2697.v2/dehydrated_device" | |
"/org.matrix.msc2697.v2/dehydrated_device$" |
presume that was accidentally dropped?
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.
No, it just wasn't there originally and I didn't change it. It is only needed for MSC3814, which is why I added it there, should I add it here too?
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 added it now, but there are a few other endpoints that could use it, which I didn't add it for.
synapse/handlers/devicemessage.py
Outdated
) | ||
|
||
since_stream_id = 0 | ||
if since_token and len(since_token) > 1 and since_token[0] == "d": |
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.
we seem to be mixing multiple conditions together here:
- whether a since token was provided
- whether it meets the expected format
It sounds suspicious to me that we'll just ignore invalid since tokens; should we complain with an error?
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.
Well, the MSC doesn't really describe the behaviour there. What happens in that case on other endpoints? I guess if they return an error, I can just do that here too.
Return errors on invalid token formats and terminate regex in both cases
Famedly has a customer who needs the feature. We implemented it for them and maintain a synapse fork with it. I don't really need it to be merged, the patch is fairly easy to maintain, but it might be interesting to others to play with so it is at least documented here for visibility. If this form is acceptable is probably on @uhoreg to decide :D |
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
According to @uhoreg:
Thus marking this as a draft for now. |
@nico-famedly: we are implementing this in Synapse now, so I grabbed this PR brought it into alignment with the spec proposal. The PR for this is #15929. I credited you in the changelog, and in the PR message, please let me know if there's anything else you want done to acknowledge this work! |
I think this is fine. We are however using this with our changes in production for a year now, so we need to figure out how to change our feature flagging to make it not break other clients on our deployments. Thanks for picking this up and moving it forward! |
@nico-famedly Can this PR be closed then? |
Since the commit was merged, yes :) |
Woo, thanks for your initial work on this. 👍 |
Signed-off-by: Nicolas Werner n.werner@famedly.com
This implements MSC3814 with a few changes (as proposed on the MSC):
This MSC conflicts with MSC2697, so I added a config option to disable the former and a config option to enable the latter. In theory you can use both at the same time, but it uses the same database table, which is why I would not recommend it.
Client side implementation: https://gitlab.com/famedly/company/frontend/famedlysdk/-/merge_requests/1111
Pull Request Checklist
EventStore
toEventWorkerStore
.".code blocks
.(run the linters)