You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The server-related part of a Matrix room ID (e.g. abolivier.bzh in !XvGbFViZZIJPftczyH:abolivier.bzh), aka the "server name", can differ from the FQDN the server is actually accessible at. In this example (!XvGbFViZZIJPftczyH:abolivier.bzh), my server's name is abolivier.bzh even though the server itself actually lives at chat.abolivier.bzh. Assuming server name = FQDN can work in some cases (e.g. with the matrix.org server) but doesn't cover most cases.
Translating a server name into a FQDN can be done using either a DNS query on the SRV record _matrix._tcp.[serverName] or through matrix.org's federation tester.
The Matrix badge generation considers the second argument in the URL as both the server's name (in order to build the room's ID) and the FQDN it lives at.
🔗 Link to the badge
Here's an example of a badge for a valid room on my server:
Use either a DNS query or the federation tester to resolve a server's FQDN.
On top of that (though not really related to this specific issue) badges should use room aliases instead of room IDs as a room isn't bound to a specific server (and using room IDs could render the badge unusable if there's no longer any user on the server that created the room in it).
I also wanted to use this opportunity to thank you, and especially to thank @fr1kin, for contributing a Matrix badge to Shields 🙂
The text was updated successfully, but these errors were encountered:
Fixes#2524
This PR addresses the issues expressed in #2524, in that it:
* checks if a server has advertised a FQDN it can be reached at and if that FQDN hosts Matrix's client APIs
* uses room aliases instead of room IDs, in order to avoid a badge being impossible to generate if the server that created the room leaves it
This includes a breaking change to the badge endpoint.
Are you experiencing an issue with...
🪲 Description
The server-related part of a Matrix room ID (e.g.
abolivier.bzh
in!XvGbFViZZIJPftczyH:abolivier.bzh
), aka the "server name", can differ from the FQDN the server is actually accessible at. In this example (!XvGbFViZZIJPftczyH:abolivier.bzh
), my server's name isabolivier.bzh
even though the server itself actually lives atchat.abolivier.bzh
. Assuming server name = FQDN can work in some cases (e.g. with thematrix.org
server) but doesn't cover most cases.Translating a server name into a FQDN can be done using either a DNS query on the SRV record
_matrix._tcp.[serverName]
or through matrix.org's federation tester.The Matrix badge generation considers the second argument in the URL as both the server's name (in order to build the room's ID) and the FQDN it lives at.
🔗 Link to the badge
Here's an example of a badge for a valid room on my server:
https://img.shields.io/matrix/!XvGbFViZZIJPftczyH/abolivier.bzh.svg
💡 Possible Solution
Use either a DNS query or the federation tester to resolve a server's FQDN.
On top of that (though not really related to this specific issue) badges should use room aliases instead of room IDs as a room isn't bound to a specific server (and using room IDs could render the badge unusable if there's no longer any user on the server that created the room in it).
I also wanted to use this opportunity to thank you, and especially to thank @fr1kin, for contributing a Matrix badge to Shields 🙂
The text was updated successfully, but these errors were encountered: