MSC4057: Static Room Aliases - #4057
Conversation
networkException
changed the title
7de8694 to
8a9968a
Compare
turt2live
added
proposal
|
Currently it links to this, which lists the homeservers in a room and requires authentication: I think you meant to link to this for the current non-static room directory: |
| of a room to a new room version, this could discourage users of using the feature in a state in which few homeservers | ||
| support it. | ||
|
|
||
| ## Alternatives |
There was a problem hiding this comment.
https://github.com/tulir/mauliasproxy already works for room aliases with no spec changes, and I'd expect room directories could be implemented easily too (but haven't checked)
There was a problem hiding this comment.
Perhaps the naming is a little unclear here. Essentially the goal of this MSC is to allow the functionality of mauliasproxy by just hosting a static file.
From my understanding that functionality would generally be regarded as room aliases (using /_matrix/federation/v1/query/directory), whereas the endpoint that whats called (public) room directory is what clients can query via their server over federation to search for rooms (using /_matrix/federation/v1/publicRooms). I'm not sure how these interact currently, but perhaps the MSC would be better off to be named "Static Room Aliases" then?
There was a problem hiding this comment.
Renamed the proposal and clarified this
There was a problem hiding this comment.
is to allow the functionality of mauliasproxy by just hosting a static file.
this shifts the complexity (extra http request, caching, etc) from a static alias provider (using the proxy or the proposed mechanism) to the alias resolver. i don't see why we would want to do this given that there are much more alias resolvers than static alias providers in the public matrix network
There was a problem hiding this comment.
Right, I'd argue that there aren't more static aliases because it's hard to set up.
Even when people looking to provide vanity aliases know about the federation API technically supporting such behavior, the user experience is quite bad. You need to think about maybe managing a signing key and at the very least you need a Web Server that can switch on query parameters (NGINX doesn't by default!)
|
|
||
| ```json | ||
| { | ||
| "#hq:example.com": "!OGEhHVWSdvArJzumhm:matrix.org", |
There was a problem hiding this comment.
Just having the room ID isn't enough. To join a room, we need to know what server(s) can be used to join (like the via parameter in matrix URIs)
There was a problem hiding this comment.
Included servers to match https://spec.matrix.org/v1.8/server-server-api/#get_matrixfederationv1querydirectory
networkException
changed the title
- Rename to Static Room Aliases to clarify scope - Mention mauliasproxy as an existing implementation of a minimal homeserver that achives the proposed scope - Use JSON object and include `servers` field in mapping to match the federation api response - Formatting and grammar fixes
| Instead of defining room alias mappings in a well-known path, the current `.well-known/matrix/server` content | ||
| could be extended to include a new field, delegating the room aliases for an entire domain to the federation | ||
| api of a different homeserver. This would also require some sort of permission system to support the use case | ||
| described in the abstract however, as otherwise any user on a homeserver would be able to create a room alias. |
There was a problem hiding this comment.
Instead of delegating this, the /.well-known/matrix/server file could also be extended to include a key like m.static_room_aliases
|
|
||
| ## Unstable prefix | ||
|
|
||
| [MSC2324](https://github.com/matrix-org/matrix-spec-proposals/pull/2324) describes well-known apis as not being |
There was a problem hiding this comment.
.well-known and other APIs that can't be versioned
Best effort is appreciated. Typically these endpoints will be receiving minor behavioural changes or new fields. New fields should be appropriately prefixed, and behaviour changes should be rolled out cautiously by implementations (waiting until after FCP has concluded is probably best to ensure there's no major problems with the new behaviour).
Given we currently directly referenced a versioned federation API response, perhaps there should be a top level JSON key referencing that version?
7 participants
Rendered
Signed-off-by: networkException <git@nwex.de>
Disclosure: I work for the German government agency FITKO where I also participate in the Matrix Community. This proposal is written and published by me personally without my work hat on.