Unable to join Rooms in a different HS by roomId

[pik]

Effectively isRoomPublished should just toggle whether the room is available in the directory listing of the other server (or contiguous and significant behavior should be spec'd / documented).

On the other-hand at the moment attempting to join a room on a different HS by <room_id> fails:

 https://matrix.org/_matrix/client/r0/join/!LyUOBSZLhKOHYlsCmU%3Amatrix.amaznev.net?access_token=<access_token>

# fails with
{"errcode":"M_UNKNOWN","error":"No known servers"}

[pik]

So there was an ongoing discussion on matrix.dev about this - and I'm not sure if everything is clarified or not (I think I was missing a fair bit of context).

POST /_matrix/client/r0/join/{roomIdOrAlias}
Note that this API takes either a room ID or alias, unlike /room/{roomId}/join.

The spec explicitly states valid arguments are {roomIdorAlias} notably joining by {roomId} of a room which exists on the User's Homeserver works.

Why is it failing for a remote server? Well apparently Synapse looks for an un-spec'd argument server_name to be present if the room_id is on a remote host ( https://github.com/matrix-org/synapse/blob/master/synapse/rest/client/v1/room.py#L248):

        if RoomID.is_valid(room_identifier):
            room_id = room_identifier
            try:
                remote_room_hosts = request.args["server_name"]
            except:
                remote_room_hosts = None

For example:

curl 'https://matrix.amaznev.net:8448/_matrix/client/r0/join/!XqBunHwQIXUiqCaoxq%3Amatrix.org?access_token=<access_token>' -H 'Pragma: no-cache' -H 'content-type: application/json' -H 'accept: application/json' -H 'Connection: keep-alive' --data-binary '{}' --compressed

{
    "errcode": "M_UNKNOWN",
    "error": "No known servers"
}

# Note the `server_name=matrix.org` argument in the second Curl which works. 
curl 'https://matrix.amaznev.net:8448/_matrix/client/r0/join/!XqBunHwQIXUiqCaoxq%3Amatrix.org?access_token=<access_token>&server_name=matrix.org' -H 'Pragma: no-cache' -H 'content-type: application/json' -H 'accept: application/json' -H 'Connection: keep-alive' --data-binary '{}' --compressed

{
    "room_id": "!XqBunHwQIXUiqCaoxq:matrix.org"
}

I guess the next step is to figure out which is correct here, the spec or the server_name argument expected by Synapse - in the later case the spec and various SDK's should be updated to provide server_name, in the former - a couple line patch to synapse should handle extracting the remote_server_name from a complete RoomID (<room_id>:<server_name>)

[richvdh]

I guess the next step is to figure out which is correct here, the spec or the server_name argument expected by Synapse - in the later case the spec and various SDK's should be updated to provide server_name, in the former - a couple line patch to synapse should handle extracting the remote_server_name from a complete RoomID (<room_id>:<server_name>)

Room IDs are opaque - the domain part is there only for namespacing, and it is never correct to try to extract it and use it as a server to talk to. I think passing the server_name query param is the correct approach for now at least, though as you note it is unspecified.

[richvdh]

Closing this for now; I think the problem is in the spec, not synapse.

[pik]

Room IDs are opaque - the domain part is there only for namespacing, and it is never correct to try to extract it and use it as a server to talk to. I think passing the server_name query param is the correct approach for now at least, though as you note it is unspecified.

Can you explain where this logic comes from (as far as the domain part), when exactly would a server_name be better? For example consider a user that wants me to join a room on their HS, they might link me <!opaque_id>:<domain_name> which they can copy/paste from their room settings. On the other hand according to what you are saying they shouldn't just tell me !XqBunHwQIXUiqCaoxq:foo.net but tell me !XqBunHwQIXUiqCaoxq:foo.net and server_name: foo.net - exactly what kind of improvement does this bring?

[richvdh]

it means it still works if their server is no longer participating in the room they started.

I'm not claiming this area is perfect, but we have been very careful to keep room IDs as opaque blobs and I don't think we should change it to fix this.

In any case, here doesn't seem to be the right place for this discussion. You may wish to weigh in on element-hq/element-web#2925, or if you still feel strongly that room-IDs should not be opaque, open an issue at matrix-doc

[pik]

I wasn't saying that <!opaque_id>:<domain_name> should guarantee resolution (alias doesn't either) - only that it would be a pretty sensible synapse behavior to parse domain_name from the room_id, especially if server_name is not provided and the room_id is on a remote host.