We should not require pusher URLs to be on a specific path

[richvdh]

per matrix-org/matrix-spec-proposals#1522, pusher URLs "MUST ... have a path of /_matrix/push/v1/notify".

I believe this was added so that we had a way of upgrading the Push API: if we needed to introduce a v2, the homeserver would figure out if it needed to talk v1 or v2 by inspecting the URI.

However, I think this is a poor way of achieving that. It would make more sense to introduce a new pusher kind of http_v2 (to sit alongside the existing http and email).

[richvdh]

I'm also not sure we need to mandate in the spec that it be HTTPS. Using an HTTP URL seems silly, but I'm not convinced it's the homeserver's job to stop you shooting yourself in that particular foot.

[richvdh]

I've labelled this as spec-omission, because synapse already allows you flexibility in this area.

[turt2live]

I've changed this to wart because we knowingly added this restriction even when we knew synapse wouldn't support it, with an intention of dealing with that problem if we ever needed to.

It was originally introduced for the version bumping mentioned in the description, though it is in fact not a pretty way to do this.

[michaelkaye]

I'm not sure what the value in opening this up is:

We already mandate that servers hosted within the matrix ecosystem in general are forced use specified prefixes at the root of their domains and this is an accepted practice.

The client-server API MUST be hosted at /_matrix/client and the federation API MUST be hosted at /_matrix/federation.

We also have the A-S API which is similar in that it is something you configure with a URL in the synapse server. However even then the postfix URL parts are still mandated; just the prefix is allowed to contain a host and optionally a path.

Additionally, it is a useful feature of standardised URLs that the path helps define what it is, when you're looking at logs or outbound traffic or even just searching the internet for what this API call is for.

Basically: we should open this up to customization to a level no more than the way the A-S endpoint allows, and ideally also change the C-S and S-S apis to normalise the amount of customization possible across the entire set of APIs, so any one of the specced APIs can be hosted at a url with a prefix including a path [i know this is hard, but as a goal].

So I should be able to host a pusher at http://example.com/testing/_matrix/push/v1/notify but not at https://example.com/push_To_My_App.com-v6

We definitely shouldn't move to permitting a third model for endpoints, and we should validate the accepted URLs to require this postfix (as we currently require the entire URL to be sent in the API call).

We should also move the url put in the data by the client to be a url prefix like the A-S api uses (which would mean a change to the C-S api), to standardise the identification of API endpoints across the spec [again, an bigger change but a good goal].

[richvdh]

So I should be able to host a pusher at http://example.com/testing/_matrix/push/v1/notify but not at https://example.com/push_To_My_App.com-v6

by your logic I should be able to direct pushes to https://example.com/push_To_My_App.com-v6/_matrix/push/v1/notify? (And watch out for nasty attacks like setting up pushes to https://example.com/push_To_My_App.com-v6%3Fx%3D which some helpful system %-decodes to https://example.com/push_To_My_App.com-v6?x=/_matrix/push/v1/notify. There be dragons here...)

We definitely shouldn't move to permitting a third model for endpoints

I think it's worth calling out a distinction between a group of endpoints where we want to be able to reach a number of different endpoints from a common prefix (eg, the C-S, S-S, and A-S APIs), and standalone endpoints where it is reasonable to talk about the entire URI for that endpoint. It's not obvious to me that the whole "prefix" arrangement buys a great deal for such standalone endpoints, and I'm not sure it's fair to consider this a "third model".

It's also worth noting that there are other places that URIs are passed around without requiring /_matrix in the path (for example, key_validity_url in m.room.third_party_invite.

If you feel strongly, I could get get on board with saying the client just submits the prefix to the C-S API, and the HS then adds /_matrix/push/v1/notify to build the complete URI, but the current (specced) arrangement seems to be the worst of all possible worlds.

[Sorunome]

Using an HTTP URL seems silly

If your gateway is on the same server as your homeserver (e.g. a gotify setup), it makes a lot of sense to use http

[Sorunome]

As for a pusher endpoint, some push services (e.g. gotify) do not allow to listen to root paths, but instead require there to be a prefix present. Allowing pushers to be https://example.com/blah/blubb/_matrix/push/v1/notify would allow such things to continue existing without the need of another gateway, only to re-write the path

[vsatmydynipnet]

Based on #8967, even I am no dev, I want to add, that Gotify currently is the only easy to run solution for people running without Google. I am working since a long time on mobile devices using LineageOS, full IN/OUT iptables Firewall and heavily protected stuff. (https://cpv.agency/kmjblog/2020/12/07/am-android-tablet-oder-smartphone-mit-lineageos-fuer-sicherheit-und-privatsphaere-sorgen/) All Open Source.

The missing part was a pusher notify system like Gotify, able to handle Matrix in the same Way then Nagios real time alerts aso. It would be really bad if this would be cancelled due to some URL definition problem. I hope there is a solution.

[innovationhub-asia]

Absolutely agree that adding that validation is far from ideal and in fact broke existing implementation of custom push gateways, somehow that commit was approved without caring of the overall ecosystems built around Synapse. TBH it's irresponsible to introduce such validations without considering backwards compatibility, what's more the specification clearly allows OTHER URLs

https://matrix.org/docs/spec/push_gateway/r0.1.1

"Notifications are sent to the URL configured when the pusher is created. This means that the HTTP path may be different depending on the push gateway."

[minecraftchest1]

What about having in the .well-known url files a matrix baseurl, aka the path to where /_matrix/* can be found.

[Thatoo]

What about having in the .well-known url files a matrix baseurl, aka the path to where /_matrix/* can be found.

@minecraftchest1 that's an idea discussed here : #693