Skip to content
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

Open
Half-Shot opened this issue Jun 11, 2024 · 4 comments
Open

How should an appservice opt-out of providing an endpoint? #1859

Half-Shot opened this issue Jun 11, 2024 · 4 comments

Comments

@Half-Shot
Copy link
Contributor

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.

@clokep
Copy link
Member

clokep commented Jun 11, 2024

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.

@turt2live
Copy link
Member

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.

@Half-Shot
Copy link
Contributor Author

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.

@clokep
Copy link
Member

clokep commented Jun 24, 2024

See also MSC2379 that you wrote @Half-Shot. 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants