-
-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How should an appservice opt-out of providing an endpoint? #1859
Comments
It is defined what ASes should do in this case: https://spec.matrix.org/v1.10/application-service-api/#unknown-routes It would be better if homeservers didn't keep trying and endpoint if it is not supported though, not sure if that's an implementation issue or if there's some spec missing to tell the homeserver to opt out. |
Worth noting that the specification, as currently written, requires an implementation to implement all endpoints unless those endpoints are explicitly listed as optional. It's an academic technicality, but appservices which don't implement an endpoint aren't spec compliant. They can likely get around it by not having a users namespace though, for example. Changing this would definitely need an MSC. |
Tricky, user namespaces are really handy for wanting to listen for events for users you care about. I suppose often the use case is that you're interested in all events on a given server, so maybe the registration file is missing some nuance. Either way, I think it's reasonable for appservices to choose not to implement a thing. |
See also MSC2379 that you wrote @Half-Shot. 😄 |
It's often the case that an appservice does not provide all of the functionality that is in https://spec.matrix.org/v1.10/application-service-api/#querying. For example, very few appservices actually implement the
/_matrix/app/v1/users/{userId}
endpoint. If you're just interested in consuming events, you really don't need the others.However, there isn't a spec-defined way to opt-out of providing these endpoints. Most developers opt to just let them 404 or 5XX or something to that effect, and hope the homeserver gracefully handles the error. I think we should do better here, and find a way to describe the endpoint as unimplemented.
Given that 404 is already taken as a valid response from some of these endpoints, one idea is just to respond with 501 (Not Implemented) for any valid endpoint that the appservice does not support. This would cause the homeserver to exempt that appservice for the duration the homeserver is up.
Anyway, if this is a reasonable sounding idea this should probably become a spec.
The text was updated successfully, but these errors were encountered: