This config allows matrix-synapse to create a endpoint on $DOMAIN/.well-known/matrix/server used for federation.
It's a straight forward way (no port opening required) to enable federation if you are okay having a subdomain (matrix.example.org) as your homeserver address.
This solution work's for me (federation tester is happy and some manual testing). But is it reasonable to use this method or does it make more sense to integrate the ruangrupa solution into this recipe?
This config allows matrix-synapse to create a endpoint on `$DOMAIN/.well-known/matrix/server` used for federation.
It's a straight forward way (no port opening required) to enable federation if you are okay having a subdomain (matrix.example.org) as your homeserver address.
This solution work's for me (federation tester is happy and some manual testing). But is it reasonable to use this method or does it make more sense to integrate the [ruangrupa solution](https://git.autonomic.zone/ruangrupa/well-known-uris) into this recipe?
This config allows matrix-synapse to create a endpoint on
$DOMAIN/.well-known/matrix/server used for federation.
It's a straight forward way (no port opening required)
to enable federation if you are okay having a subdomain
(matrix.example.org) as your homeserver address.
nice @yksflip! and you don't have to open up the port? I'm a bit confused that you don't have to do that... but if you are sure it is then federating for you then this is pretty great! Small change 😄
nice @yksflip! and you don't have to open up the port? I'm a bit confused that you don't have to do that... but if you are sure it is then federating for you then this is pretty great! Small change 😄
yes! If you don't want to expose an extra port synapse supports delegation either by srv-dns record or like here with .well-known file. Other Matrix server then know to use 443 instead of federation port.
It's more tricky if you want to use the tld as matrix handle but also want to run matrix on a subdomain. Then you'd need smth like the ruangrupa setup.
yes! If you don't want to expose an extra port synapse supports [delegation](https://matrix-org.github.io/synapse/latest/delegate.html) either by srv-dns record or like here with .well-known file. Other Matrix server then know to use 443 instead of federation port.
It's more tricky if you want to use the tld as matrix handle but also want to run matrix on a subdomain. Then you'd need smth like the ruangrupa setup.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
This config allows matrix-synapse to create a endpoint on
$DOMAIN/.well-known/matrix/serverused for federation.It's a straight forward way (no port opening required) to enable federation if you are okay having a subdomain (matrix.example.org) as your homeserver address.
This solution work's for me (federation tester is happy and some manual testing). But is it reasonable to use this method or does it make more sense to integrate the ruangrupa solution into this recipe?
nice @yksflip! and you don't have to open up the port? I'm a bit confused that you don't have to do that... but if you are sure it is then federating for you then this is pretty great! Small change 😄
@@ -86,3 +86,3 @@# Defaults to 'false'.##serve_server_wellknown: trueserve_server_wellknown: {{ env "SERVE_SERVER_WELLKNOWN" }}you'll need to bump the config version in the
abra.shalsoyes! If you don't want to expose an extra port synapse supports delegation either by srv-dns record or like here with .well-known file. Other Matrix server then know to use 443 instead of federation port.
It's more tricky if you want to use the tld as matrix handle but also want to run matrix on a subdomain. Then you'd need smth like the ruangrupa setup.
Thanks! you can
deploy -Cfor now I guess? We can make a release soon.