Closed heurtematte closed 1 year ago
These restrictions are because it's not possible for an appservice to control users on other domains. The Intent
instances are controllable users.
Membership events are raised through room.event
though - does that help?
What sort of usecase are you after which needs this functionality?
I think this kind of control should be on the matrix side, than on a SDK for developing app-service, and if it doesn't exist maybe a requirement from matrix spec.
I can filter join membership with room.event
, so that's work for me. thanks! :-)
My usecase is to interact with federated users trying to join public rooms and provide links about private policy, code of conduct, .. in the same way as consent workflow works for internal homeserver users.
The restriction regarding controllable users is on the Matrix side, fwiw
For your usecase, room.event
is definitely the way to go here.
Describe the bug
Appservice can't emit
room.join
event when it involves users from other domains due to some conditions on it. https://github.com/turt2live/matrix-bot-sdk/blob/main/src/appservice/Appservice.ts#L632Same for other events:
room.leave
,room.invite
To Reproduce Steps to reproduce the behavior:
User from a homeserver try to join a public room on other matrix homeserver where an appservice is deploy which tries to manage
room.join
event, not only local users, but also users from other homeservers.Expected behavior
No restriction on domain, should be only app specific development not sdk. Even some specific code about intent: this.getIntentForUserId(event['state_key']); https://github.com/turt2live/matrix-bot-sdk/blob/main/src/appservice/Appservice.ts#L635
IMO it's more functional code, and might be somewhere else, not in the SDK, or on a specific event.