Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Clarify that an appservice can be interested in local and remote users #14000

Conversation

MadLittleMods
Copy link
Contributor

@MadLittleMods MadLittleMods commented Sep 30, 2022

Clarify that an appservice can be interested in local and remote users. Also adds tests that would actually fail if we attempted something like #13958 again.


It's not really a question of controlling the users, but more of whether the application service wants to receive events and updates related to those users, which an application service may well want to do for events coming from non-local users.

-- @anoadragon453, #13958 (comment)

Pull Request Checklist

  • Pull request is based on the develop branch
  • Pull request includes a changelog file. The entry should:
    • Be a short description of your change which makes sense to users. "Fixed a bug that prevented receiving messages from other servers." instead of "Moved X method from EventStore to EventWorkerStore.".
    • Use markdown where necessary, mostly for code blocks.
    • End with either a period (.) or an exclamation mark (!).
    • Start with a capital letter.
    • Feel free to credit yourself, by adding a sentence "Contributed by @github_username." or "Contributed by [Your Name]." to the end of the entry.
  • Pull request includes a sign off
  • Code style is correct
    (run the linters)

@MadLittleMods MadLittleMods added the T-Task Refactoring, removal, replacement, enabling or disabling functionality, other engineering tasks. label Sep 30, 2022
Comment on lines +416 to +426
def _notify_interested_services(self):
# This is normally set in `notify_interested_services` but we need to call the
# internal async version so the reactor gets pushed to completion.
self.hs.get_application_service_handler().current_max += 1
self.get_success(
self.hs.get_application_service_handler()._notify_interested_services(
RoomStreamToken(
None, self.hs.get_application_service_handler().current_max
)
)
)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a better, more clean way to do this dance?

@MadLittleMods MadLittleMods marked this pull request as ready for review September 30, 2022 20:33
@MadLittleMods MadLittleMods requested a review from a team as a code owner September 30, 2022 20:33
Copy link
Member

@anoadragon453 anoadragon453 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have time at the moment for a full review, but with an AS hat on the comments and code look correct to me.

tests/handlers/test_appservice.py Outdated Show resolved Hide resolved
@anoadragon453 anoadragon453 requested a review from a team October 3, 2022 11:00
Co-authored-by: Andrew Morgan <[email protected]>
@erikjohnston
Copy link
Member

It's not really a question of controlling the users, but more of whether the application service wants to receive events and updates related to those users, which an application service may well want to do for events coming from non-local users.

Is there a legitimate use case for this though? I'm a bit wary as the behaviour will be different based on local or remote users. In particular, you'll only get stuff from remote users in rooms that the server is in, at which point you'll usually get that info as they'll be AS rooms.

I just want to make sure that this is something we consciously want to support, rather than something that someone might want at some point, maybe.

@anoadragon453
Copy link
Member

Thanks for questioning this @erikjohnston. After thinking about this more and asking in #matrix-spec, it indeed seems that there are no valid use cases for needing to specify a remote user in an application service's user namespace. By specifying local users, you will receive room events/presence updates from remote users anyhow.

As @Half-Shot put it, defining remote users is merely a footgun for which an Application Service may assume that it'll receive all events sent by that user, even though it will only receive events in rooms that are shared with a local user.

So by that logic, I'm fine with us defining (and limiting in the code) user namespaces to only cover local users. It would make sense to update the spec to include the same. Sorry for the run-around!

@MadLittleMods
Copy link
Contributor Author

Sounds great to me 👍

I'll get #13958 in shape again ⏩

@MadLittleMods
Copy link
Contributor Author

It would make sense to update the spec to include the same.

Also created matrix-org/matrix-spec#1272 to track a spec clarification ⏩

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A-Application-Service Related to AS support T-Task Refactoring, removal, replacement, enabling or disabling functionality, other engineering tasks.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants