-
Notifications
You must be signed in to change notification settings - Fork 379
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
MSC1704: Adding ?via= to matrix.to permalinks to help with routing #1704
Conversation
https://matrix.to/#/!somewhere:example.org/$something:example.org?via=example-1.org&via=example-2.org | ||
``` | ||
|
||
Clients can pass the servers directly to `/join` in the form of `server_name` |
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.
what are these server_name
parameters of which you speak?
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.
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.
ah, i misread /join as the slash-command rather than the API.
parameters. | ||
|
||
When generating the permalinks, clients should pick servers that have a reasonably | ||
high chance of being in the room in the distant future. The current recommendation |
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.
should we try to use the server from the domain part of the room id?
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.
imo servers should already be appending the server name in the room ID to the candidates so clients don't have to worry about it. There's no guarantee that the server name in the room ID is still a resident in the room, or has a chance of being around for a while so I'm further hesitant to recommend it.
There hasn't been a whole lot of feedback in the negative for this proposal, and I think I've addressed the concerns that were raised: @mscbot fcp merge |
Team member @turt2live has proposed to merge this. The next step is review by the rest of the tagged teams: No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
By adding a new parameter to the end, receivers can more easily join the room: | ||
|
||
``` | ||
https://matrix.to/#/!somewhere:example.org?via=example-1.org&via=example-2.org |
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.
Note that this is a breaking change for any clients that parsed matrix.to urls using naive string-splitting. Per @turt2live in #matrix-spec:matrix.org, the clients he sampled didn't fall into this category and either handled matrix.to links like real URIs or didn't handle them at all. I don't see it as a huge issue (especially not compared to how awful including matrix.to in the spec at all is), but I thought it was worth documenting this concern on the PR.
The final comment period, with a disposition to merge, as per the review above, is now complete. |
Spec for [MSC1704](#1704) Reference implementations: * Original: matrix-org/matrix-react-sdk#2250 * Modern recommendations: https://github.com/matrix-org/matrix-react-sdk/blob/2ca281f6b7b735bc96945370584c5cb1b5f7e1f1/src/matrix-to.js#L29-L70 The only deviation from the original MSC is the recommendation for which servers to pick. The original MSC failed to consider server ACLs and IP addresses correctly, and during implementation it was realized that both of these cases should be handled. The core principles of the original MSC are left unaltered.
Merged via #1955 🎉 |
Rendered