-
Notifications
You must be signed in to change notification settings - Fork 29
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
Next #2822
Conversation
Codecov Report
@@ Coverage Diff @@
## master #2822 +/- ##
==========================================
+ Coverage 93.51% 93.60% +0.08%
==========================================
Files 111 110 -1
Lines 6001 6036 +35
Branches 1086 1093 +7
==========================================
+ Hits 5612 5650 +38
+ Misses 335 331 -4
- Partials 54 55 +1
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
This removes completely the requirement to having access to peer's presence directly from the matrix server, and instead replace it with the requirement for the PFS to know (already required for mediated transfers) and provide that presence (implemented in `next` RSB). Instead of searchUserDirectory, we request the PFS `/address/.../metadata` endpoint for its view of latest peer's presence.
Now that presence is fetched from PFS, we don't need to join discovery global room anymore, and since PFS and MS rooms were removed previously, we can clear the utility and helpers which supported this.
Also fix some typos
and validate peer's displayname signature coming from service
Services now return a new `address_metadata` field which maps addresses to their respective metadata/presence object. We need to handle this, and pass it in a transfer's metadata. Besides this, mediated transfers should try to use this mapping in the incoming transfer's metadata to optimize not having to request metadata from service to send the output message. This usage, despite validated by signature, should be constrained to this transfer only (for now).
Processed, SecretRequest, SecretReveal and Unlock messages Also, don't use messageSend's userId on retries: If this message had to be retried, maybe the userId isn't valid anymore, so we remove it on retries, to force transport to re-fetch this peer's presence/metadata, or mind its own caching mechanism as needed.
So, PC mediators assume they're the 1st address in route, and their partner 2nd, and trim it when forwarding the transfer. We comply here until they can handle passing whole metadata unchanged.
PC signs metadata with checksummed addresses, but send them all lowercase-serialized. We were also decoding addresses checksummed, but `address_metadata`, being a dict, was being exempted from this change. This is just a workaround: proper fix is to perfectly sign what is received/sent (passthrough), and being able to handle receiving both.
This reverts commit 4198e17.
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.
Basically everything has been already review by PRs targeting the next
branch. I just took a quick look on the last commits. Looks all good to me. So I don't see a reason why we should not merge this to master
. So the final testing before the mainnet release can start.
Fixes #
Short description
Definition of Done
Steps to manually test the change (dApp)