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.

Sign up for GitHub

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

Jump to bottom

MSC1704: Adding ?via= to matrix.to permalinks to help with routing #1704

Merged
merged 1 commit into from
Jan 10, 2019
Merged

MSC1704: Adding ?via= to matrix.to permalinks to help with routing #1704

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 36 additions & 0 deletions proposals/1704-matrix.to-permalinks.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
# matrix.to permalink navigation

Currently Matrix uses matrix.to URIs to reference rooms and other entities in a
permanent manner. With just a room ID, users can't get into rooms if their server
is not already aware of the room. This makes permalinks to rooms or events difficult
as the user won't actually be able to join. A matrix.to link generated using a
room's alias is not a permanent link due to aliases being transferable.

In lieu of an improved way to reference entities permanently in Matrix, a new parameter
is to be added to matrix.to URIs to assist clients and servers receiving permanent links
in joining the room.

For reference, existing permalinks look like this:

```
https://matrix.to/#/!somewhere:example.org
https://matrix.to/#/!somewhere:example.org/$something:example.org
```

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
Copy link
Contributor

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.

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`
Copy link
Member

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Query params of https://matrix.org/docs/spec/client_server/latest.html#post-matrix-client-r0-join-roomidoralias

Copy link
Member

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
Copy link
Member

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?

Copy link
Member Author

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.

is to pick up to 3 unique servers where the first one is that of the user with the
highest power level in the room, provided that power level is 50 or higher. The other
2 servers should be the most popular servers in the room based on the number of joined
users. This same heuristic should apply to the first server if no user meets the power
level requirements.
KitsuneRal marked this conversation as resolved.
Show resolved Hide resolved