Matching remote users against the application service user namespace regex is a footgun

[MadLittleMods]

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!

-- @anoadragon453, matrix-org/synapse#14000

---

This behavior has been updated in Synapse via matrix-org/synapse#13958

[turt2live]

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!

The spec should be clear that it's only events the server has access to (thus rooms which are shared with that server) - changing the server-side code to deny remote users would be a spec violation, at least without an MSC to back it.

@anoadragon453

[anoadragon453]

I agree. So not denying shouldn't require an MSC.

[turt2live]

I agree. So not denying shouldn't require an MSC.

Too many double negatives: At best, synapse can require a config option be set to allow the namespace, however it cannot take the functionality away on its own.

[turt2live]

ftr, matrix-org/synapse#13958 (comment) has more words on this (including the archeaology)

[MadLittleMods]

Created an MSC for this: MSC3905